-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Frederik,
The outline of your mail is clear. And I hope I can give some input, that could give relativation to some of your points. Op 24-12-11 14:02, Frederik Ramm schreef: > 1. Strict Tagging Rules You make a few clear points from my understanding: 1) The lack of strict rules, result in the lack of documentation for new people. Nobody knows what is correct, so what to teach junior mappers? 2) Editors who take the time to document, write it in their own vision. 3) Statistics say that bot programmers make the most edits, so if the programmer structurizes one combination, the stylesheet men follow. With your analogy of a superorganism - it is not really important what the sensory part of a single organism observes, it should find an encoding. Given the gained structure, the structure can evolve to something workable. It doesn't matter that 100 different mappers, tag the same in 10 different forms. The fact that it is tagged - thus gained structure - could allow a queen-mapper to re-tag the structure to consensus, which then gets statistically speaking more traction because it is the most common used form. Your point is important, but is it semantically speaking: a show stopper? I sincerely doubt it. As you already pointed out, regarding the low hanging fruits. Just apply that to this problem, new people: easy non-ambigious things. And if they want to sponsor an other not yet categorised subject, show them the process how it works, and please: just let them edit. Adding information in an 'uncommon way', isn't wrong information. Maybe automatic retagging should be made more trivial, as mentor for example. > 2. Imports and the Community Given that we do have a lot data ourselves, and completion isn't a target is some parts of the world anymore, while maintaince will be forever. A focus on data integration should be pursued. If imports are only about 'wow, so now I can render (and edit) data of the government in 1990 in mapnik', ditch that philosophy. Get OpenMetaMap on steroids and find a way to be able to *contribute back* on the original data license of that government. We would be a geographic wiki system, using all our tools, facilitate that! Get forks of OpenStreetMap running everywhere with different licenses based on themes of data, and a way to make one map out of that. > 3. Level of Detail, Relation Overload Again a thing were the OpenMetaMap philosophy kicks in. Why should all the data that you want to be rendered and edited inside a massive database on a single system (inside a single editor session)? It is not a relation overload: its information overload. People should be able to download relevant data when they are editing. It might be up to the editor what is relevant for a specific use case, but an API could facilitate this by allowing XAPI like requests having specific themed features for a box request on live data. I am very for multiple layers of data, that can semantically be related between the underlying foundations. This would bring innovation in OpenStreetMap and not only 'hard work'. It is strange how in the last years (academic) automatic editing and update efforts are ignored, and the only academic efforts that were embraced were related to the use of the data, hence: routing, which is not even the core business of this project. > 4. Data Model Changes & Technology Datamodel; nothing to add, needs fundamental rethinking. I would actually suggest: a declarative extensible standard. While the last hacking weekend in the Linux Hotel, we created some thing that could data replicate any tile server, without the need for all the extra tables, osm2pgsql etc. For people only doing tiles, this is a much faster approach. Doing might indicate OpenStreetMap, the data project, support tile business as 'postprocessed' form of its data. This could speed up the deployment of tileservers, and loadbalancing though. Another distribution thing, the minutely stuff, why not do these kind of things over XMPP using OSM-XML or PBF (a la Wave). This would also reduce the load and gives anyone realtime updates using standard software without the need for a zillion scripts. > I'd love to find that all the problems I listed here turned out to > be non-problems in the end, and were somehow solved automatically > along the way. It wouldn't be the first time for me to think > something is a problem and OSM took it in its stride. Maybe > mentioning the issues already helps to achieve that magic. Thanks for writing this email :) > Merry Christmas, or whatever you're having - Likewise Frederik, lets make it a productive and innovative 2012. Lots of things to tackle :) Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk716oMACgkQYH1+F2Rqwn2k5wCfa9WIxbJTSx7DTpIudUQmRIpl tCYAn3WeaOMN7e26iWRiOJqqP6rfyUib =3oJu -----END PGP SIGNATURE----- _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
