[OSM-talk] Potential problems moving/depreciating map features tags.

Ulf Lamping ulf.lamping at web.de
Fri Jul 13 20:45:04 BST 2007

David schrieb:
> With all the talk of fixing the inevitable inconsistencies and niggles
> in map features I haven't seen much talk on the potential problems
> that changing tags could cause.
> I think it would be wise to discuss this a bit. The problems I see follow.
> 1. How will the changes be communicated? Both to mappers entering data
> and consumers of the data either via the API or planet dump. If people
> don't know the tags have changed they will keep using the old ones.
> I believe I read on one of the lists there are more active mappers
> that are not subscribed to the various mailing lists than are
> subscribed.
> I also think the map features wiki page may not be viewed often by
> lots of mappers. Once you memorize the basic tags you need you don't
> have a lot of reason to go back. If you do it's possibly just to find
> a new tag you haven't used yet so you might easily skip over the
> changes without noticing them.
> Also the planet dump is easy to get hold of and in a relatively simple
> format. This means it's very easy to use without making any noise.
> Lots of people could be using it for all sorts of things without
> anybody knowing.
> Perhaps it would be better to pool the changes together and apply them
> all at once with lots of fanfare to increase the chances mappers will
> notice.
> 2. User inertia. Even for technical people getting the hang of mapping
> can be a bit of a challenge. Since the old tags will presumably
> continue to work many people might just continue using them instead of
> making the effort to learn new tags.
> 3. What to do with the old tags in the database? The old tags can't
> really be deleted because the person entering them might be using a
> different tagging scheme.
> The new tags could be added to primitives that have the old tag. That
> has the disadvantage of increasing the size of the data without
> conveying additional information.
> Just ignoring the old tags sort of gives a situation I feel map
> features was intended to avoid. Having different tags with the same
> meaning.
> The old tags are not too bad if a tag gets changed once but what after
> two, three or four times? Using the data starts to get more difficult
> as you need to be away of not only the current tags but all the
> historical ones as well.
> Presumably at some point in the past the tags currently depreciated
> fit into the tagging scheme reasonably well. As map features continues
> to grow and evolve more tags may look out of place including those
> previously moved.  So having tags move more than once isn't out of the
> question.
> I personally think it may be best to live with the inconsistencies.
> The infrastructure isn't currently there to support the amount of
> evolution it needs to stay consistent. I think it may need to move
> beyond a wiki page and become more integrated with the api. Perhaps
> even to the point map features tags are separated from the rest of the
> tags and expected to comply with a defined standard. That way editors
> like JOSM could present the standardized tags to the user anyway they
> wanted. Hiding any inconsistencies or even the concept of keys and
> values altogether.
> Ok so I rambled at the end but I think the earlier points have at
> least some merit.
Hmmm, this really sounds to me like: let's wait until some voodoo magic 
happens, and then all will be well - but let's do it later. Let's see 
the disadvantages of keeping things as they currently are:

The map features page serves as a kind of reference (I know, some people 
don't like this at all) for osm. It's one of the first things a newbie 
will see - and to be honest it's a real mess (which makes it hard for a 
newbie to learn tagging easily). The tagging scheme still doesn't make 
sense for a lot of things, good example pages are pretty rare, ... So 
seeing this as "the reference" for osm really set's me in a bad mood ...

I'm pretty aware of the problems that such changes will provide for all 
participants - and I don't have a clean solution for all of them. 
However, from software development my experience is: waiting for cleanup 
of stuff to some point in time in the future usually makes things worse 
than doing it as soon as possible - once you know the right way to go. 
Waiting for some vodoo day to change, will only let more people have to 
learn the changed tags and more "external" projects will have to change 
more things.

Example: osmarender misses a lot of icons for things already in the map 
features. As I'm currently doing it with mappaint, I'm gonna add these 
icons to osmarender more sooner than later (that will be another 
annoyingly long discussion :-). So fixing the map features first will 
give me a lot less work than adding anything to osmarender now, changing 
things in map features later on and then changing osmarender again. This 
it true for the currently none existing wiki pages, software working 
with the planet file, ...

So in the end you'll have a lot *more* work than doing it right away ...

It was also discussed earlier, that the changes to the database can be 
done in a bulk update, which was already done before to fix some typos.

What you proposing by keeping a fixed set and release new changes is 
exactly what's done in software development. However, this results in 
additional overhead, and we already don't have the manpower to stem the 
work to be done (see the various none existing Mapping/Features pages).

BTW: Yes, this was all discussed before in recent days.

Regards, ULFL

P.S: You might not be aware of the "release early, release often" 
software development paradigma, which basically states (oversimplified): 
"don't wait too long for changes to go to the public"!
P.P.S: I've started a 
http://wiki.openstreetmap.org/index.php/Deprecated_features page, so you 
can easily track changes that way, if you like.

More information about the talk mailing list