3 ms·

> the longer it exists, the better the data will become. This is unfortunately not a given. The world changes constantly, and things like having up to date co

> the longer it exists, the better the data will become. This is unfortunately not a given. The world changes constantly, and things like having up to date coverage of restaurants require an immense amount of essentially ephemeral work to keep up to date.

ChrisMarshallNY 6y ago
That's why there should be a decoupled architecture. I am not an OSM expert. It may have this already. I am all for OSM, and sincerely wish it great success. What I do have, however, is experience in founding a worldwide, federated infrastructure that supports a fairly specialized (read: "small") demographic, but does that exceedingly well. It has become a worldwide standard, and is being taken to the next level by a team that doesn't really include me, anymore. It has a lot of structural support for federation. The idea is to push specialization away from the core as far and as fast as possible. The core is a relatively simple, tightly-focused, ultra-high-quality database engine, with a powerful semantic API. The services are addons that were written by some really energetic and skilled people that bring far more to the table than Yours Truly. In fact, these addons are what made the system suddenly become a "must have" for everyone. I'm assuming that OSM should have a "core mission" of geographic data, which is really just geolocation stuff. Basically, tagged locations. The tags can be used to relate the locations to external datasets. I would then assume that things like businesses, government services, and other geotagged datasets are attached as adapters to the "core," so they can be managed by others, who are specialized. Google does this (with arguable success) by letting businesses and individual users contribute data. I assume that it uses its own tools to aggregate and clean that data, and probably applies the data in an adapter fashion. This is what they are good at, and at vast scale and performance. Say what you will about them, but they do "big and fast" really well. I have found, through my own experience, that if I want local data to be accurate, it is important to let locals directly supply that data. In my experience, that started with an infrastructure designed for federation, and is realized by writing data harvesters that provide a rich, simple UI. Also, it is important to keep the core "pure." Specializations should be supplied at the adapter level; not by changing the core. For the most part, the central database schema of my system hasn't changed in ten years, but it does a lot more now, than I ever dreamed it would, back then. But that's just me. I don't think I'm anywhere near the level that many people live at. My experience is fairly small and humble. But effective.
- Twisell 6y ago
  I've once spoken to an OSM "evangelist" and he really struggled to get this point. In a way I got his point the OSM model can virtually store anything so it's the data provider burden to develop a glue code to interact with OSM. However because of potential vandalism or sheer goofiness objects and ids can potentially break at anytime within OSM so writing glue code is actually not trivial. Maybe a half way solution would be to promote generic glue code framework. I've heard about this project by a french local authority that help sync back data from OSM to your own database. Dunno if other similar projects exists. https://gitlab.com/Geonov/le-bon-tag https://gitlab.com/Geonov/le-bon-tag

ChrisMarshallNY 6y ago

That's why there should be a decoupled architecture. I am not an OSM expert. It may have this already. I am all for OSM, and sincerely wish it great success. What I do have, however, is experience in founding a worldwide, federated infrastructure that supports a fairly specialized (read: "small") demographic, but does that exceedingly well. It has become a worldwide standard, and is being taken to the next level by a team that doesn't really include me, anymore. It has a lot of structural support for federation. The idea is to push specialization away from the core as far and as fast as possible. The core is a relatively simple, tightly-focused, ultra-high-quality database engine, with a powerful semantic API. The services are addons that were written by some really energetic and skilled people that bring far more to the table than Yours Truly. In fact, these addons are what made the system suddenly become a "must have" for everyone. I'm assuming that OSM should have a "core mission" of geographic data, which is really just geolocation stuff. Basically, tagged locations. The tags can be used to relate the locations to external datasets. I would then assume that things like businesses, government services, and other geotagged datasets are attached as adapters to the "core," so they can be managed by others, who are specialized. Google does this (with arguable success) by letting businesses and individual users contribute data. I assume that it uses its own tools to aggregate and clean that data, and probably applies the data in an adapter fashion. This is what they are good at, and at vast scale and performance. Say what you will about them, but they do "big and fast" really well. I have found, through my own experience, that if I want local data to be accurate, it is important to let locals directly supply that data. In my experience, that started with an infrastructure designed for federation, and is realized by writing data harvesters that provide a rich, simple UI. Also, it is important to keep the core "pure." Specializations should be supplied at the adapter level; not by changing the core. For the most part, the central database schema of my system hasn't changed in ten years, but it does a lot more now, than I ever dreamed it would, back then. But that's just me. I don't think I'm anywhere near the level that many people live at. My experience is fairly small and humble. But effective.

Twisell 6y ago
I've once spoken to an OSM "evangelist" and he really struggled to get this point. In a way I got his point the OSM model can virtually store anything so it's the data provider burden to develop a glue code to interact with OSM. However because of potential vandalism or sheer goofiness objects and ids can potentially break at anytime within OSM so writing glue code is actually not trivial. Maybe a half way solution would be to promote generic glue code framework. I've heard about this project by a french local authority that help sync back data from OSM to your own database. Dunno if other similar projects exists. https://gitlab.com/Geonov/le-bon-tag https://gitlab.com/Geonov/le-bon-tag