[Talk-us] US Interstate exit junction exit_to tag

[Alan Mintz]

At 2011-04-07 13:47, Mike N wrote:
>On 4/7/2011 4:09 PM, Alan Mintz wrote:
>>
>>Case 2. Very occasionally, there will be more than one street name
>>shown, usually when the ramp ends at or near a point where a street
>>changes name. Use semicolons to place multiple values in the exit_to and
>>exit_to_dir tags. e.g.:
>>
>>"Exit 73 / Diamond Drive / Railroad Canyon Road"
>>is tagged
>>ref="73" +
>>exit_to="Diamond Drive;Railroad Canyon Road"
>>
>>"Exit 183 / SR-247 South / Barstow Road"
>>is tagged
>>ref="183" +
>>exit_to="CA-247;Barstow Road" +
>>exit_dir="South;"
>
>   Does exit direction refer to the compass direction of the intersecting 
> road, or the signed direction, and if so which road in the list?

Compass direction of the road, usually for intersections with primary or 
higher category roads where there are multiple ramps to reduce 
intersections (e.g. cloverleafs).


>   Sign:  I77 North; US 44 East; NC 56 East; Charlotte; Rock Hill; York

Assuming that Charlotte, Rock Hill, and York were aligned with I77, US44, 
and NC56, respectively on the sign:

exit_to="I-77 North;US-44 East;NC-56 East"
towards="Charlotte;Rock Hill;York"

OR

exit_to_root="I-77;US-44;NC-56"
exit_to_dir="North;East;East"
towards="Charlotte;Rock Hill;York"

(See note [0])



>   So someone has to parse the sign to be able to properly enter the 
> information?   And I'm still not clear on the benefit of having it 
> separated if the first thing the data consumer does is string it back together.

Not all consumers are for the purpose of navigation or map rendering. It 
might be useful, for example, to be able to query

select * from <CA-60 exit nodes> where exit_to_root="Rosemead Blvd"

to get both ramps from CA-60 to Rosemead Blvd, instead of having to use 
'exit_to like "Rosemead Blvd%"'.



[0]: You may have been alluding to some ambiguities in the way ; can be 
interpreted. Here's what I've done when the number of values in one tag is 
not the same as the number of values in another related tag. I'm hoping 
that consumers follow suit:

- Each value consists of fields that are separated by semicolons.
- Empty fields in the beginning or middle of the value are indicated by 
just the separator (semicolon). This also means that you use a trailing ';' 
to indicate that the last field in a value is empty.
- If valueA and valueB are related, you parse them from left to right to 
get the correct A/B pairs. If you run out of fields in one before the 
other, the last value is repeated for the one that is short - otherwise the 
user should have just used empty fields to indicate there were no values 
there. e.g.:

A-B pairs 1-2, 3-4, 5-<nothing>, 7-8, 9-10, 11-10, and 12-10 would be 
encoded as:

A=1;3;5;7;9;11;12
B=2;4;;8;10

If you add another pair 13-14 to the end, you would have to encode it:

A=1;3;5;7;9;11;12;13
B=2;4;;8;10;10;10;14

Yes, this can be complicated. If the user chooses not to use the unequal 
count feature, just ensure you put the same number of fields in each value, 
repeating or using an empty field as necessary.

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