Hi, On 01/03/2015 06:22 PM, Chris Hill wrote: > What about the maps I produce for my client? You're not likely to know > about it as it is a private project. If you make a mechanical edit that > breaks my render, should I send the bill for the changes to you rather > than ask my client to pay?
That is an interesting question and far, far broader than a mechanical edit. For example, it is very likely that with API 0.7 we'll be introducing an incompatible change to how areas are mapped. We (as in the OSM project) will probably make the effort to update the stock software - major editors, osm2pgsql, osmosis and so on, and popular open source software like OSRM will be easily upgraded, but we are meanwhile so popular that there will be tons of OSM-based applications out there somewhere that will just fail (and the developers have meanwhile moved on). There will be an outcry (cf. the "maturity" discussion in another thread): "How can you be so irresponsible to make this change, don't you see how this ruins the application, now who's going to pay for it, we expect that you provide at least one year's notice and keep a compatible API for at least another year to give us time" etc.etc. Personally - while I am very adverse to mechanical edits for other reasons - I believe that OSM always comes under a "take it or leave it" policy, and we cannot (and should not strive to) offer any guarantees that something you build today still works tomorrow. This doesn't mean that we should randomly switch around tagging just to make life more difficult for people, but if there is a good reason for a change, I think "data consumers might have a problem with the change" should not be an reason we consider or else we're close to total stagnation. Of course that doesn't mean that we should make life hard for data consumers *unnecessarily*. But at the same time our current tagging scheme is always a draft and subject to change at any time. Or perhaps more precisely - subject to evolution. And that brings me back to mechanical edits; those are usually not evolutionary and therefore I tend to dislike them. A good technical solution to this whole affair could be a system where you could "subscribe" to tags. Some of you may have noticed that Taginfo now supports a list of which-project-uses-which tags here: http://taginfo.openstreetmap.org/projects -- Suppose you could do something like this but non-public, for example Chris could register his interest in pipeline tagging somewhere, and would get an automatic notification if there is any major mechanical edit or tagging change that affects pipelines. Now it wouldn't be important for Chris since he's following what happens on the lists anyway, but there might be 20 other people who have set up something that regularly processes pipeline information and who haven't told anyone and aren't reading here. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk