[OSM-talk] stop deleting abandoned railroads
61sundowner at gmail.com
Mon Aug 17 11:37:33 UTC 2015
On 17/08/2015 4:28 PM, Colin Smale wrote:
> If only all this energy were directed at helping OSM forwards. We
> haven't had a lot of progress in the last few years (I am not talking
> about mapping as such, but about the OSM framework itself).
> There are still periodical discussions about how to link OSM with
> other data sources - OSM IDs are too volatile, and IIRC there were
> objections to putting "foreign keys" (like shop branch numbers) into
> OSM on the grounds that someone would need to maintain that link. So
> how ARE we going to do it then?
Maintenance/verification takes place by those concerned.
If a branch shop number is of concern to you .. then you check it.
The idea that everyone must be able to check everything is ridiculous.
> Or are we insisting on building what we in the trade call a "data
> island"? Let's build some technical bridges, so it becomes a real
> alternative to maintain a parallel data set.
> And then of course there are support for 3d mapping and the "area data
> type" which have been under discussion for years.
You forgot 'indoor mapping'... :-)
> How will we square the circle with regards to data quality?
I've had students trying to square circles .... having shown them how to
square rectangles/squares/triangles on the same machine.
> Will the free-tagging laissez-faire camp win, or will the
> curated/managed tagging camp win?
I'm in the 'systematised free tagging' camp .. I want a structure that
has a simple good logical basis for the tags. But allows added tags ..
hopefully following the structure present.
At present there is no structure/philosophy that can be followed.
> How will this tug-of-war be organised? Will the forces at work cause
> OSM to tend to converge towards "quality" or self-destruction? After
> all, OSM says its product is the data, not a mapnik representation.
> The raster tiles may look OK, but the underlying data may tell a story
> of mapnik and OSS-carto having to work very hard to mask bad data quality.
The quality of the data is not your/my issue .. it is the structure of
> Where is this all going to end?
> Aren't there more important things to worry about than whether or not
> a couple of hundred ways deserve a place in OSM?
Those who are worried about it .. do it .. and try to fix these issues.
Big issues or small issues ... depends on your view point.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk