From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss EN:Switzerland/DIDOK here:


How accurate is the DIDOK data in this import? I notice it has this bus stop half way up a mountain!:

-- Harry Wood 16:32, 26 January 2011 (UTC)


Since publication of DIDOK data on several maps, many corrections were made. Is there any kind soul out there who could make an up-to-date comparison?-- Gürbetaler (talk) 19:26, 16 April 2017 (UTC)

The comparison at is up to date. Please do NOT put Swisstopo in the wiki, this will get us only into trouble! I would suggest to ask on the swiss mailing list. Help with didok is always welcome. --Datendelphin (talk) 20:22, 16 April 2017 (UTC)
And why does nobody update the explanation if everything is up to date? And what trouble must be expected if mentioning Swisstopo? And what is the "Swiss Mailing List"?-- Gürbetaler (talk) 20:43, 19 April 2017 (UTC)
Well some things are forgotten sometimes. Swisstopo: we may not use data from Swisstopo, their license does not permit it. Non the less we often get people using Swisstopo as a source. This is difficult to track down and in the worst case a redaction is necessary which si painful. So we try to warn against using Swisstopo wherever possible. In the case of DIDOK it is unnecessary to mention so many sources, and harmful to mix allowed sources with prohibited ones. Swiss mailing list: Sorry I was so brief, I meant this: There are more people to read your comments and answer your questions. --Datendelphin (talk) 19:05, 20 April 2017 (UTC) (Swisstopo) is not a valid source, the web map of Swisstopo, is forbidden to be used as a source. Even though they display the data in question, there is no need to use it, and it may not be used for mapping. There are plenty of other, better UIs for accessing the data, which may be used for mapping. In order to avoid people mistakenly going to and using it for mapping, we should not link to it. As it is, the Swiss community already spends too much time tracking people down who use Swisstopo sources and revert those edits. --Datendelphin (talk) 19:00, 14 May 2017 (UTC)


DIDOK is a public list originally from the Federal Office of Transport (BAV), with railway, tram, bus, and some boat and cable transport stations in Switzerland. It is currently best accessed on the portal. It can also be viewed on

That is what I wanted to write. Now verdy_p has inserted "all official", and removed the "some" which I used to qualify boat and cable transport stations. There exist official stations which are not included in this list. As far as I understand, this list is relevant for pricing, time table and maybe subsidies. Why did you (verdy_p) change that? please explain. --Datendelphin (talk) 19:24, 14 May 2017 (UTC)

I have absolutely not suppressed anything, as you just did again (with your own preference to German-only when this page is actually in English and Switzerland is officially multilingual)...
As well you supressed the link to the official actualized map from the source, because you wanted to promote only another unrealted site that is not necessarily using the most updated data (even if it also allows comparing with other data sources including OSM)... This page is primarily about the DIDOC/DIDOK official datasource, and not about derived sites. Creating confusions between data sources will not help anyone. — Verdy_p (talk) 13:26, 8 July 2017 (UTC)
Hi verdy_p. Thanks for answering. Here my arguments again
  • This page is about the datasource which may be used. Swisstopo is forbidden. Using Swisstopo jeopardises the whole project, because it conflicts with the ODbL.
    COMPLETELY FALSE !!! There's absolutely no conflicts with maps. We don't use any map as source (except when explicitly licenced such as cadastral maps that we must still analyze and prepare to derive data to import). None of the two maps are importable, but DIDOC is a dataset that exists independantly of maps using it.
    "Jeopardize" ??? What ??? the dataset metadata directly gives an explicit usage right to the Swisstopo and references it as a reference rendering... This exists even before OSM now want to reuse the same data too: it would be OSM which would be actually "jeopardizing" the DIDOC project if you maintain your term. — Verdy_p (talk) 10:07, 9 July 2017 (UTC)
  • Swisstopo are the consumers. The construct for maintaining this data is of course complex. But SBB is mainly running the infrastructure for the list in question. I hope that will put your mind at ease that Swisstopo is in no way "closer" to the source or more "authoritative". It is forbidden anyway.
--Datendelphin (talk) 08:22, 9 July 2017 (UTC)
Swisstopo has data NOT ONLY from SBB. And it is NOT forbidden at all as a map (only as a data source for the additional data which is not in DIDOC). If DIDOC is legal for use by OSM, it is also perfectly legal for use by SBB or Swisstopo: we do NOT require any EXCLUSIVE licence to OSM for open data, so Swisstopo is not at all "jeopardizing" the project (not more than what we do with the same DIDOC data).
SBB is also not the only producer of the DIDOC list (which includes railway from SBB, but other transports too).
The official dataset is directly referencing the Swisstopo map (not at all to the SBB map!) in its own published metadata: if the part of DIDOC coming from SBB is illegal, then DIDOC itself is also illegal for use in OSM and this project page is forbidden too. We need more accurate metadata with another explicit licence, but then none of the two maps are usable !
Note that the link to the Swisstopo map was correctly selecting the DIDOC layer (excluding others) to exhibit only this dataset, but this is still not what we import.
Do not confuse map licenses and data licenses: we do not use any other external maps, only data. As well aerial imagery from Bing is NOT importable and not opendata, it is only usable to derive vector open data, but we do not own it. That SBB map show other items than cannot be imported, but the only purpose of both maps is to show a rendering of the DIDOC data. None of the two maps are data sources, they are just rendering with separate licencing. — Verdy_p (talk) 09:53, 9 July 2017 (UTC)
Probably you still have not read the actual official metadata describing the official source of the dataset:
And legal constraints:
it is explicitly owned by the BAV/OFT in Bern (, and "SwissTopo" is the official map service owned and operated directly by the BAV/OFT (on
Removing that link is just like removing correct credits to the source. DIDOC belongs to the Swiss administration, not to SBB (which is just one of the transport services that must (by Swiss law) provide data to the Swiss admin for publishing this joined DIDOC data). SBB is only a consumer (like us) of the DIDOC dataset, even if it contributes a part of it. — Verdy_p (talk) 10:53, 9 July 2017 (UTC)
BAV and Swisstopo are both related to the Swiss government, but they are not otherwise answering to each other directly. the trafimage map is cool becuase it uses OSM.
A map does not have to be "cool", it's your opinion but has absolutely no legal consequence. Your insistance is just exactly like spamming advertizing for a specific transporter (whic hhas no privilege at all on this dataset that does NOT belong to him: linking on to this specific SBB transporter and not the actual owner is competely unfair (against both the Swiss governement that finances and organizes theses transports, as well as for other competitors and involved operators). — Verdy_p (talk) 15:36, 9 July 2017 (UTC)
But we don't have to link to it, we have our own comparison map. You are mixing up a lot of things here. SBB has a lot of roles in all this. Maybe we can discuss this at the next Swiss stammtisch: DE:Switzerland:Zürich/OSM-Treffen There are other people who participate and you can hear what others have to say, apart from me. --Datendelphin (talk) 14:49, 9 July 2017 (UTC)
I'm not mixing things as much as what you do: SBB is only one transporter, and the data is not even sourced directly from them (they only haver to provide data to the Swiss government, that owns this data completely, and that then licenses it for use, in the same conditions for us as for SBB on its public website, because the data does not belong to SBB; the DIDOC metadata is very clear, SBB has absolutely NO privilege and the best credits are to the Swiss government which organize the public transports, while SBB only provides some means that the governement will finance, ot will delegate under contract to SBB, or to other competitors). The government's DIDOC list is also containing many data completely unrelated to SBB (not even railways, notably for urban bus lines, or navigation, or cable transports). SBB may have additional data but not part of DIDOC (because the Swiss law does not require that it be released publicly to the Federal office) and not licenced to us.
So effectively you insist on using SBB: you are completely confusing things: the link in question is for a map, not the dataset itself. The dataset has a reference WMS server, part of its official publication metadata, and this WMS server is NOT from SBB, but completely part of the federal Swiss geographic portal.
The map you want to keep is a separate private website from SBB (including the SBB logo at top of page!), for which we absolutely have NO right to use it (and this is not from this map that we take the DIDOC dataset, SBB (just like OSM) is just a consumer of the dataset fully owned by the federal office that provides licenses to us, to SBB or any other operators in Switzerland, or even to other competing commercial maps including Apple/Google/Bing/Nokia/Facebook...).
And you have abusely used the term "jeopardize" above: you were competlely wrong because you are confusing entities, and confusing distinct licences (on dataset or map rendering), and not reading the accurate metadata.
Your repeated removal is in fact abusive: you are incorrectly crediting the actual source of the dataset (it is definitely not SBB, only one of the contractors working for the Swiss government!!!) by crediting a consumer of the data, instead of crediting the actual legal owner. And the DIDOC list contains data where SBB is completely excluded (including data related to services in relations with bordering countries around Switzerland, made by international cooperation at governmental or regional authority levels that preferably work with other transport companies: SNCF and Keolis in France, DB in Germany... same thing with Italy and Austria). — Verdy_p (talk) 15:27, 9 July 2017 (UTC)
@verdy_p could you please state in one, two coherent sentences what your point is? And please do that without insulting datendelphin who has been responsible for the DIDOK data in OSM since the very beginning, long before it was reorganised into the current format and distribution channel (and who has been in contact with the data source side many times). SimonPoole (talk) 18:07, 9 July 2017 (UTC)
Note that I have not insulted him (and did not contest, until now, his work on following the DIDOC data integration in OSM). He used himself first the "jeopardize" term and I demonstrated he was wrong (the SBB site is not ODbL-licenced, it is full copyrighted) ! He said I was confusing things buit I've shown he has confused many more things. He concentrates on "coolness" but this is absolteuyly not relevant.
Each time I added a single sentence, but the arguments are always thez same: SBB is NOT the owner and provider of the DIDOC datasource, it only contributes to part of it as an operator because of Swiss law. The datasource has a metadata, which clearly shows the same links to the federal sites, and nowhere any site of SBB (which is not the data owner).
The metadata is clear. The official map to render the map is the one seen on the federal Swisstopo; the SBB map is derived from this (just like our OSM maps) but is not the DIDOC datasource. Citing only SBB would be extremely unfair (advertizing only one of the operators, but not the actual legal owner of the data). We cannot use any SBB data (that has not licenced anything to us, and cannot do that for the DIDOC data which SBB does not own), we use the DIDOC list because it is opendata licence is granted to us (and to SBB) by the Swiss federal authorities that must be credited properly.
Now if datendelphin contests the right to cite the only official federal source (he incorrectly affirms such citation is "fordidden"!), then we simply cannot use the DIDOC data at all, and this large copyvio will have to be removed completely from OSM (and what datendelphin did since the begining was just waste, is necessarily forbidden too: if he continues, he is in fact challenging the legality of his own work!). We cannot use import anything in OSM without properly citing the sources to assert their legality and compatibility.Verdy_p (talk) 18:55, 9 July 2017 (UTC)
You are confusing things: this is not wikipedia, this is not an encyclopedic treatment of the datasets provenance, background etc etc, it is mainly a documentation of how the data was imported, long, long before it was available on the current terms, plus a couple of pointers to where the data is located now (which we currently only use for QA purposes). If you want to write a wikipedia article on the subject, more power to you, but please do so on wikipedia. We might even link to it from here then. SimonPoole (talk) 21:16, 9 July 2017 (UTC)
You add to the confusion by adding now (out of topic) Wikipedia in the loop... And the effective location of the data is not on SBB, it has NEVER been there. Basically crediting the source and naming it is a requirement, not a convenience, crediting someone else however is a legally sanctionable, this is abusive. Delphione repeatedly affirmed he was forbidden to credit FOT for this data: not only this not forbidden, this is required. the DIDOC data is not free/public domain, it is completely copyrighted and protected even if it has an open licence. Even the SBB transporter is crediting FOT. We absolutely don't need SBB for this dataset (any claimed licence/authorization for this data supposedly coming from SBB would be invalid), but we cannot ignore FOT for its required copyright credit, and for getting a valid licence...
All I made was to add only a basic link (the most accurate one) without removing the alternate map link provided, it was not at all an encyclopedic article ! Everyone credits the correct sources (the legal right owners), not just indirect consumers of data, why would it be different here ? Continue like this, soon we'll suppress crediting the cadastres/land surveys, or Bing aerial... and OSM will become illegal, and will close, or will get lot of refusals for licencing new data (because we won't credit the sources but someone else). This is a serious issue.
And if you say the page explains how the data was imported, there's no such detail. As well there was wrong pointers to its location (it has never been at SBB, except in derived formats but not exactly the same contents, and without a correct licence if that alternate format and content was used for importing in OSM). — Verdy_p (talk) 01:38, 10 July 2017 (UTC)
Another proof: the federal map uses the most recent DIDOC dataset (April 2017), when the other SBB map uses DIDOC dataset from 2015 only (out of date), patched by SBB for its own convenience (but these patches are not really part of the open DIDOC dataset, they are copyrighted SBB, not free, in fact illegal for use in OSM without a prior licence agreement: the SBB does not really uses DIDOC, it cannot be reliably referenced for it). Once again read more carefully the metadata associated with the dataset ! — Verdy_p (talk) 17:31, 12 July 2017 (UTC)
as has been pointed out to you already, this is not a wikipedia article, it is a page for OSM contributors, contains mainly non-open data, including the base map, and experience shows that contributors will assume that the data available there can be used for OSM. The only person claiming that linking to the SBB site causes any kind of issue is you. Please realize that the wiki is not your private property.SimonPoole (talk) 18:24, 12 July 2017 (UTC)
How can they assume that ? This map is a website rendering a map not a source usable in any editor. The SBB map is also not valid as a source, the data shown there is completely proprietary (except for specific layers such as the DIDOC and OSM layers). If you want a free map (excluding the bakground map used on both sites), use the existing OSM map rendererings, or use these sites with a blank background. Your selection of default layers on the SBB site (which includes things completely unrelated to DIDOC, and the fact that SBB uses an old DIDOC dataset) is not completely free. Whever you like it or not, the SBB site is invalid according to your own partial point of view. And you want to ignore that (and the fact that the reference metadata of the dataset correctly references the federal site, not SBB which is completely unrelated, out of date/unmaintained, then patched in a proprietary way, and in fact not correctly usable as a correct reference for DIDOC). You just refuse to cite the correct source and credit it correctly (this is really unfair and in complete contradiction with the OSM policy). I also contacted the federal office that also replied me that they supported only one map, but not the SBB map which is only a reuser working with the same licencing terms as you or OSM (we all have to use the same credits to the FOT). — Verdy_p (talk) 18:31, 12 July 2017 (UTC)
Lok at the bottom of the SBB map: "Geodaten © swisstopo (5704003351), © OpenStreetMap contributors, © SBB/CFF/FFS": the background map (Swisstopo) is also not free, as well as all other data (SBB/CFF/FFS). And they do not correctly credit the FOT (even if they are required to do it): the SBB site is non-conforming at all for DIDOC and should be the one to remove. — Verdy_p (talk) 18:37, 12 July 2017 (UTC)
As we're heading for the 33rd iteration of reverts without any progress, I reported this to an admin now. Hopefully the page will get locked for some time to allow for a cool down. Mmd (talk) 16:23, 21 July 2017 (UTC)
The page is locked for now. Please use the talk page to clear up the disagreements in a civilized way (i.e.: not by edit war). For starters, please try to understand what the other party is saying and tell the readers why you think that is either wrong or not relevant to the discussion. And listen to what the other party thinks that your position is and try to explain if you think you are misunderstood. --Lyx (talk) 21:14, 21 July 2017 (UTC)
in fact I heard, but there was absolutely no justification for deleting this required official reference. It's just one user that does not like this source but cannot see that his prefered source is not more free than the official one, and in fact really outdated and has never been authoritative. Everything I made was to make things clear about the real source that Datendelphin constantly wanted to hide for very obscure reasons that do not pass any arguments he opposed against the FOT (even if it's the effective ONLY owner of the DIDOC dataset) but not to the SBB (service which is definitely NOT free and has no more privilege than OSM or Datendelphin on this DIDOC data). This was confirmed by asking the FOT directly about this: SBB does not own any right on this data, SBB is not the producer, and the SBB map is not representative of the dataset as it is modified in a propriaty way and based only on an old outdated version of the dataset.
Read above the big strong dataset: I did not invent anything, all the references are in the real source of the data, where it is effectively and officially referenced and published. But he does not want to read these, he just trusts SBB for strange reasons I cannot understand,t without checking more. Even the SBB itself gives credit to the FOT, and the SBB background map is also completely proprietary, as well as all additional annotations visible in the SBB site (that are actually not part of the free DIDOC dataset).
Anyway I had absolutely not removed the secondary reference to SBB that Datendelphon likes, I jsut added the missing real auithoritative reference. Both can be compared side by side, but the SBB map is in fact NOT usable at all as a valid source in OSM, the way it is presented. Actually we don't need either map, because what is really imported in OSM is the dataset itself, not the maps, the link was just made to be informative (and fair for crediting FOT correctly).
THe only thing that Datendelphin did in this page was not useful, it was purely an hostile act of destruction, that should have been treated like normal vandalism against a citation which is in full conformance of our common practives and policies: being fair erverywhere in OSM about real sources, and not obfuscating them. Now I challenge what Datendelphin did, because I fear that in fact he has actually imported proprietary data in OSM without a due licence from SBB, instead of limiting himself to the DIDOC data: when he was hiding the real source, he probably did not want that we see that what he did was wrong and in fact not the free DIDOC data: hiding the source was made only to avoid any kind of comparisons so that no one would contest what he did based on the false reference presented.
You'll probably one day receive a legal order of SBB about the SBB data in OSM to have it deleted. Or from FOT wanting to cancel the licence we have on DIDOC because we have refused to credit them properly as the real owner of the DIDOC list (doing so with obstination is a valid reason for canceling our rights if we do not want to respect their open data licence). — Verdy_p (talk) 22:53, 21 July 2017 (UTC)

Requesting unprotection

Resolved: This edit request was answered.

I think requesting unprotection is uncontroversial, because User icon 2.svgVerdy_p (on osm, edits, contrib, heatmap, chngset com.) is blocked indefinitely and the protection was a reaction to edit warring which is over for a long time. I personally do not specifically want to edit this page, I just think that the protection is not needed any more. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:42, 31 May 2019 (UTC)

OOjs UI icon check-constructive.svg Unprotected. – Minh Nguyễn 💬 09:50, 19 June 2019 (UTC)