>And that’s the point, rules and complexity have completely unknowable downsides. Downsides like the destruction of the whole project.
With each rule and added complexity you make the system less human and less fun. You make it a Computer Scientists rube goldberg machine while sterilizing it of all the joy of life.
While too much rules and complexity can certainly be bad, some basic amount of standardization can actually reduce complexity and really doesn't cause a "destruction of the whole project".
As a counterpoint, too much flexibility can also increase complexity. For example, without defined rules, 5.6.2022 can mean 5. June 2022 or 6. May 2022. Nor user, nor parser can know for sure what it means, if standard isn't defined. This kind of flexibility certainly isn't fun.
Example from OSM wiki for "Key:source:date":
> There is no standing recommendation as to the date format to be used. However, the international standard ISO 8601 appears to be followed by 9 of the top 10 values for this tag. The ISO 8601 basic date format is YYYY-MM-DD.
https://wiki.openstreetmap.org/wiki/Key:source:date
Just define some essential standards. It won't lead to destruction of the project!
And while you are making breaking changes, please fix the 'way' element. Maps are big. Storing points in ways as 64bit node-ids, while coordinates in nodes are also 64-bit (32bit lon and 32bit lat), just leads to wasted space and wasted processing time. There are billions of these nodes and nearly all of these nodes don't have tags, just coordinates. There is no upside for this level of indirection. And in case tags are needed for a point, this can already be solved with a separate node and a 'relation' element.
OSM data format could certainly be improved and it would benefit end users, as better tools/apps could be made more quickly and easily.
The date example is a good one. No one has fun by choosing their own date format. This is putting the burden of choice onto the user. They might like to think about some map stuff and now they have to think about data format stuff.
Of course projects like these have to strike a balance between the strictest bureaucratic nightmare and such a structure so loose that people are overburdened by the available options at every corner.
I think a lot of that complexity can (and should!) live in the tools themselves. Who cares about a date format, when the tool that creates it offers a date picker or extracts the correct date from the meta data of an image? The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input.
The proposed improvements would obsolete a bunch of problems such as broken polygons [1] which happen regularly. They would also make processing OSM more accessible without needing to randomly seek over GBs of node locations just to assemble geometries which takes a significant runtime percentage of osm2pgsql.
For me Steve Coast lost his credibility when he joined the closed and proprietary what3words.
There's around 5.1e14 meters squared on the surface of earth. It takes 34 bits to address this uniquely. If we use one of EFF's dice words style short word lists (6^4 words), we need 5 words to describe any point on earth with 1 meter precision.
If we use a projection like say S2 (though plenty of other options exist), these 5 word locators will show strong hierarchical locality. In any specific area for example, there's likely only 3 distinct top level words. Likewise, the last word is useful but probably unnecessary precision for "find the building" day to day use. So the middle 3 words will be sufficient to be unambiguous in most cases, and if people used this system they'll naturally become familiar with the phrases typical to their locale.
All of this can be done with an algorithm a freshman cs student can understand, with a trivial amount of reference data. It can run on any mobile device made in the last 15 years without an internet connection.
I designed a scheme like this for fun years ago, just because it was a natural outflow of some stuff I was doing with dicewords for default credentials in a consulting context, and I just find spatial subdivision structures neat.
It's hard to interpret what3word's scheme as anything but craven rent seeking. They want to keep the mapping obscure, and fundamentally sacrifice usability in the interests of this. That what3words markets this specifically as a solution for low income nations, and dupes NGOs that are not tech savvy in the service of this is utterly #$%@$#ing revolting.
Imagine trying to rent seek on selling poor people their own street addresses, if you'll let me be slightly hyperbolic.
There is no reason a scheme like this can't simply be a standard from some appropriate body, and a few open source reference implementations.
But you don't need to complicate the storage format to fix a problem like that. You can build validation tools that will check whether the stored data conforms to the correct specified geometry, and only emit valid polygons to later tools in the pipeline when they do.
"Be liberal in what you accept and strict in what you send" is still a good principle. The problem with rejecting invalid structures at the data storage format instead of a later validation step is that it hurts flexibility and extensibility. If later on you need a different type of polygon that would be rejected by the specification, you'll need to create a new version of the file format and update all tools reading it even if they won't handle the new type, instead of just having old tools silently ignoring the new format that they don't understand.
In the first part of the article I was thinking, oh, maybe Steve Coast isn't such a jerk after all.
Then I got to the meat of it. Oh dear.
As one of the many many people who has had to deal with OSM data, I curse people with this attitude that the mess is somehow desirable or necessary. It's not. There is a long spectrum between totally free form and completely constrained, and OSM's data model is painfully down the wrong end, and causes enormous harm to all kinds of potential reuses of the data.
It also causes harm to the people creating data. Try adding bike paths and figuring out what tags are appropriate in your area. Try working out how to tag different kinds of parks, or which sorts of administrative boundaries should be added or how they should be maintained. It puts many people off, me included.
> The Engineering Working Group (EWG) of the OSMF has “commissioned” (I think that’s OSMF language for paid) a longstanding proponent of rules and complexity to, uh, investigate how to add rules and complexity to OSM.
> [...]
> Let us pray that the EWG is just throwing Jochen a bone to go play in the corner and stop annoying the grownups.
> The harder you make it for them to edit, the less volunteers you’ll get.
And that is why dedicated area type (rather than representing areas with lines or special relations[0]) could help new mappers and new users of data.
There would be very significant transition costs, but maybe it would be overall beneficial.
It is possible to have objects that are both area and line at once. Or area according to one tool/map/edtor and line according to another.
And many multipolygon relations are in inconsistent state and require manual fixup.
Also, complexity of entire area baggage makes explaining things to newbies more complex. You can either try to hide complexity (used by iD in-browser-editor) leaving people hopelessly confused when things are getting complex or present full complexity (JOSM) causing people to be overwhelmed.
1000 times yes! I am a spatial data expert but only a some-time OSM editor and I still have yet to figure out how to create a polygonal feature more complex than a single building footprint. The theoretical advantage of a unified topology model of just nodes/edges where polygons and lines share core geometry is nullified by cultural rules that say "don't do that" to editors (I had a bunch of parks that shared a boundary with a road reverted with nasty notes). The current setup is not just hard for processors, it's hard for non-experts to understand and therefore a higher barrier than a simple polygon model would be.
I know it’s nothing to do with the main thrust of the article, but the author fundamentally misrepresents KYC. Know-your-customer is a facet of anti-money laundering and anti-corruption regulation. It has nothing to do with talking to users.
I’ve started playing with data from OpenStreetMap. It started with me trying to fetch all the places where I could get water when moving around Copenhagen, which turned out not to be as easy as first envisioned, because OSM seems to have a lot of different ways to categorise available water, which makes sense, OSM and the tagging system isn't there to support only my usecase, and describing my idea doesn't fit 1:1 with the model.
It's a tough problem to map out the world and describe it, especially when everyone can add or modify the data, but anything that could improve the experience of importing like osm2pgsql would be welcome.
I don't understand how this doesn't fit your use case. The tags are for different things, e.g.
> for places where you can get larger amounts of "drinking water" for filling a fresh water holding tank, such as found on caravans, RVs and boats
versus
> a man-made construction providing access to water, supplied by centralized water distribution system (unlike in case of man_made=water_well [...]). The tag man_made=water_tap is used for publicly usable water taps, such as those in the cities and graveyards. Water taps may provide potable and technical water, which can be specified with drinking_water=yes and drinking_water=no.
And another tag for when you're not mapping a separate water point, but indicating whether a given feature has drinking water (for example a well or mountain hut).
You're saying that it's tough when anyone can mess with the data rather than working in a structured way, but these tags have distinct definitions and seem perfectly sensible to me (there are much worse examples like highway=track, which spawned huge discussions in various places within the community). How do these tags not match your use case to select which tags you need and display those in the way you want (e.g. as list or map)?
I spent 20 months of my life traveling around Europe and Asia and I found the sources to fill up my camper's water tank mostly using OSM data! It works very well in most areas.
I used the the app Maps.me for that (which by the way I would not recommend anymore). Maps.me's internal search function is not intuitive but I found out the right key words to get to drinking water sources.
To your list I would add the search for springs. Especially in mountainous areas you often find usable springs (sometimes pipes coming out of a wall) with drinking water.
The exact same argument that praises OSM's super flexible tagged node data model should also praise MS Excel for the number of things that can be achieved in the world of business with just a grid of boxes.
Both have been hugely successful, and both have the same pile of downsides.
> Both have been hugely successful, and both have the same pile of downsides.
Exactly. And the solution should not be to throw away spreadsheets completely and turn them into relational databases, but to create new tools to alleviate the downsides and reduce their impact (possible by exporting the spreadsheet information into a relational database, but without taking away the user's option to continue working with it.)
The entire article can be summed up as: “OSM stores maps as graphs, in flat files where each line is either a node, an ordered list of nodes, or metadata. The graph nodes can be arbitrarily ordered in OSM files, which leads to computational complexity when parsing them. This is not a bad thing, since it means that the spec for OSM files can be extremely simple, which makes it easy for people to contribute to OSM. Other mapping formats optimized for parsing speed require a lot of irrelevant fluff that makes them much harder to understand by human contributors.”
Ironically, 95% of this article is irrelevant fluff that does not make it any easier for the reader to understand.
The claim that a dataset with billions of users has only dozens of people able/interested in doing data processing on it is a damning admission that the format is too hard to deal with
I maintain some OSM data-mangling code - moderately popular perhaps, but certainly not core - and even that has 840 github stars. I'd take the "dozens" as poetic licence really.
Dozens of open source volunteers who are interested in volunteering their free time to do software development using the format.
In addition to the innumerable developers in Facebook, Apple, and other corporations who are paid to do the data processing and actually bring the data to those billions of users.
The author is ranting a lot about OSMF's recent decisions, gives all kinds of reasons why they will undoubtedly lead to horrible consequences and grants sage advice what should have been done instead.
The only thing I'm missing is any indication that OSMF's course actually did cause any problems in reality.
What happened to the title? It used to be “In Defense of OpenStreetMap's Data Model”, which is the literal blog post title. Someone has now changed it to the boring-sounding “OpenStreetMap's Data Model”, probably resulting in fewer clicks.
Just for context, here is the current OSM data model in a nutshell:
There are three data types - nodes, ways and relations. All of the three can have any number of "tags" (i.e. a map<string, string>), which define their semantic meaning. For example, a way with `barrier=fence` is a fence. This stuff is documented in the openstreetmap wiki.
A node is a point with a longitude and a latitude.
A way is a sequence of nodes.
A relation is a collections of any number of nodes, ways or other relations. Each member of this collection can be assigned a "role" (string). Again, the semantics of what each role means is documented in the openstreetmap wiki.
To modify data, simply new versions of the edited data are uploaded via the API.
---
The most prominent point that stands out here is that only nodes have actual geometry.
This means that...
1. to get the geometry of a way (e.g a building, a road, a landuse, ...), data users first need to get the locations of all the nodes the way references. For relations, it is even one more step.
2. in order to edit the course of a way, editors actually edit the location of the nodes of which the way consists of, not the way itself. This means (amongst other things) that the VCS history of that way does not contain such changes
I have been looking into improving kerb and traffic_signals data for some bboxen. It is daunting, and I figure I need to work backwards - try to find out what the accessibility map apps look for and use those pairs. If I know what target I am shooting for I guess it will be alright. This is like my first week looking into this and I hope to find these targets soon.
> The harder you make it for them to edit, the less volunteers you’ll get.
I'm not sure I like OSMs obsession with the data model. I guess this has to do with its business model, but then let's not pretend the product manager is tasked to optimize for end-users.
I'd like it to focus on the UI. The easier it is to input a geographic thingie and the easier it is to visualize the geographic thingie, the better OSM both for users and volunteers.
Two issues to strengthen my point:
1. The osm-tag mailing list regularly discusses how tags are visualized in various renderers when recommending which to choose.
2. Quick mobile-based correction are nearly impossible with OSMAnd. I'd love to take a picture and write a quick note like "speed limit changed", so that someone (perhaps a bot) can pick this up and update the data model. Same with restaurant opening hours. Or various POIs.
Note: speed limit needs to be enabled, it is disabled by default. It is also unavailable in USA due to horrific default speed limit system which requires massive work to support.
Disclaimer: I am one of people working on StreetComplete
> I'm not sure I like OSMs obsession with the data model.
Given effort that went into various parts - fundamental data model has not received any changes for a long time. I would not describe it as obsession.
> I guess this has to do with its business model
OSM do not really have business model, it is not a business
It is surprisingly difficult to say which closed ways are areas and which are not. This depends entirely on tags of the way and is only solved by heuristics.
The current format stores locations and references to locations, so for example, a line feature only stores references to locations, so to realize it on a map, you have to go through the data and find all the locations it references and build up the actual geometric feature. So people do caching and so on, for sure.
The proposed changes would make that sort of data transformation easier and less resource intensive.
So, come up with an improved format that has/enforces various 'rules' and also provide a conversion program for moving between the new/old format, as desired.
Slowly deprecate the nastiest parts of the old, as people get used to the new format.
There's an amusing paradox I've seen many times amongst GIS managers - their complaints about how dreadful OSM data is are pretty much the direct opposite of their enthusiasm to use it!
Heh, their data model is 99% of the reason why I don't use OSM. It's scattered all over the place with so many tables! It's such a nice project, but damn is it impossible to work with programmatically, let alone poke around it to discover what's all in there.
There are various complaints about OSM data model but this is a new one to me. In OSM basically everything is mixed together and there is no real separation into layers.
zigzag312|3 years ago
>And that’s the point, rules and complexity have completely unknowable downsides. Downsides like the destruction of the whole project. With each rule and added complexity you make the system less human and less fun. You make it a Computer Scientists rube goldberg machine while sterilizing it of all the joy of life.
While too much rules and complexity can certainly be bad, some basic amount of standardization can actually reduce complexity and really doesn't cause a "destruction of the whole project".
As a counterpoint, too much flexibility can also increase complexity. For example, without defined rules, 5.6.2022 can mean 5. June 2022 or 6. May 2022. Nor user, nor parser can know for sure what it means, if standard isn't defined. This kind of flexibility certainly isn't fun.
Example from OSM wiki for "Key:source:date":
> There is no standing recommendation as to the date format to be used. However, the international standard ISO 8601 appears to be followed by 9 of the top 10 values for this tag. The ISO 8601 basic date format is YYYY-MM-DD. https://wiki.openstreetmap.org/wiki/Key:source:date
Just define some essential standards. It won't lead to destruction of the project!
And while you are making breaking changes, please fix the 'way' element. Maps are big. Storing points in ways as 64bit node-ids, while coordinates in nodes are also 64-bit (32bit lon and 32bit lat), just leads to wasted space and wasted processing time. There are billions of these nodes and nearly all of these nodes don't have tags, just coordinates. There is no upside for this level of indirection. And in case tags are needed for a point, this can already be solved with a separate node and a 'relation' element.
OSM data format could certainly be improved and it would benefit end users, as better tools/apps could be made more quickly and easily.
atoav|3 years ago
Of course projects like these have to strike a balance between the strictest bureaucratic nightmare and such a structure so loose that people are overburdened by the available options at every corner.
I think a lot of that complexity can (and should!) live in the tools themselves. Who cares about a date format, when the tool that creates it offers a date picker or extracts the correct date from the meta data of an image? The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input.
joshxyz|3 years ago
yyyy mm dd mm yyyy
[1] https://twitter.com/dan_abramov/status/1447710863960551433
RicoElectrico|3 years ago
For me Steve Coast lost his credibility when he joined the closed and proprietary what3words.
[1] https://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Mult...
jasonwatkinspdx|3 years ago
There's around 5.1e14 meters squared on the surface of earth. It takes 34 bits to address this uniquely. If we use one of EFF's dice words style short word lists (6^4 words), we need 5 words to describe any point on earth with 1 meter precision.
If we use a projection like say S2 (though plenty of other options exist), these 5 word locators will show strong hierarchical locality. In any specific area for example, there's likely only 3 distinct top level words. Likewise, the last word is useful but probably unnecessary precision for "find the building" day to day use. So the middle 3 words will be sufficient to be unambiguous in most cases, and if people used this system they'll naturally become familiar with the phrases typical to their locale.
All of this can be done with an algorithm a freshman cs student can understand, with a trivial amount of reference data. It can run on any mobile device made in the last 15 years without an internet connection.
I designed a scheme like this for fun years ago, just because it was a natural outflow of some stuff I was doing with dicewords for default credentials in a consulting context, and I just find spatial subdivision structures neat.
It's hard to interpret what3word's scheme as anything but craven rent seeking. They want to keep the mapping obscure, and fundamentally sacrifice usability in the interests of this. That what3words markets this specifically as a solution for low income nations, and dupes NGOs that are not tech savvy in the service of this is utterly #$%@$#ing revolting.
Imagine trying to rent seek on selling poor people their own street addresses, if you'll let me be slightly hyperbolic.
There is no reason a scheme like this can't simply be a standard from some appropriate body, and a few open source reference implementations.
TuringTest|3 years ago
"Be liberal in what you accept and strict in what you send" is still a good principle. The problem with rejecting invalid structures at the data storage format instead of a later validation step is that it hurts flexibility and extensibility. If later on you need a different type of polygon that would be rejected by the specification, you'll need to create a new version of the file format and update all tools reading it even if they won't handle the new type, instead of just having old tools silently ignoring the new format that they don't understand.
stevage|3 years ago
Then I got to the meat of it. Oh dear.
As one of the many many people who has had to deal with OSM data, I curse people with this attitude that the mess is somehow desirable or necessary. It's not. There is a long spectrum between totally free form and completely constrained, and OSM's data model is painfully down the wrong end, and causes enormous harm to all kinds of potential reuses of the data.
It also causes harm to the people creating data. Try adding bike paths and figuring out what tags are appropriate in your area. Try working out how to tag different kinds of parks, or which sorts of administrative boundaries should be added or how they should be maintained. It puts many people off, me included.
Bah.
delusional|3 years ago
Yet they've made an open source map, and I haven't. The data tells me that I'm wrong.
Sujan|3 years ago
> The Engineering Working Group (EWG) of the OSMF has “commissioned” (I think that’s OSMF language for paid) a longstanding proponent of rules and complexity to, uh, investigate how to add rules and complexity to OSM.
> [...]
> Let us pray that the EWG is just throwing Jochen a bone to go play in the corner and stop annoying the grownups.
It's a "response" to https://blog.openstreetmap.org/2022/06/02/announcement-data-...
everybodyknows|3 years ago
> Facebook solved this in a beautifully OSM-like way: daylight. Daylight is a sanitized, consistent and cleaned up map based on OSM
https://daylightmap.org/ https://registry.opendata.aws/daylight-osm/#usageexamples https://gist.github.com/jenningsanderson/3e42a99dcb8f760038a...
matkoniecz|3 years ago
And that is why dedicated area type (rather than representing areas with lines or special relations[0]) could help new mappers and new users of data.
There would be very significant transition costs, but maybe it would be overall beneficial.
It is possible to have objects that are both area and line at once. Or area according to one tool/map/edtor and line according to another.
And many multipolygon relations are in inconsistent state and require manual fixup.
Also, complexity of entire area baggage makes explaining things to newbies more complex. You can either try to hide complexity (used by iD in-browser-editor) leaving people hopelessly confused when things are getting complex or present full complexity (JOSM) causing people to be overwhelmed.
See https://wiki.openstreetmap.org/wiki/Area#Tags_implying_area_... for a start of a complexity fractal.
[0] https://wiki.openstreetmap.org/wiki/Area
pramsey|3 years ago
JackFr|3 years ago
myself248|3 years ago
matkoniecz|3 years ago
That is neither helpful, not useful, nor making me more likely to treat this diatribe more seriously.
NelsonMinar|3 years ago
kawsper|3 years ago
I identified the following tags to look out for:
amenity=drinking_water, https://wiki.openstreetmap.org/wiki/Tag:amenity%3Ddrinking_w...
man_made=water_tap, https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_tap
amenity=water_point, https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwater_poin...
drinking_water=*, https://wiki.openstreetmap.org/wiki/Key:drinking_water
It's a tough problem to map out the world and describe it, especially when everyone can add or modify the data, but anything that could improve the experience of importing like osm2pgsql would be welcome.
Aachen|3 years ago
> for places where you can get larger amounts of "drinking water" for filling a fresh water holding tank, such as found on caravans, RVs and boats
versus
> a man-made construction providing access to water, supplied by centralized water distribution system (unlike in case of man_made=water_well [...]). The tag man_made=water_tap is used for publicly usable water taps, such as those in the cities and graveyards. Water taps may provide potable and technical water, which can be specified with drinking_water=yes and drinking_water=no.
And another tag for when you're not mapping a separate water point, but indicating whether a given feature has drinking water (for example a well or mountain hut).
You're saying that it's tough when anyone can mess with the data rather than working in a structured way, but these tags have distinct definitions and seem perfectly sensible to me (there are much worse examples like highway=track, which spawned huge discussions in various places within the community). How do these tags not match your use case to select which tags you need and display those in the way you want (e.g. as list or map)?
jmkb|3 years ago
snickerer|3 years ago
I used the the app Maps.me for that (which by the way I would not recommend anymore). Maps.me's internal search function is not intuitive but I found out the right key words to get to drinking water sources.
To your list I would add the search for springs. Especially in mountainous areas you often find usable springs (sometimes pipes coming out of a wall) with drinking water.
londons_explore|3 years ago
Both have been hugely successful, and both have the same pile of downsides.
TuringTest|3 years ago
Exactly. And the solution should not be to throw away spreadsheets completely and turn them into relational databases, but to create new tools to alleviate the downsides and reduce their impact (possible by exporting the spreadsheet information into a relational database, but without taking away the user's option to continue working with it.)
gennarro|3 years ago
MontyCarloHall|3 years ago
Ironically, 95% of this article is irrelevant fluff that does not make it any easier for the reader to understand.
jtbayly|3 years ago
That is poor design for sure.
nkozyra|3 years ago
seoaeu|3 years ago
Doctor_Fegg|3 years ago
ciphol|3 years ago
In addition to the innumerable developers in Facebook, Apple, and other corporations who are paid to do the data processing and actually bring the data to those billions of users.
xg15|3 years ago
The only thing I'm missing is any indication that OSMF's course actually did cause any problems in reality.
teddyh|3 years ago
westnordost|3 years ago
There are three data types - nodes, ways and relations. All of the three can have any number of "tags" (i.e. a map<string, string>), which define their semantic meaning. For example, a way with `barrier=fence` is a fence. This stuff is documented in the openstreetmap wiki.
A node is a point with a longitude and a latitude.
A way is a sequence of nodes.
A relation is a collections of any number of nodes, ways or other relations. Each member of this collection can be assigned a "role" (string). Again, the semantics of what each role means is documented in the openstreetmap wiki.
To modify data, simply new versions of the edited data are uploaded via the API.
---
The most prominent point that stands out here is that only nodes have actual geometry.
This means that...
1. to get the geometry of a way (e.g a building, a road, a landuse, ...), data users first need to get the locations of all the nodes the way references. For relations, it is even one more step.
2. in order to edit the course of a way, editors actually edit the location of the nodes of which the way consists of, not the way itself. This means (amongst other things) that the VCS history of that way does not contain such changes
boredumb|3 years ago
uptime|3 years ago
matkoniecz|3 years ago
anticristi|3 years ago
I'm not sure I like OSMs obsession with the data model. I guess this has to do with its business model, but then let's not pretend the product manager is tasked to optimize for end-users.
I'd like it to focus on the UI. The easier it is to input a geographic thingie and the easier it is to visualize the geographic thingie, the better OSM both for users and volunteers.
Two issues to strengthen my point:
1. The osm-tag mailing list regularly discusses how tags are visualized in various renderers when recommending which to choose.
2. Quick mobile-based correction are nearly impossible with OSMAnd. I'd love to take a picture and write a quick note like "speed limit changed", so that someone (perhaps a bot) can pick this up and update the data model. Same with restaurant opening hours. Or various POIs.
matkoniecz|3 years ago
This can be done with StreetComplete (Android app) - long press on map to create note, photo can be added.
> Same with restaurant opening hours. Or various POIs.
You can also outright survey this with StreetComplete. See https://github.com/streetcomplete/StreetComplete
Note: speed limit needs to be enabled, it is disabled by default. It is also unavailable in USA due to horrific default speed limit system which requires massive work to support.
Disclaimer: I am one of people working on StreetComplete
> I'm not sure I like OSMs obsession with the data model.
Given effort that went into various parts - fundamental data model has not received any changes for a long time. I would not describe it as obsession.
> I guess this has to do with its business model
OSM do not really have business model, it is not a business
tinus_hn|3 years ago
RicoElectrico|3 years ago
https://github.com/tyrasd/osm-polygon-features
maxerickson|3 years ago
The current format stores locations and references to locations, so for example, a line feature only stores references to locations, so to realize it on a map, you have to go through the data and find all the locations it references and build up the actual geometric feature. So people do caching and so on, for sure.
The proposed changes would make that sort of data transformation easier and less resource intensive.
mring33621|3 years ago
Slowly deprecate the nastiest parts of the old, as people get used to the new format.
an9n|3 years ago
pete_nic|3 years ago
Great advice
unknown|3 years ago
[deleted]
chaps|3 years ago
matkoniecz|3 years ago
?
There are various complaints about OSM data model but this is a new one to me. In OSM basically everything is mixed together and there is no real separation into layers.
What you mean by "many tables"?
npteljes|3 years ago