From my perspective it feels like all the people making money with products based on OSM are fine with the core project stagnating, because it encourages more customers to consider their own offerings.
OSM is certainly not the only problem suffering from this, it’s the same with Scala.
I’m not involved with OSM, but I looked at using it for a project several years ago, and it seemed pretty clear back then that it was only meant to be a data source, and not a pre-built solution.
With that context, a lot of the problems in this article don’t look so bad. Should things like tagging and new data models go into the core functionality? Or should they be separate projects built using the core functionality? I don’t know the answer, but maybe it helps explain why OSM may seem to be stagnating.
I don’t see this as problem too (that there’s no pre-built solution). However, fuzziness of tagging schemes makes raw OSM data → your domain model step really hard.
For example, problems with geocoders (postal address search engines) mentioned in post is largely because it’s hard to extract buildings (they might be mapped as points, ways and relations, and relations might have building=* both on relation and on outer contour), parts of street address (but street-level addresses are blobs anyway) and, most importantly, membership of city/town/village: first you need to extract populated place boundary (either place or boundary, I don’t know which is right), then check for geometry inclusion. You also probably need to add some buffer zone around city boundaries and should be able to fix minor breaks in multipolygon relations (they can consist of thousands of ways and accidentally broken when editing features near boundary).
Even renderer on main OSM page has such problems: for example, sometimes named object such as place is tagged twice: on polygon and on point inside this polygon. Should renderer render it once or twice? And how should it merge such objects?
I think the idea would be to pull in data directly into a version of the base product so that the data can be shared.
There’s some trickiness involved, and it would be surely necessary to opt-out, but in an alternate universe all the transportation information/yelp reviews/etc. could be fetched and OSM could be as useful/better than GM
OSM is more widely used than ever before, but I agree that it’s got a number of systemic risks. Zverik hints at a few key ones: a long-time exclusively volunteer approach, a fear of executive action, and a resistance to professional input. Fortunately the US Foundation (there are many international chapters) is working on some of these issues by hiring its first-ever executive director. This may benefit just the US community initially. I expect it will help OSM cross over from a hobbyist (“craft”) mentality to a product or utility mindset long-term.
What I think would make sense is for official cartographic agencies to start maintaining their respective regions of the map and contribute towards standardization and tool development. Public maps are a business enabler and could be considered public infrastructure.
Libraries are doing something similarly stupid. They are very frequently catalogizing individually instead of sharing the records and even when they share the records, they don’t publish them as open data – meaning projects such as Wikipedia / Wikidata cannot use them.
From my perspective it feels like all the people making money with products based on OSM are fine with the core project stagnating, because it encourages more customers to consider their own offerings.
OSM is certainly not the only problem suffering from this, it’s the same with Scala.
see also https://lobste.rs/s/oaeb7y/why_openstreetmap_is_serious_trouble
I’m not involved with OSM, but I looked at using it for a project several years ago, and it seemed pretty clear back then that it was only meant to be a data source, and not a pre-built solution.
With that context, a lot of the problems in this article don’t look so bad. Should things like tagging and new data models go into the core functionality? Or should they be separate projects built using the core functionality? I don’t know the answer, but maybe it helps explain why OSM may seem to be stagnating.
I don’t see this as problem too (that there’s no pre-built solution). However, fuzziness of tagging schemes makes raw OSM data → your domain model step really hard.
For example, problems with geocoders (postal address search engines) mentioned in post is largely because it’s hard to extract buildings (they might be mapped as points, ways and relations, and relations might have
building=*both on relation and on outer contour), parts of street address (but street-level addresses are blobs anyway) and, most importantly, membership of city/town/village: first you need to extract populated place boundary (either place or boundary, I don’t know which is right), then check for geometry inclusion. You also probably need to add some buffer zone around city boundaries and should be able to fix minor breaks in multipolygon relations (they can consist of thousands of ways and accidentally broken when editing features near boundary).Even renderer on main OSM page has such problems: for example, sometimes named object such as
placeis tagged twice: on polygon and on point inside this polygon. Should renderer render it once or twice? And how should it merge such objects?I think the idea would be to pull in data directly into a version of the base product so that the data can be shared.
There’s some trickiness involved, and it would be surely necessary to opt-out, but in an alternate universe all the transportation information/yelp reviews/etc. could be fetched and OSM could be as useful/better than GM
OSM is more widely used than ever before, but I agree that it’s got a number of systemic risks. Zverik hints at a few key ones: a long-time exclusively volunteer approach, a fear of executive action, and a resistance to professional input. Fortunately the US Foundation (there are many international chapters) is working on some of these issues by hiring its first-ever executive director. This may benefit just the US community initially. I expect it will help OSM cross over from a hobbyist (“craft”) mentality to a product or utility mindset long-term.
What I think would make sense is for official cartographic agencies to start maintaining their respective regions of the map and contribute towards standardization and tool development. Public maps are a business enabler and could be considered public infrastructure.
Libraries are doing something similarly stupid. They are very frequently catalogizing individually instead of sharing the records and even when they share the records, they don’t publish them as open data – meaning projects such as Wikipedia / Wikidata cannot use them.