On 4/8/2011 1:16 PM, Alan Mintz wrote:
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%"'.
As Nathan has noted, you still need a fuzzy search to find Blvd or
Boulevard. Also spelling mismatch searches are useful to find 'Rosmead'
/ 'Rosemede' as either the search term or the typo'd OSM entry. This
is something that computers are good at. Mapper resources should be
reserved for surveying and geo creation, not pre-parsing queries.
While I agree that we need to make sure that whatever we come up with is
not awkward to use, exit_to doesn't qualify as awkward. There are only
52,000-some motorway_junctions tagged in the world, and I'm pretty sure
that 70% of the US motorway junctions have been entered. That number
of entries is easy to handle even if you have to perform a search-query
on all.
>I would not be averse to something like:
>
>exit_to="CA-247 South"
>
>OR
>
>exit_to_root="CA-247"
>exit_to_dir="South"
>
>Consumers that have evolved can use the second form if it is found, or
>the first if it is not. Older consumers can use the first form. Users
>that choose not to use the second form can use the first form and it
>will work with both old and new consumers.
The point of the most recent change was standardization - consumers
should not need to code 2 routines to handle both forms. Our tagging
guides should be as simple as possible. There is already a good 1 page
on motorway_junction. If a non-programmer were to try to enter their
information and saw a full second page just to cover parsing rules, they
would simply abandon their efforts as too complicated. (That already
happens too often today with the existing OSM guidelines)
_______________________________________________
Talk-us mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-us
