Should we use OpenStreetMap as central POI repository?

As I understand TransforMap will build upon OpenStreetMap by creating (or connecting) points of interest (POIs) with basic information (name, website URL, location, address…) in OSM. This will allow to have a central database (and community) as hub to aggregate additional data for each single POIs querying data from other databases/sources.
My question is easy, why OpenStreetMap? Why not Wikipedia (geo-location can be added and with DBpedia we could semantically query properties)? Another database?
So far OSM has the issue of considerably restricting the type of content and bulk imports.
So why OSM? Not a loaded question, I’d really like to better understand the reason behind the choice (so I can also answer to those who will raise that question) :smile:

Wikipedia as Strong relevance criteria what they accept. Relatively short-living POIs like CSA pickup places will not fit their (especially in the German Wikipedia) requirements.

What I would support is to store longer descriptions (articles) in Wikipedia. It is already possible to link from OSM to Wikipedia (either directly or via Wikidata), and one can match from Wikipedia to OSM objects in the other way. But the POI must be ‘important’ enough for Wikipedia to accept it, e.g. the ZEGG (demo-maps, Wikipedia).

My arguments for OSM are:

  • It is the biggest free geodatabase - also for POI data.
  • Its content is not owned by any legal entity, but whole humanity - it is a Commons!
  • Its ODbL license allows easy usage on maps (e.g. in contrast to geonames, which is CC-BY).
  • OSM data is used on millions of devices, e.g. navigation systems - our POIs are automatically available there.
  • OSM data is kept up to date not only by us, but by millions of OSM contributors.
  • A really big ecosystem of APIs, tools and applications exists, and it is actively developed.
  • It is multilingual on default.
  • Features full history (version control) for data.

Yes, this is true, OSM is meant primarily for geo-data. That means you can map only what is visible on the ground.
It is therefore proposed to store all ‘ground truth’ data in OSM, and our own classification like ‘this is a Commons’ in our own databases, linking to OSM.

Yes. This is because OSM has reached a stage of maturity (that every growing database will reach at a certain point), where one cannot simply pour in data on top of existing because of a lot duplicates would be generated then!

Not far in the future, TransforMap will (hopefully!) also reach this point :slight_smile:.

Because there are billions of datasets already existing in OSM, there are strict import guidelines. More information can be found in this Discourse thread about How To import in OSM.

Ich wäre sehr dafür, den Titel in eine Frage zu verwandeln, da ja dazu kein Konsens herrscht.

Viele Datenpunkte / POIs , die zu Transformap gehören, passen weder in OSM, Wikipedia noch in Wikidata. Jedes dieser Projekte ist ein eigenes Commons, mit eigenen Regeln, welche Daten es aufbauen und pflegen will. Es gibt sicherlich mit jedem der Dienste eine Überschneidung, aber das ist es dann schon.

Wenn wir zum Beispiel die Commons-Bücher von @silke nehmen: jeder Artikel, der geographische Bezüge enthält, sollte in der Karte auftauchen. Keiner dieser so generierten POIs passt in irgendeines der obigen Dienste.

Jetzt einen weiteren Dienst zu erstellen, in denen dann Metadaten zu diesen Artikeln gesammelt werden sollen, ist keine gute Idee, denn: diese Artikel sind unter einer freien Lizenz veröffentlich worden und ab da hat niemand mehr eine Kontrolle darauf, wo eine (überarbeitete) Kopie im Netz auftaucht.

Deswegen finde ich den Vorschlag, ein Paradigma “Use UUID wherever possible” zu entwickeln und zu propagieren, so wichtig. Wenn schon in der ersten Veröffentlichung eine UUID als universell eindeutiger Anknüpfungspunkt enthalten wäre, dann wären die verschiedenen öffentlich zuegreifbaren Versionen aufeinander bezogen.

Als zweit wichtigstes Paradigma würde ich “Commoners, take responsibility for your own metadata” wichtig. Zu deutsch: lasst die Metadaten so nah oder am besten direkt in den Medien, die sie beschreiben. Und das ist zumindest für den geographischen Bezug sehr simpel, da es da ja nur um die angabe zweier Zahlen geht. Lasst uns darauf einwirken, Metadaten an Erstveröffentlichungsstelle dabei zu haben.

Ja natürlich!
OSM ist ja nur für Geodaten. Events z.B. passen da nicht rein. Die Idee ist, dass man den Ort (Veranstaltungsraum) in der OSM mappt, die Events in einer anderen DB, deren Eventlocation dann ein Verweis (Link) auf OSM ist.

Agree it would be great to keep OSM for geographic data and other metadata elsewhere.

What database(s) is Transformap using currently to store additional data?

1 Like

What is currently used on the demo maps is:

  • Wikimedia commons for POI images (it is common practice in OSM to link to Wikimedia Commons)
  • Wikidata is used to fetch human readable descriptions of the POI types (“garden:type=community” => “Community garden”) - but his is experimental at the moment, as there is unclarity in wikidata how to handle multiple OSM tags for one type of object.

The TransforMap Taxonomy is currenty stored in a JSON file, as we don’t have the DB ready for that yet.

As requested by Toka here: [quote=“toka, post:4, topic:744”]
Ich wäre sehr dafür, den Titel in eine Frage zu verwandeln, da ja dazu kein Konsens herrscht.

  • translated: I would rather change the topic-name, as there is no consent yet.[/quote]

I changed the topic name from “Why do we …?” to a more open question “Why should we …?”

And it is a very good question. There are many good arguments. People also already voiced arguments against, so we should get as much informations on that as possible, to take an informed decision!

(I’m wondering whether this discussion belongs to this FAQ in the end and not an own thread under Engineering. My rationale is that there seems to be no alignment on that specific question.)

I’m wondering whether locating data in OSM is not something that should happen at a later stage (i.e. when we managed to create a federation of maps that exchange data and that you can see under a map aggregator). A large number of duplicate POIs (between the maps) would have been already sorted out then (UUID). TransforMapS would have then the community (federated maps) to actually run the incremental effort of importing data into OSM, to enrich the largest geodata commons, and make alternative economies more visible there. @toka @species @almereyda?

1 Like

IMHO Data stored in OSM should be equally federated as data stored in other repositories.

But additionally, plugins designed to collect data in different repositories, could be evolved into tools, which support sharing part of the data into other repositories.

For example: Mietshäuser-Syndikat uses Wordpress + OSM Plugin to publish a map of their projects.
They publish three “layers”, running projects, planned projects, abandoned projects.
Only the first layer (running projects) would be a candidate for a linked object inside OSM.
I do not know much about the OSM Plugin, but in principle such a plugin could publish into OSM directly for specific content types.
While creating a coordinate for a piece of information, by checking an option, this data could be send to OSM. If the page is edited again, the plugin could check, if the linked OSM object still exists, was changed or changed to some other object, describing the same resource.

1 Like

I agree, that it would better fit in engineering and will move it there.

Actually just reading and translating the letter from Daniel Janz last year, I got the impression, that there was a common understanding, to have OSM as one of the central POI repositories for quite some time, and but needs revision before we would start any production.

@alabaeye you mentioned, that @Luca had some concerns or rejections with using OSM as POI database. @Luca could you specify that?

There is two perspectives here:

  1. One of the data publishers who maybe don’t want to give up control of their data.
  2. OSM which maybe doesn’t want to store all the POIs offered to them.

We’ll find many more reasons for and against centralization of geo data. In general we assume

3 posts were split to a new topic: Using Wikidata for identifiers, storage and metadata aggregation