[Talk-us] US Interstate exit junction exit_to tag

Alan Mintz Alan_Mintz+OSM at Earthlink.Net
Fri Apr 8 18:29:13 BST 2011


At 2011-04-08 09:55, Nathan Edgars II wrote:
>On 4/8/2011 12:47 PM, Alan Mintz wrote:
>>At 2011-04-07 13:31, Nathan Edgars II wrote:
>>>On 4/7/2011 4:09 PM, Alan Mintz wrote:
>>>>"Exit 183 / SR-247 South / Barstow Road"
>>>>is tagged
>>>>ref="183" +
>>>>exit_to="CA-247;Barstow Road" +
>>>>exit_dir="South;"
>>>>
>>>>Does anyone have examples of places where my suggested model does not
>>>>work?
>>>
>>>It's not backwards-compatible with anything that uses exit_to. To get
>>>the text of the sign you have to piece together the exit_to and
>>>exit_to_dir fields.
>>
>>It's the way it was done with the street name split a while back, though
>>I acknowledge that it isn't an identical situation, since we ultimately
>>decided the direction was not part of the street name. In this case, the
>>direction is an important part.
>
>It's not even close to identical.

Ack'd, as I wrote.


>  It's very rare to have two parallel streets with the same name except 
> for a different directional prefix (and in those cases the directional 
> prefix should be part of the name).

Agreed, though I can think of two immediately, one of which is just a 
couple miles from me (North and South Mainstreet), and the other in LA 
(East and West Vermont St. running N/S). In the direction prefix 
discussion, all agreed that the directions in these _are_ part of the name, 
and should/would not be separated out. They should not be separated in this 
case either.


>  On the other hand, it's very common to have two consecutive exits for 
> each direction of a road.
>The question is still what benefit there would be to splitting it.

I gave an admittedly weak example in my last response to Mike N. My point 
is still that there does not necessarily have to be an existing use case to 
support modeling the data in this way. It's part of an experienced DBA's 
skillset to be able to guess at what might be needed in the future when 
modeling data today to reduce rework in the future. In the OSM environment, 
where there is no formal schema, versioning, practices to sync consumers 
and providers on the same spec, etc., it's particularly heinous to have to 
re-work things later.


--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>




More information about the Talk-us mailing list