Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Mon Jul 05 2010 - 02:37:41 EDT

This problem is not just limited to these conventions for thoroughfares. The interpretation of many parts of a civic address rely on the context provided by other elements.

The solution is really simple. Don't omit useful stuff.

A postal worker that receives a letter addressed to "1600 (absent) Avenue" is well-justified if she decides that she is not going to deliver the letter [1].

If you want to ensure that the letter gets delivered, you put the rest of the address in. No different here.

Any system of constraints is likely to fail internationally.

Making house number relative to the thoroughfare is not possible. There is the thoroughfare branching we encountered, which would complicate it. The perfectly logical numbering system employed by the Japanese for house numbering, which is relative to the block [1], would make it even more difficult to codify.

--Martin

[1] No allowances made for overly zealous posties who know that there is only one 1600 on an Avenue in the city and deliver the letter anyway.

[2] http://en.wikipedia.org/wiki/House_numbering#Japan_and_Korea

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Brian Rosen
> Sent: Monday, 5 July 2010 8:23 AM
> To: thompson@ieee.org
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-
> 00.txt
>
> While I do want to change the basic way the PIDF schema is defined,
> enforcing a restriction in the schema seems like a poor choice. I am
> loth to define a null road name; that's a big change to the way PIDF
> works; if you don't have an element, you don't include it, rather than
> include it with a null value.
>
> I'll ask around the PIDF cognoscenti to see what they think.
>
> Brian
> On Jul 4, 2010, at 3:45 PM, Geoff Thompson wrote:
>
> > Brian-
> > It seems lik a bad idea to let perfectly good assumptions (like a MP
> > or a house number "needs" a road name) get screwed up by unusual
> > exception as you have noted.
> >
> > Why not, instead, just charge ahead but allow a special value of
> > road name ("NULL" ?) that notes that in this case it is known that a
> > road name does not exist? The entered value should probably be
> > differentiated from that which would be provided if the value of
> > road name were "unknown".
> >
> > Geoff
> >> Message: 2
> >> Date: Sat, 3 Jul 2010 16:53:18 -0400
> >> From: Brian Rosen<br@brianrosen.net>
> >> Subject: Re: [Geopriv] Fwd: I-D
> >> Action:draft-george-geopriv-lamp-post-00.txt
> >> To: Carl Reed<creed@opengeospatial.org>
> >> Cc: geopriv@ietf.org
> >> Message-ID:<917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net>
> >> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
> >> DelSp="yes"
> >>
> >> I am a co-author on this draft, and the milepost addition to the
> lamp
> >> post original was motivated by the NENA requirement to have a
> >> milepost.
> >>
> >> I agree that the MP nearly always needs a road name. So does a
> house
> >> number. The current documents don't have requirements like that,
> >> primarily because we keep finding odd cases that don't meet what we
> >> thought was a simple rule.
> >>
> >> Brian
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Mon, 5 Jul 2010 14:37:41 +0800

This archive was generated by hypermail 2.1.8 : Mon Jul 05 2010 - 02:35:58 EDT