Lester Caine wrote:
Not really the right choice of words, but following on from yesterdays post
related to 'timezone' I've been using the tools available and viewing the
current coverge of that tag, which is fairly complete - except - in some areas
the smaller parcels making up an area rather than the area itself is tagged with
the information. Now in theory it should nat matter as I should be able to throw
away relations totally contained within another and be left with the top set,
but should that 'processing' be applied in general to this type of 'relation'.
ISO3166 country codes are perhaps another example. Add a note to the relevant
guideline that if tagged item is totally contained within another of the same
'value' then it will be removed.
This links to how one gets a list of tags related to all of the relations a
query co-ordinate is located in so we can return that 'inventory'
Following a couple of discussions at Birmingham yesterday, a couple of
additional points came up which I am sure have been discussed somewhere.
I'd like to propose the concept of a 'metatag' which is a tag which is returned
for every point enquiry. We do not want to create a lot of these, but a few
would make sense. timezone, and 'administrative' such as ISO3166 codes should be
a useful key, but also landuse. All of these would be relations rather than
areas, and would automatically but combined to provide a single 'overlay' ...
one result per node on the data.
This relates to another apparent anomaly when people are adding data like
'landuse' in that where two areas touch, we get two overlapping ways which may
require tagging with different boundary information. The particular example was
field boundaries for agricultural use. My own 'style' is to pick out the whole
area as agriculture, and then add the field boundaries within that area. But
others draw each field as an area, and then there is no way to pick up to tag
the boundary type. The timezone data is another example where 'style' changes,
and some zones have tens of small areas while the majority are single relation
per timezone.
I think that we need to come up with some way to assist in combining data where
there is no need for duplication if the result set of an enquiry can include the
relevant tags. Select all the areas tagged with the same 'metatag' and then
rework them to provide a relation and separate ways where the boundary is common.
I'm also thinking here that the 'addressing' problem could be helped if
'postcode' (or something equivalent in areas without) was a metatag, and when a
building is selected, adjacent street tags were listed so that the correct one
can be applied to the building. Saves having to type the street name every time,
and would reduce the volume of data needing to be stored as that would only be
entered once per 'postcode'. The administrative metatag would return the area
details for a postcode. This would hopefully allow us to get around the current
problem of things like 'Broadway, Wychavon' when it should be 'Broadway,
Worcestershire' ( and Not Broadway, Gloucestershire which ia all Facebook will
accept! )
Back off out to Birmingham ...
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
