From OpenStreetMap Wiki
Jump to: navigation, search

Cannot by nature coexist

Tim, you are pro forking and seem to be unwilling to account for the significant (for all practical purposes insurmountable) technical and political hurdles in creating long term workable coexistant forks. -- Firefishy 18:26, 31 August 2010 (BST)

I'll backup my case briefly.

  1. UMP-pcPL is a CC-BY-SA licensed mapping project started in Poland, OSM has benefitted importing some sets of the data and visa versa. Cross data sharing has stagnated due to the difficulty in merging. UMP-pcPL seems to lack attribution of OpenStreetMap sourced data.
  2. GeoBase Import. This has been going on for approaching 2 years and still the process is going on. GeoBase data is a set in stone dataset but the difficuly of one dataset moving makes merging nightmarish. Two diverging + moving datasets make the problem exponentially more difficult.
  3. NaPTAN bus stop data import. The import has cause the level of bus stop mapping to dropoff with the imported data stagnating.

TimSC's response:
Firstly, try to avoid bringing me into the argument - it's ad hominem and it's off topic. I suggest you just make your case. Stating that I am "unwilling" to accept your argument without backing that up with facts fails to assume good faith. Even if you somehow show I am irrational, it has no bearing on the issues surrounding the topic we are discussing, which is forking.
I have not said that the technical challenges are of no consequence. I have attempted to rebut faulty arguments. That doesn't mean I don't accept the conclusion. In fact, I have said on multiple occasions that the resources required to face the technical challenge is the main reason against forking.
Your point that the challenges are insurmountable is worth discussing but I have not seen the case made. Since you are a sysadmin you would be an ideal person to full in the section OSM Resources Would be Better Used Elsewhere on the wiki. Or shall I just cut and past your mailing list post? [1] Obviously, I will comment on that section on the talk page, once it gets written.
Your argument above seems to be incomplete to me. You have premises: "import has caused data to stagnate", "merging active databases is exponentially difficult" and "UMP-pcPL lacks attribution". You have a conclusion "Forks Cannot by nature coexist". You don't have a logical argument that connects them and I can't see how it can be done. Merging data between forks is not absolutely necessary for forks to remain active. I also don't agree with your premise that imports always fail or are completely worthless. OS Opendata has proved to be quite useful.
I might argue that "UMP-pcPL project is active", "OSM is active" therefore "forks coexist" therefore the statement "Forks Cannot by nature coexist" is false. (I am using the definition of "fork" as stated on the article page.) But I am not really familiar with UMP-pcPL, so you might be able to disagree? Not sure.
Regards, --TimSC 18:54, 1 September 2010 (BST)
By stating there is a branch & trunk and 'coexisting' I would assume you intent for there to be data sharing. I have quoted above cases to show that data sharing is not as easy as your statements would seem to imply. -- Firefishy 20:26, 2 September 2010 (BST)
I have outlined the background on the article page including this issue. I would be interested if you think I have given a balanced view on that page. I said importing data is a "laborious and very tedious task". Do you think that's reasonable? --TimSC 10:47, 3 September 2010 (BST)
I'll opt out. I feel too strongly against forking for me to be properly balanced. Maybe add some sort of split (colour?) between the pro and con entries. Also the first entry: 'Multiple Databases Fulfil Different Mapping End Users Needs' has a contra, one database is a strength, all the data works together and different 'sets' of data from the database do not conflict. --Firefishy 16:49, 3 September 2010 (BST)

Fictional planets?

This may not be quite the right place to ask this question, but I'm curious if there are any alternative databases to use apart from the main OSM one? I'm thinking of purely fictitious worlds, or moons, or Middle Earth, or humorous satire historical maps, or futuristic islandscapes?

If somebody wants to illustrate OSM software, such as JOSM or Mapnik, but doesn't want to reference real places or be constrained by the BY-SA restrictions, it might be interesting to construct an artificial map to show the basic principles, but all based on completely fictitious PD data.

Does such a thing already exist as a joint project? Is the data (or even better, the rendered tiles) available anywhere?

--Eric2 15:56, 28 March 2012 (BST)

One place you can play around is in the test API: . This is a test deployment of The Rails Port including the website, separate test user accounts, and a test database. However it doesn't include a test tile server, so the tiles you see there are not rendered from the data present in the test database. There isn't much data present in the test database. This means if you zoom in on a bit of map, and then swap to potlatch or the data view to see the data, it will not correspond. Also means if you create an imaginary world in Potlatch, you don't get to see it as a rendered map unless you render it yourself. Also bear in mind that (although generally I would't expect it to happen) the test database may be taken down, or even wiped at short notice, or it may be broken. It is for software dev/testing after all -- Harry Wood 15:16, 29 March 2012 (BST)
Thanks for your answer. I'm kind of surprised that there isn't such a thing already, kind of like a community SIM-city crossed with minecraft crossed with a Dubai building project or a fantasy novel... I'm sure there are a few fictional cities or worlds with a sufficiently geeky fanbase to try something like that. Or the uncyclopedia crowd with time to spare. I guess there's not too much to map on Mars though, apart from the major peaks and landing sites (and the canals).
I've no idea how tricky it is to set up rendering, but I see there are a lot of different options. I was just hoping that something similar was already setup somewhere. Eric2 16:46, 30 March 2012 (BST)