Re: [OSM-talk] MEP - pipelines
hi, the last weeks have been quite horrible here, but at least I managed to write some kind of framework for the MEP: https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Pipeliner as if there isn't enough on my shoulders right now, I've been called away on short notice for the next 6 weeks; I won't be able to contribute to the MEP until my return at the end of march. I'd be happy if some kind souls could contribute to the MEP proposal in the meantime, otherwise I'll hope to be able to continue it after my return. tnx cu ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On 09/01/15 13:12, Frederik Ramm wrote: Just to be clear, the core of my idea was some kind of subscription mechanism where you, as a data user, could say: I am processing these tags in my application and I wish to be notified of important changes. I wasn't even thinking about the input side of that, just describing the output side. I think that the two are somewhat related ... One needs a table of data from which to select what one wants to subscribe to. The service that supplied changes which affected a defined area was nice but seems to have stopped? Not looked to see why, but I used to get messages about changesets which affected my local area. If one has a database of tags which one can subscribe to and receive messages about updates to that is just another way of filtering update messages. The same database can be used to flag values entered which do not match the 'subscribed' list of accepted entries, and perhaps indicate where an update to one tag also needs secondary tags. One subscribes to a tag metadata mechanism which provides updates at one of two levels ... the metadata for the tag has changed, or data related to a particular tag has changed. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
Hi, (full-quoting as an exception here) Just to be clear, the core of my idea was some kind of subscription mechanism where you, as a data user, could say: I am processing these tags in my application and I wish to be notified of important changes. I wasn't even thinking about the input side of that, just describing the output side. Bye Frederik On 01/09/2015 01:59 PM, François Lacombe wrote: I think there is a big difference between getting information from templates (very guided and structured) and completely understand the whole wiki. Such software supplying information about tags would be to get them from the ValueDescription template and give a link to the wiki page if human want to read. Many osmose tests may be aromatically setup just by reading the feature restriction or the mandatory tags on a value description. The same from presets, renders, ... Cheers *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com http://www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux 2015-01-09 1:35 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com mailto:dieterdre...@gmail.com: 2015-01-06 13:34 GMT+01:00 François Lacombe fl.infosrese...@gmail.com mailto:fl.infosrese...@gmail.com: As Frederik suggested, I'm strongly in favor of software supplying information about tags. The wiki can be understood by humans but not so readable by machines. I am not against software supplying information about tags, but we shouldn't expect miracles, machines are not only bad at understanding our wiki, they are generally bad at understanding the world. ;-) Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
I think there is a big difference between getting information from templates (very guided and structured) and completely understand the whole wiki. Such software supplying information about tags would be to get them from the ValueDescription template and give a link to the wiki page if human want to read. Many osmose tests may be aromatically setup just by reading the feature restriction or the mandatory tags on a value description. The same from presets, renders, ... Cheers *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux 2015-01-09 1:35 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: 2015-01-06 13:34 GMT+01:00 François Lacombe fl.infosrese...@gmail.com: As Frederik suggested, I'm strongly in favor of software supplying information about tags. The wiki can be understood by humans but not so readable by machines. I am not against software supplying information about tags, but we shouldn't expect miracles, machines are not only bad at understanding our wiki, they are generally bad at understanding the world. ;-) Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
2015-01-06 13:34 GMT+01:00 François Lacombe fl.infosrese...@gmail.com: As Frederik suggested, I'm strongly in favor of software supplying information about tags. The wiki can be understood by humans but not so readable by machines. I am not against software supplying information about tags, but we shouldn't expect miracles, machines are not only bad at understanding our wiki, they are generally bad at understanding the world. ;-) Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
Dana 7. 1. 2015. 03:53 osoba Bryce Nesbitt bry...@obviously.com napisala je: While we're at it, it would be nice to have a database that allows going from the tagged item (e.g., fitness centre) to recommended tag. The iD editor has a nice internal feature called aliases, so a person looking to add a restroom will find the toilet preset. +1 We need something like those aliases, but centralised so all editors have the same presets, and data consumers don't have to dig around our wiki and taginfo to find what they need. Also, if data consumers use this potential online service to dinamically get the tags they need, their process wouldn't be vulnerable to these kinds of changes. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
Maybe derailling and off-topic but anyway I do agree... To be discussed on tagging, dev, ...? While we're at it, it would be nice to have a database that allows going from the tagged item (e.g., fitness centre) to recommended tag. The iD editor has a nice internal feature called aliases, so a person looking to add a restroom will find the toilet preset. +1 We need something like those aliases, but centralised so all editors have the same presets, and data consumers don't have to dig around our wiki and taginfo to find what they need. +1 Also, if data consumers use this potential online service to dinamically get the tags they need, their process wouldn't be vulnerable to these kinds of changes. +1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On 07/01/2015 5:37 AM, althio althio wrote: Maybe derailling and off-topic but anyway I do agree... To be discussed on tagging, dev, ...? While we're at it, it would be nice to have a database that allows going from the tagged item (e.g., fitness centre) to recommended tag. The iD editor has a nice internal feature called aliases, so a person looking to add a restroom will find the toilet preset. +1 We need something like those aliases, but centralised so all editors have the same presets, and data consumers don't have to dig around our wiki and taginfo to find what they need. +1 Also, if data consumers use this potential online service to dinamically get the tags they need, their process wouldn't be vulnerable to these kinds of changes. +1 I'll start a page today, based only on the Features page I cited in the first place. I assume that will be non-controversial. Then we can add to it. Do you think I should subscribe to the tag list and warn them? Tom Taylor TomT5454 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
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
Re: [OSM-talk] MEP - pipelines
On 1/6/2015 6:47 AM, Chris Hill wrote: If the new scheme is adopted in staged way that would be better than a single mass edit, though it can still break data use for people who don't follow OSM's mailing lists. I don't blame the proposer of the scheme; he's just following the daft guidelines in the wiki. He probably hasn't realised what a phoney, broken procedure voting is. Let's stop using voting. There's nothing wrong with voting - there just needs to be a well defined way to stage changes so that consumers are informed and can adapt to them as they come in. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
+1 with Mike, there is nothing wrong with voting. As Frederik suggested, I'm strongly in favor of software supplying information about tags. The wiki can be understood by humans but not so readable by machines. We can imagine that draft of presets or renders can be dynamically generated by software provided that a reference would be completed and maintained. *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux 2015-01-06 12:56 GMT+01:00 Mike N nice...@att.net: On 1/6/2015 6:47 AM, Chris Hill wrote: If the new scheme is adopted in staged way that would be better than a single mass edit, though it can still break data use for people who don't follow OSM's mailing lists. I don't blame the proposer of the scheme; he's just following the daft guidelines in the wiki. He probably hasn't realised what a phoney, broken procedure voting is. Let's stop using voting. There's nothing wrong with voting - there just needs to be a well defined way to stage changes so that consumers are informed and can adapt to them as they come in. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
A tagging scheme, that was already in use, was being changed by a proposal, supported by a small number of votes. Because of these votes the proposer decided that his tagging scheme should be adopted by a mass edit. That mass edit would have broken any use of the tagging scheme by data consumers. Surely data consumers are what we want. We want OSM data to be used, not just for rendering but for analysis, routing, research, planning and many more uses. Data reliability matters. If a tagging scheme just gets changed on an arbritary date, especially in a single step, we risk scaring away dara consumers - all for a change that there's no evidence that it's needed and supported by a small number of votes. Mappers matter too (even more actually) and changing tagging schemes confuses them too. Extending a tagging scheme is quite different, both for mappers and consumers. Let's stop this crazy idea that a handful of votes makes anything alright. It doesn't. Wiki voting is wrong, devisive and sometimes destructive. If the new scheme is adopted in staged way that would be better than a single mass edit, though it can still break data use for people who don't follow OSM's mailing lists. I don't blame the proposer of the scheme; he's just following the daft guidelines in the wiki. He probably hasn't realised what a phoney, broken procedure voting is. Let's stop using voting. On 6 January 2015 06:06:08 GMT, Bryce Nesbitt bry...@obviously.com 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? (This is not hypothetical I really do have a render using pipelines. I'm also using pipeline data to calculate approximations of distribution and aggregation). You'd rather face a tag fragmentation, and slowly see your data slip away? It seems in many cases it's a favor to have the data migrated to one tagging system as long as that change is properly coordinated. --- cheers, Chris osm user, chillly___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On 03/01/15 22:05, François Lacombe wrote: I include some mechanical edits as vandalism, other than that, vandalism has not caused me any problems at all. I was too. And I don't understand why a static snapshot can't help you regarding changes that don't suit your needs. Think about that in practice! Chris is currently ADDING new data to the database, using his current set of tagging rules and needs to update his view of the data as that is added. HOW can that be done if he is forced to take a static snapshot? There have been several comments about 'phasing things out' rather than simply point in the sand destroy that data. By all means introduce new or expanded tags, but only destroy data after there has been a period of time to allow a switch over. I don't like the way PHP handles some areas of 'improvement', but one does at least get a warning that something will be removed later. I would STILL prefer a database of approved tags rather than the random notes provided by the wiki, and this could then be used by editors to identify valid entries, and eventually flag up deprecated tags and values. The same database would provide a cross reference perhaps to what is rendered by a particular service, or recommend alternate ways of doing something. This is possibly a case for a separate API for the management of tag metadata? Nothing stopping private tagging, but controlling better the core tagging infrastructure and allowing MANAGEMENT of the evolution of tags. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
I'm a data consumer also. And I've faced tagging proposals that would break my imports also. In general while I think the tagging / wiki voting system is pretty broken, I also believe in mass re-tagging to make data more regular. While there's a one time disruption due to re-tagging, the promise of more rational data in the future makes it worth it. The least short term pain is to leave the old tags alone and introduce new tags, slowly eat away data. But that's also the most painful long term. Similar pain comes from deleting tags in the editor, as is done for Tiger data in the USA. We can imagine that draft of presets or renders can be dynamically generated by software provided that a reference would be completed and maintained. I have written a script that extracts from each editor (Merkator, JOSM, iD, Potlatch 2) and mapping tool (osmarender, mapnik) which tags they have as presets, and which tags they render. That could be a start to a a grand unification system. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On 06/01/2015 8:16 AM, Lester Caine wrote: On 03/01/15 22:05, François Lacombe wrote: ... This is possibly a case for a separate API for the management of tag metadata? Nothing stopping private tagging, but controlling better the core tagging infrastructure and allowing MANAGEMENT of the evolution of tags. While we're at it, it would be nice to have a database that allows going from the tagged item (e.g., fitness centre) to recommended tag. Maybe I'm missing something that already exists, but at the moment my understanding is that the Map Features page at http://wiki.openstreetmap.org/wiki/Map_Features is my primary resource. This provides the reverse mapping from tag to feature, and I have to search the whole page to get what I need in the other direction. If the mapping I need doesn't exist, I'll be glad to add a Wiki page containing it. It would obviously have to cross-reference advice on the Features page. Tom Taylor TomT5454 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
While we're at it, it would be nice to have a database that allows going from the tagged item (e.g., fitness centre) to recommended tag. The iD editor has a nice internal feature called aliases, so a person looking to add a restroom will find the toilet preset. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
Data won't slip away because it is not tagged; it will slip away because it is not linked. The linking process benefits from having less coordination. On Tue, Jan 6, 2015, at 06:06 AM, Bryce Nesbitt wrote: You'd rather face a tag fragmentation, and slowly see your data slip away? It seems in many cases it's a favor to have the data migrated to one tagging system as long as that change is properly coordinated. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
Am 05.01.2015 um 00:17 schrieb Lists: On Jan 4, 2015, at 21:11, Richard Z. ricoz@gmail.com wrote: On Sun, Jan 04, 2015 at 09:18:57AM -0200, Lists wrote: May I suggest the following work flow: 1) Agree upon 2 dates sufficiently spaced i.e. 2 weeks apart 2) First date, add the new tag, leave the old tag in the system. This will not break anything, and from that date data consumers know they can start migrating their renderers, harvesters, or whatever into the new scheme without loss of data integrity 3) Run sanity checks on the data, maybe manually correct slips such as type=sewer - substance=sewage if needed 4) On Second date remove the unwanted key, objects where the key should remain should have been flagged by now, and data consumers should all be on the new scheme also. 5) Define an interval to re-run the scripts if it is probable that anybody still might use the old scheme. it needs more flexible rules and generally the suggested 2 weeks are extremely short. I was just throwing out a suggestion for timeframe without thinking much about its feasibility, I agree that the timeframe might need to be longer, and that is for me an open topic for discussion. I will not myself take part in any mechanical edit, though I might be affected as a data consumer. +1 For example we still have many (not counted) culvert=yes even though it is considered obsolete since a long time. That might be that they haven’t done any mechanical edits, and that old data still are accepted in many data consumers Think some QA software could do the job but we need to request for it. JOSM's validator could even silently change or at least ofter an automatically change. In those cases (like here) when it is possible to have the old and new tagging in parallel the transition could be done in two steps long apart. I agree that it should be a two-step job +1 no problem to delete type=* so far but adding additional tags should be no problem. This should be the general rule for mechanical edits when migrating tagging schemes. Also make sure that editors such as Potlatch2, iD, JOSM and Merkaartor, all have corrected their presets by the second date. If old scheme is stuck in the preset than it is likely that old scheme will continue to be used. also to be considered if keepright or similar need adjustments I was mentioning a few sources I could get from the top of my head, I probably have forgotten a lot of them It is always depending on the support of as many different projects as possible but that is sometimes a lot of work. cu colliar 0xE8F56581.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
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? (This is not hypothetical I really do have a render using pipelines. I'm also using pipeline data to calculate approximations of distribution and aggregation). You'd rather face a tag fragmentation, and slowly see your data slip away? It seems in many cases it's a favor to have the data migrated to one tagging system as long as that change is properly coordinated. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
May I suggest the following work flow: 1) Agree upon 2 dates sufficiently spaced i.e. 2 weeks apart 2) First date, add the new tag, leave the old tag in the system. This will not break anything, and from that date data consumers know they can start migrating their renderers, harvesters, or whatever into the new scheme without loss of data integrity 3) Run sanity checks on the data, maybe manually correct slips such as type=sewer - substance=sewage if needed 4) On Second date remove the unwanted key, objects where the key should remain should have been flagged by now, and data consumers should all be on the new scheme also. 5) Define an interval to re-run the scripts if it is probable that anybody still might use the old scheme. This should be the general rule for mechanical edits when migrating tagging schemes. Also make sure that editors such as Potlatch2, iD, JOSM and Merkaartor, all have corrected their presets by the second date. If old scheme is stuck in the preset than it is likely that old scheme will continue to be used. Also data consumers must be aware when new tagging scheme is in the editor presets as that WILL affect their data. Aun Johnsen On Jan 4, 2015, at 09:06, talk-requ...@openstreetmap.org wrote: Rainer, others and myself should be focused on consistency, versatility of tags, doing things (like tag migration) once. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On Sat, Jan 03, 2015 at 05:22:17PM +, Chris Hill wrote: On 03/01/15 16:50, Rainer Fügenstein wrote: in accordance to the mechanical edit policy, I'd like to open the discussion on this list: a recently approved proposal introduced new tags for pipelines and marker [1] and changed an established tag: type=* was changed to substance=* The values may need changing, e.g. type=sewer become substance=sewage the main reason for this change was a (possible) conflict with type=* as used in relations. also, type=* was considered to be too generic to describe the medium flowing within pipelines. this requires a mechanical update of existing data: No, just because a handful of wiki 'votes' does not mandate a mechanical edit. handful of votes? The proposal was really hard to miss so everyone who wanted to vote did so. 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? (This is not hypothetical I really do have a render using pipelines. I'm also using pipeline data to calculate approximations of distribution and aggregation). there are friendlier ways to ask someone that you need more time to catchup with your private project after Xmas vacation. The change is reasonable and the use of type was suboptimal in this setting. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
Lists lists at gimnechiske.org writes: This should be the general rule for mechanical edits when migrating tagging schemes. Fair enough when there is a clear use that this fosters but it is unclear whether that is true here. As a community we have to make sure that trolls and others without our best interests at heart do not abuse our norms for there own ends. Also make sure that editors such as Potlatch2, iD, JOSM and Merkaartor, all have corrected their presets by the second date. If old scheme is stuck in the preset than it is likely that old scheme will continue to be used. Agreed. An example related to this is the continued type=* preset for trees in iD. -- Andrew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
AH Fair enough when there is a clear use that this fosters but it is unclear AH whether that is true here. As a community we have to make sure that trolls AH and others without our best interests at heart do not abuse our norms for AH there own ends. are you referring to me and the pipeline proposal? if yes, I'll withdraw the MEP proposal, since I don't want to be a troll. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
Rainer Fügenstein rfu at oudeis.org writes: are you referring to me and the pipeline proposal? if yes, I'll withdraw the MEP proposal, since I don't want to be a troll. Sorry not to make myself clear. The comment was not aimed at you and I would like to make clear that I support the mass edit that you are proposing and want it to go ahead. -- Andrew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On Sun, Jan 04, 2015 at 09:18:57AM -0200, Lists wrote: May I suggest the following work flow: 1) Agree upon 2 dates sufficiently spaced i.e. 2 weeks apart 2) First date, add the new tag, leave the old tag in the system. This will not break anything, and from that date data consumers know they can start migrating their renderers, harvesters, or whatever into the new scheme without loss of data integrity 3) Run sanity checks on the data, maybe manually correct slips such as type=sewer - substance=sewage if needed 4) On Second date remove the unwanted key, objects where the key should remain should have been flagged by now, and data consumers should all be on the new scheme also. 5) Define an interval to re-run the scripts if it is probable that anybody still might use the old scheme. it needs more flexible rules and generally the suggested 2 weeks are extremely short. For example we still have many (not counted) culvert=yes even though it is considered obsolete since a long time. In those cases (like here) when it is possible to have the old and new tagging in parallel the transition could be done in two steps long apart. This should be the general rule for mechanical edits when migrating tagging schemes. Also make sure that editors such as Potlatch2, iD, JOSM and Merkaartor, all have corrected their presets by the second date. If old scheme is stuck in the preset than it is likely that old scheme will continue to be used. also to be considered if keepright or similar need adjustments Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On Jan 4, 2015, at 21:11, Richard Z. ricoz@gmail.com wrote: On Sun, Jan 04, 2015 at 09:18:57AM -0200, Lists wrote: May I suggest the following work flow: 1) Agree upon 2 dates sufficiently spaced i.e. 2 weeks apart 2) First date, add the new tag, leave the old tag in the system. This will not break anything, and from that date data consumers know they can start migrating their renderers, harvesters, or whatever into the new scheme without loss of data integrity 3) Run sanity checks on the data, maybe manually correct slips such as type=sewer - substance=sewage if needed 4) On Second date remove the unwanted key, objects where the key should remain should have been flagged by now, and data consumers should all be on the new scheme also. 5) Define an interval to re-run the scripts if it is probable that anybody still might use the old scheme. it needs more flexible rules and generally the suggested 2 weeks are extremely short. I was just throwing out a suggestion for timeframe without thinking much about its feasibility, I agree that the timeframe might need to be longer, and that is for me an open topic for discussion. I will not myself take part in any mechanical edit, though I might be affected as a data consumer. For example we still have many (not counted) culvert=yes even though it is considered obsolete since a long time. That might be that they haven’t done any mechanical edits, and that old data still are accepted in many data consumers In those cases (like here) when it is possible to have the old and new tagging in parallel the transition could be done in two steps long apart. I agree that it should be a two-step job This should be the general rule for mechanical edits when migrating tagging schemes. Also make sure that editors such as Potlatch2, iD, JOSM and Merkaartor, all have corrected their presets by the second date. If old scheme is stuck in the preset than it is likely that old scheme will continue to be used. also to be considered if keepright or similar need adjustments I was mentioning a few sources I could get from the top of my head, I probably have forgotten a lot of them Richard Aun Johnsen ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] MEP - pipelines
in accordance to the mechanical edit policy, I'd like to open the discussion on this list: a recently approved proposal introduced new tags for pipelines and marker [1] and changed an established tag: type=* was changed to substance=* the main reason for this change was a (possible) conflict with type=* as used in relations. also, type=* was considered to be too generic to describe the medium flowing within pipelines. this requires a mechanical update of existing data: nodes: containing pipeline=marker nodes: containing pipeline=substation type=* -- substance=* ways: for man_made=pipeline ways: containing pipeline=substation type=* -- substance=* As of now, I'm only aware of the ITO pipeline map (rendering), that is affected by this change. this affects data worldwide. I assume that this update will have to be executed several times in the near future, as mappers may continue to use type=* until they are aware of the new pipeline tagging scheme. cu ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
Hi, Am Samstag, den 03.01.2015, 17:50 +0100 schrieb Rainer Fügenstein: in accordance to the mechanical edit policy, I'd like to open the discussion on this list: a recently approved proposal introduced new tags for pipelines and marker [1] and changed an established tag: type=* was changed to substance=* the main reason for this change was a (possible) conflict with type=* as used in relations. also, type=* was considered to be too generic to describe the medium flowing within pipelines. Some mappers used pipeline:type for the substance. http://taginfo.openstreetmap.org/keys/pipeline:type#values It is/was a recommendation to use xx:type instead of the confusing type tag (especially on relations). http://wiki.openstreetmap.org/wiki/Key:type Can you have a look at that pipeline:type tag, too? Regards Werner (werner2101) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
CH No, just because a handful of wiki 'votes' does not mandate a mechanical CH edit. OK, then we'll have split data. CH What about the maps I produce for my client? You're not likely to know what about changing the rendering rules after the mechanical edit? the purpose of this discussion is to let users like you know about the change. CH about it as it is a private project. If you make a mechanical edit that CH breaks my render, should I send the bill for the changes to you no. you're using open data here without any guarantees. CH What? your amazing wiki page might be ignored by some mappers? How dare CH they?! [censored] CH If you must have a mechanical edit (which I don't see as vital), why not CH add substance=* tag alongside the type=* tag? redundancy? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
I don't see any objection to do as Rainer suggested. Maybe someone can give us examples of conflict with any other data ? All the best *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux 2015-01-03 17:50 GMT+01:00 Rainer Fügenstein r...@oudeis.org: in accordance to the mechanical edit policy, I'd like to open the discussion on this list: a recently approved proposal introduced new tags for pipelines and marker [1] and changed an established tag: type=* was changed to substance=* the main reason for this change was a (possible) conflict with type=* as used in relations. also, type=* was considered to be too generic to describe the medium flowing within pipelines. this requires a mechanical update of existing data: nodes: containing pipeline=marker nodes: containing pipeline=substation type=* -- substance=* ways: for man_made=pipeline ways: containing pipeline=substation type=* -- substance=* As of now, I'm only aware of the ITO pipeline map (rendering), that is affected by this change. this affects data worldwide. I assume that this update will have to be executed several times in the near future, as mappers may continue to use type=* until they are aware of the new pipeline tagging scheme. cu ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On 03/01/15 16:50, Rainer Fügenstein wrote: in accordance to the mechanical edit policy, I'd like to open the discussion on this list: a recently approved proposal introduced new tags for pipelines and marker [1] and changed an established tag: type=* was changed to substance=* The values may need changing, e.g. type=sewer become substance=sewage the main reason for this change was a (possible) conflict with type=* as used in relations. also, type=* was considered to be too generic to describe the medium flowing within pipelines. this requires a mechanical update of existing data: No, just because a handful of wiki 'votes' does not mandate a mechanical edit. nodes: containing pipeline=marker nodes: containing pipeline=substation type=* -- substance=* ways: for man_made=pipeline ways: containing pipeline=substation type=* -- substance=* As of now, I'm only aware of the ITO pipeline map (rendering), that is affected by this change. 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? (This is not hypothetical I really do have a render using pipelines. I'm also using pipeline data to calculate approximations of distribution and aggregation). this affects data worldwide. I assume that this update will have to be executed several times in the near future, as mappers may continue to use type=* until they are aware of the new pipeline tagging scheme. What? your amazing wiki page might be ignored by some mappers? How dare they?! If you must have a mechanical edit (which I don't see as vital), why not add substance=* tag alongside the type=* tag? That way existing renders and other uses will not be broken. Mech edits that are presumably intended to improve the quality of OSM data can badly damage confidence in the data by breaking existing use. -- Cheers, Chris user: chillly ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
2015-01-03 18:22 GMT+01:00 Chris Hill o...@raggedred.net: The values may need changing, e.g. type=sewer become substance=sewage +1 indeed 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? (This is not hypothetical I really do have a render using pipelines. I'm also using pipeline data to calculate approximations of distribution and aggregation). The map your produce for private projects should be based on a static export of OSM. It will prevent any kind of vandalism to have impact on your valuable services. As data producer, may I ask you how can I refine any tagging scheme if so called private projects have priority on information improvement and general interest ? Rainer, I doesn't avoid you contacting supp...@itoworld.com (and maybe any other pipeline user) to inform them. If you must have a mechanical edit (which I don't see as vital), why not add substance=* tag alongside the type=* tag? That way existing renders and other uses will not be broken. Mech edits that are presumably intended to improve the quality of OSM data can badly damage confidence in the data by breaking existing use. Why not. It will maintain type=* on features which shouldn't be described with it and I think it's bad. If we do so, the wiki must be assumed as a reference. Because, when substance=* and type=* will be on every feature, who will be able to make the distinguish between them both ? All the best *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On 03/01/15 17:46, François Lacombe wrote: 2015-01-03 18:22 GMT+01:00 Chris Hill o...@raggedred.net mailto:o...@raggedred.net: 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? (This is not hypothetical I really do have a render using pipelines. I'm also using pipeline data to calculate approximations of distribution and aggregation). The map your produce for private projects should be based on a static export of OSM. It will prevent any kind of vandalism to have impact on your valuable services. Thanks for telling me how to run my process. Given that the data used in the project are being edited and are evolving and includes data other than the pipeline data that are being edited, a static snapshot won't cut it. I include some mechanical edits as vandalism, other than that, vandalism has not caused me any problems at all. As data producer, may I ask you how can I refine any tagging scheme if so called private projects have priority on information improvement and general interest ? If you must adjust tagging schemes that are in use, then you must devise a way to migrate to the new scheme in stages that doesn't break the existing processes that people use the data for. The proposer of the change is, IMO, fully responsible for this and if there is not a proper migration plan then the change should be quickly rejected. Simply replacing a tag with another tag via mechanical edit at an arbitrary point in time just isn't good enough to me. -- Cheers, Chris user: chillly ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
2015-01-03 21:18 GMT+01:00 Chris Hill o...@raggedred.net: I include some mechanical edits as vandalism, other than that, vandalism has not caused me any problems at all. I was too. And I don't understand why a static snapshot can't help you regarding changes that don't suit your needs. If you must adjust tagging schemes that are in use, then you must devise a way to migrate to the new scheme in stages that doesn't break the existing processes that people use the data for. The proposer of the change is, IMO, fully responsible for this and if there is not a proper migration plan then the change should be quickly rejected. Simply replacing a tag with another tag via mechanical edit at an arbitrary point in time just isn't good enough to me. I'm sorry, but I'm not very fond of bureaucracy. My unpaid contribution is entirely done in free time (like many MANY people here) and we won't spend it on personal interests considerations. As Rainer rightly said, you're using free data without any guarantee. My point isn't to not be user-friendly, but if I setup a smooth migration process for YOU, it won't necessarily suit your neighbour's processes. Why each data consumer can't adapt themselves and make an effort ? Mechanical edits aren't bad if they are prepared and users informed about it. Then a precise date can be discussed and everyone start using tags at the same tags without letting the old ones in the DB for years. Rainer, others and myself should be focused on consistency, versatility of tags, doing things (like tag migration) once. That's why OSM need a serious workflow refinement regarding tagging reference. This new one should include mechanical edits and communication about them toward data consumers. *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
