Peter Miller wrote on 02/06/2010 10:17:
> On 2 Jun 2010, at 09:48, Ed Loach wrote:
>
>    
>> Gregory wrote:
>>
>>      
>>> But what if a 3rd source says something different. Should
>>> we record that too, and how?
>>>        
>> not:name=Something,Somewhat,SomePlace,...
>>
>> This perhaps relates to a discussion I just had on the irc channel
>> about how to tag a road with two names. I've not checked the OS
>> Locator source data, but there is a road in Wrabness which seems to
>> have two names - Rectory Road and Primrose Hill. The best
>> suggestions on how to tag this involved using the alt_name tag or
>> using ; as a separator in the name tag as is commonly used for
>> separating values already. (This arose as I'd tagged the name as
>> Primrose Hill and the ITO comparison layer highlighted that Rectory
>> Road was missing).
>>
>> So I'd suggest if it doesn't already that the layer recognise
>> ;-separated lists in both name and not:name tag values.
>>
>>      
> I believe that Gregory was actually talking about a list of names that
> the road isn't called rather than alternative valid names.
>
> With references to an earlier comment about the OSM DB being 'flooded'
> with 'not:name' data I estimate that only 0.3% of roads in OS Locator
> have errors so we are talking about a very small number of entries,
> but they may be important entries. In that case that there are
> multiple not:names, then possibly the ';' separator would be
> appropriate to create a list, but I can't think of any instance where
> I would use it at present.
>
> I guess what we are saying is that there is a difference between an
> error (calling it High Street when it is actually Rectory ROad and
> High Street is somewhere else in the village) and where some locals
> refer to it as Rectory Road. The former go in not:name and the later
> in alt:name. Or OS Locator layer should probably also check 'alt-name'
> fields and treat them as matches.
>
>
> Regards,
>
>
> Peter
>
>    
>> Ed
>>      
>
I haven't really got my head into the database design to know of where 
it is weak or strong, but the critical issue is to have distinct, 
understandable entries where different meanings are around.

If you introduce a new tag that has a distinct and clear purpose, then 
you can readily backtrack and merge it with something else.

If you try and adapt and interpret tags, then you head down a path where 
the ambiguity allows others to take other views, and then you cannot 
manipulate the data.

In this case, there are a couple of interesting issues. One it is 
country specific, and secondly we are talking about data that is not for 
publication.

My suggestion would be:

1) That there should be a GB/UK specific group of tags (or more 
specifically country specific) so there is no need for these projects to 
seek world-wide consensus.
2) A country specific tag is assumed never to be rendered.
3) A country specific tag can be converted according to whatever rules 
are deemed appropriate into a formal tag, but there would need to be a 
convention on whether the conversion was one time (and therefore the tag 
should then be removed) or ongoing.
4) Within the tags, there could be a convention for working data.

So we could have:

gb:work:invalid-name   Chelsee
gb:way   Unclassified County Road   -->  Highway:unclassified
gb:project:OSVector:validated no

Just a thought.

Spenny


_______________________________________________
Talk-GB mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-gb

Reply via email to