OSM Development Problems

Created by: Lester Caine, Last modification: 25 Aug 2015 (13:05 BST)

This is taken from a post to the OSM Talk list and I've copied it here as the base for a sort of Blog on the problems of dealing with OSM data these days.

--------

I can't believe that I am the only person who is stuck in a sort of no-mans land in relation to OSM. Time is a commodity that is in short supply for many of us, so ideally we want to make the best use of it. What I would prefer to be spending time on IS adding data and while I've a growing backlog of material which I should like to add, much of that relates to historic development of the current data, so CURRENTLY I do not have a crib sheet to follow to add material which substantially relates to current object, but includes elements which may come under the classification 'abandoned railways'. The sections of railway information are only a part of the historic element and includes other objects which are currently being adapted or replaced, and I currently don't see ANY point in migrating random pieces of history to OHM, when the bulk of the context is still on OSM. I can be confident that the material is buried in the change log, but that does not make it usable for rendering, and THAT is the problem here. Just as people can omit 'abandoned railway' tag from their own rendering, 'old road or old building' should also be selectable ... and in my book, all that is missing currently is correct rending of 'start_date' and 'end_date' in conjunction with the historic material such as 'abandoned railway'.

Yes I know that end_date is a crude structure as is start_date, but currently they are all that exists to provide a chronology of when objects appeared on the map and in what form. That a base map would only contain object with a current valid start_date and end_date allows new development to be mapped but not yet displayed, and the evolution to that new development still to be maintained in the database. This is more about CURRENT history than adding past events but a solution should cover both.

Up until now while the differences between the rendering in various tools was irritating, it was reasonably manageable. I don't see that the current planned change will be reflected in all the tools quickly? And more of a problem, if some tools follow 'old' practices then things will be even more confusing for newcomers?

Now I am TRYING to get my head around all of the extra stuff I need to provide a private rendering system and I've just had to do a hard reboot of the server as it froze trying to render a sample picture of where I've got to, so I need something a bit more stable before I can use it in the open. Even with an 8 core processor and 32Gb ram it's struggling with a small extract, but then the UK slice does have a larger volume of data for the area?

osm-lsces-demo should explain partially where I've got to. Shields on the road numbers seem to be inconsistent. Need a few less on some roads, and actually include some on others. The other problem is as you should be able to see the main traffic routs are on secondary roads (yellow here), but a number of key roads are actually tertiary or unclassified and I think I need to actually re-tag them so that the gaps in the routing grid are properly represented. Of cause the hill structure would go to explain a few gaps in that grid ...

I'm trying to get self sufficient, but that is simply not an easy job with so many different tools used in the background!

------

The time being spent on keeping a UK style rendering available is more than I would like to spend, but at least one can take control of things unlike other sources where people 'improve' things all the time without any regard to what current users actually need.