Re: [Tagging] RFD pipeline sub tag substance
I'd like to repeat once again that substance doesn't seem to be a nice key descriptor for values like ... during the draft stage, I (we) couldn't come up with an expression that covered everything that might one day be transported in a pipeline. content ... too static medium ... too spooky product ... is sewage a product? type ... too generic and already in use and what exactly is a neutron bean? etc. a native english speaker may come up with a proper expression, but I'd better not change this key once again. Oh.. 'multiphase' is a mixture of gas, fuel and water as it comes out of some well heads if this is the proper term used for pipelines, then this would be the right one, yes, multiphase is a term used in the oilgas industry for exactly this, uhm, substance. cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD pipeline sub tag substance
and what exactly is a neutron bean? correction: should read neutron beam ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD pipeline sub tag substance
Hello Warin, Wednesday, January 28, 2015, 8:48:16 AM, you wrote: W Request For Discussion W http://wiki.openstreetmap.org/wiki/Key:substance thanks for picking up thus topic. I have to leave in a few minutes for a 6 week assignment, therefore only just a few words: - my intention impression was that - as of now - substance=* is a tag to be chosen wisely (cough) by whoever needs it, but more definition structure is definitely a goal. - I was thinking of a kind of main type, sub type scheme, i.e. substance=fuel substance:detailed=kerosine substance=fuel substance:detailed=diesel substance=water substance:detailed=drinking_water etc. cu --- Je Suis Charlie ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD pipeline sub tag substance
hi, first, I wouldn't use the value of substance=* as key for the detailed level, because in this case we would introduce a new key (i.e. fuel=) whenever a new substance is introduced (i.e. substance=fuel). second, I'd stick with two levels (general, detailed), otherwise we'd eventually end up with a substance having 8 levels, down to the molecular structure. cu So for natural gas worked out to that basic level, as one example, that would be substance = gas gas=fuel fuel=natural_gas None of this colon/semicolon business that has got people so worked up :) And it may reduce the errors of tagging things like substance=fuel substance:detailed=drinking_water And it too gets around drinking_water as that becomes substance = liquid liquid=water water=drinking (or potable?) Other ideas? Kick them around guys.. brainstorm it. Oh.. 'multiphase' is a mixture of gas, fuel and water as it comes out of some well heads (as stated on the wiki). Interested to see any ideas on a good tag for that .. nice puzzle that one. Maybe it is the physics tag of multiphase as in containg all the states of gas, liquid and solid. Fits... anyone know? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - shop=electronic_parts
michal, MB I don't know whether re-using service=* key is a great idea, as it's MB normally used as a refinement to highway=service I took the idea from the shop=car wiki page. http://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar MB (Compare that with MB all these type=* issues where it collides with use of type=* on MB relations). you're telling me! ;-) cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] hrmpf.
andy, thank your for joining this list. S You might be surprised. that's nice to hear. finally, all the work may not have been in vain, after all ;-) S To be clear, I don't think that anyone's criticising the change itself, S just the notification of it. [...] but it would still have been nice for data S consumers to know that the change was happening. ever since the change from type=* to substance=* (and mount=* to support=*) was introduced, it was clear to me that a large scale mechanical edit of existing nodes/ways is necessary. and I am and was aware of the MEP from an earlier occasion. since I like to do things step by step, finishing the draft, open it for voting, incorporation of the approved scheme into existing wiki pages came first. the next step is the MEP, but holiday season doesn't really speed things up. the 13 wrongly tagged nodes came to me by chance, so I took the opportunity to change them. I'll move the MEP to the top of my TODO list, any help with the MEP is appreciated. tnx cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] hrmpf.
hey guys, can you please check the comments on this changeset: http://www.openstreetmap.org/changeset/27805365 short summary: manually editing 13 nodes is a mechanical edit that needs to be discussed in advance, this list here is unimportant, nobody reads proposals and 18:4 yes votes don't count. either I'm missing the point here or [censored]. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] hrmpf.
frederik, FR I think it's a slippery slope problem. Agreed that 13 nodes is not a FR lot. But at how many would you draw the line? 20? 100? 500? all 13 nodes have been checked and edited by me manually (not using search-and-replace). since this case is not covered in the mechanical edit policy, IMHO this policy does not apply. therefore, it should not matter if 13, 20, 100, 500 nodes have been changed this way. the main reason for the edit was the fact that those nodes contained both man_made=pipeline AND pipeline=marker tags, which was even wrong considering the old version of the pipeline wiki page. FR How many FR objects would you mechanically-edit without any extra discussion and FR solely based on an 18:4 vote in a tagging discussion? pipeline mapping is the field of a small minority of mappers. considering this logic, established tags in fields of minority interests can never be changed, unless it becomes the interest of the majority. apart from that, the main criticism is the change of type=* to sustance=* (which was also done in the changeset) as a result of the proposal. I see a point here, considering that the change of a tag affects map styles, software, ... as mentioned by SomeoneElse. I followed the proposal process step by step, and it does say nothing about notifying others. thanks to Matthijs for his research comment. cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] hrmpf.
hi, IJ Won't this apply to your change: no, because I still insist on the fact that changing 13 nodes manually is not a mechanical edit. neither by the (small) number, nor by the way it was done. the main critique here is that a tag was changed during the proposal process (type=* to substance=*). the proposal process was followed step by step, and it says nothing about consulting the MEP or any mailing list other than this. cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Accuracy of survey
W Ultimate 'accuracy'? You do realise that the tectonic plates are moving? btw: as a result of the Mar.2011 earthquake, japan has moved by at least 5m. how did OSM react? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] key:support, man_made=surveillance
hi, since the pipeline proposal was approved, I'm currently creating sub-pages for most tags used in the proposal. I took the liberty to create a page for support=* [1], as discussed earlier. two ideas: - support=* could also be useful for man_made=surveillance. the example picture in [2] prominently features a pole. - since surveillance cameras are often mounted on ceilings, I introduced support=ceiling. let me know if this is acceptable or requires a proposal. cu [1] http://wiki.openstreetmap.org/wiki/Key:support [2] http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsurveillance ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Accuracy of survey
TP It was not clear if the OP indeed wants to map pipelines, TP or was just quoting the pipeline expert for his opinion about TP surveying methods. the latter. I'm referring to all nodes, not just pipelines marker. Just used the conversation I had some time ago as an example. W Terms !! W In Metrology (http://en.wikipedia.org/wiki/Metrology) the words W accuracy, error, etc have specific meaning .. please forgive my ignorance - let the experts decide on a proper term to be eventually used as tag. dilution comes to mind, but that's GPS specific, if I'm not mistaken. FV Even if you collect plenty of GPS traces with no systematic error, these FV still cannot beat a theodolite triangulation. when specifying accuracy, the source of the coordinates shouldn't matter. It could be GPS, DGPS, theodolite triangulation, a file provided by officials or companies ... FV I used estimated_accuracy=* or gps_accuracy=* a couple of times, IMHO, that's the way to go. would recommend against gps_*, see above. also, there should be a distinction between estimated and actual accuracy. FV but I doubt FV that it prevents other mappers from moving or even deleting them. Some use FV editors like Potlatch, so they are not aware of tags. Some do thousands of FV edits, all of which are validator based corrections. They do not ask nor FV think nor look at tags, except at those reported by the validator. software evolves; if such a tag is considered useful and widely used, it may eventually be supported by the developers. of course, there'll always be the black sheep ... FV Also, there is no clear line between high and low precision data. Should an FV editor warn when the precision is better than 1m, but ignore a precision of FV 2m? This all depends on the precision of the new data, which the editor does FV not know. for starters, I'd begin with a general warning if the precision of the existing node is less or equal than 2m (thats better than what the average consumer receiver can achieve). to draw a line between high and low precision, this article [1] may be helpful. some GPS receivers show the current precision in meters; GPX files contain HDOP/VDOP/PDOP if provided by the receiver. In theory and if provided, when a GPX file is used as source for nodes, precision could be derived from this information (by whatever means). FV There are no GPS traces for pipeline markes. actually, there are ;-) I just didn't upload mine. but apart from that, pipeline mapping seems to be a few-(wo)men show, therefore it's more likely that pipeline operators may release their (high precision) data [2] before there are enough GPS traces to significantly increase precision via interpolation. cu [1] http://en.wikipedia.org/wiki/Global_Positioning_System (section Augmentation f.) [2] https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/PipelineExtension#status_update.2F1 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Accuracy of survey
MK maybe just add a note to the pipeline (note = maped mit GPS with MK guaranteed accuracy of blahblah). I'm rather thinking of something machine-readable, enabling the editor to warn the user in case he/she is about to change high precision data. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Pipeline Extension)
oh well, couldn't have done it with the valuable input from members on this mailing list and the guys on the proposals talk page. also a big thanks to Imagic, who tutored the very beginnings of the proposal, among other things. cu f Am 11.12.2014 um 23:25 schrieb François Lacombe: This is actually a great work. Thank you for the time spent to setup this document ! Good luck for this vote :) f +1 f Another nice example how it can work. f Thanks for your effort. f fly f ___ f Tagging mailing list f Tagging@openstreetmap.org f https://lists.openstreetmap.org/listinfo/tagging --- NOT sent from an iPhone ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - (Pipeline Extension)
hi, https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension is now open for voting. tnx cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Adding values to usage=* key for power transmission
let me sum this up: - loop=yes, a technical term in use and accepted by the pipeline industry (loop configuration), was voted down in favour of a more generic term, that can also be used in other areas (flow_direction=*). and also not to have one more tag. - mount=* was abandoned in favour of support=*, because it is already in use, and also not to have one more tag. - usage=* is discouraged, because it is already in use, causing to have one more tag. FL Thus, I'm not sure we should literally add power: or railway: or whatever FL before usage=* since all features concerned by my proposal and railway one FL will be tagged with power=* or railway=* ACK. the primary tag defines the object, and also defines the scope (namespace) of the secondary ones. consequently, most of the secondary ones would also have to be prefixed. man_made=pipeline pipeline:name=West 4 pipeline:flow_direction=both pipeline:usage=transmission pipeline:location=underground ... since all four secondaries in this example are (already) in use in other fields. cu FL *François Lacombe* FL fl dot infosreseaux At gmail dot com FL www.infos-reseaux.com FL @InfosReseaux http://www.twitter.com/InfosReseaux FL 2014-12-02 13:02 GMT+01:00 Rainer Fügenstein r...@oudeis.org: LS I agree with you if you say that usage LS sounds like a very general key and not a railway specific key. So the LS railway guys have just been a little faster than the power guys and LS occupied this key. I would accept this and search another key to avoid LS unnecessary conflicts. I dont insist in power:usage. It can also be LS something else, but I would introduce a new key for this. usage is discouraged because the railway guys already use it. network is discouraged because the bus/cycle guys alread use it. if this trend continues, we may run out of suitable words in the english language one day. what about system=* or purpose=*? even prefixed as power:system, pipeline:system? cu LS cu LS Lukas Sommer LS 2014-12-01 23:38 GMT+00:00 François Lacombe fl.infosrese...@gmail.com : Hi Lukas, I don't like this : railway guys introduced usage without any namespace. Why should power introduce one ? usage=* is a common tag. The proposal isn't introducing power:location instead of location=* even if there is some specific values. Do you agree ? *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux 2014-12-01 9:31 GMT+01:00 Lukas Sommer sommer...@gmail.com: Maybe we could use a key with a namespace: power:usage=* or something else. Keeping is separate from the railway usage could give us more clairity. Lukas Sommer 2014-11-24 15:24 GMT+00:00 François Lacombe fl.infosrese...@gmail.com : Hi Rainer and thank you. I didn't spend time yet on the update done on the Pipeline proposal but be sure I will. What were the concern against network=* tag ? If they can be avoided with usage=* (or any common key) I'm ok to join you to use the same between power transmission and pipelines. Cheers *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux 2014-11-24 15:57 GMT+01:00 Rainer Fügenstein r...@oudeis.org: hi, FL I knew usage=* and it can be the ideal key to indicate usage=transmission, FL usage=distribution,... on power lines or power cables. If I'm not mistaken, this key is intended to serve the same purpose as the network=* key is in the pipeline proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension#Pipelines FL But it is currently and exclusively used for railway tagging. FL https://wiki.openstreetmap.org/wiki/Key:usage concerns against using the network=* key have been raised. it would make sense to join forces here and use a common key, be it usage=* or something else. cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging --- NOT sent from an iPhone ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging --- NOT sent from an iPhone ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo
Re: [Tagging] Adding values to usage=* key for power transmission
MR I do not know why anyone should tag one OSM way both with power=* and MR railway=*. and here I contradict my own oppinion: In many cities, there's a gas pipeline running under (almost) every street, providing gas to domestic homes (as do water, sewage ...) just imagine a city like vienna, drawing one or more man_made=pipeline ways parallel to nearly every highway=* - a nightmare, editing-wise. in these cases, it would be better to use the already existing highway=* way and also tag it as man_made=pipeline. and here we have the first name=*, ref=* conflict, only to be solved by prefixes. similar situations where pipelines run underneath bridges to cross a river (etc). can't speak for the power guys here, but rather unlikely that something runs directly underneath/above a high voltage power line ;-) cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Adding values to usage=* key for power transmission
LS I agree with you if you say that usage LS sounds like a very general key and not a railway specific key. So the LS railway guys have just been a little faster than the power guys and LS occupied this key. I would accept this and search another key to avoid LS unnecessary conflicts. I dont insist in power:usage. It can also be LS something else, but I would introduce a new key for this. usage is discouraged because the railway guys already use it. network is discouraged because the bus/cycle guys alread use it. if this trend continues, we may run out of suitable words in the english language one day. what about system=* or purpose=*? even prefixed as power:system, pipeline:system? cu LS cu LS Lukas Sommer LS 2014-12-01 23:38 GMT+00:00 François Lacombe fl.infosrese...@gmail.com: Hi Lukas, I don't like this : railway guys introduced usage without any namespace. Why should power introduce one ? usage=* is a common tag. The proposal isn't introducing power:location instead of location=* even if there is some specific values. Do you agree ? *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux 2014-12-01 9:31 GMT+01:00 Lukas Sommer sommer...@gmail.com: Maybe we could use a key with a namespace: power:usage=* or something else. Keeping is separate from the railway usage could give us more clairity. Lukas Sommer 2014-11-24 15:24 GMT+00:00 François Lacombe fl.infosrese...@gmail.com: Hi Rainer and thank you. I didn't spend time yet on the update done on the Pipeline proposal but be sure I will. What were the concern against network=* tag ? If they can be avoided with usage=* (or any common key) I'm ok to join you to use the same between power transmission and pipelines. Cheers *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux 2014-11-24 15:57 GMT+01:00 Rainer Fügenstein r...@oudeis.org: hi, FL I knew usage=* and it can be the ideal key to indicate usage=transmission, FL usage=distribution,... on power lines or power cables. If I'm not mistaken, this key is intended to serve the same purpose as the network=* key is in the pipeline proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension#Pipelines FL But it is currently and exclusively used for railway tagging. FL https://wiki.openstreetmap.org/wiki/Key:usage concerns against using the network=* key have been raised. it would make sense to join forces here and use a common key, be it usage=* or something else. cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging --- NOT sent from an iPhone ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] pipeline flow direction; was: Feature Proposal - RFC - Pipeline Extensions
hi, TK I'm certainly no pipeline expert, so forgive my ignorance. Does TK flow_direction=both mean that there actually is flow in both direction TK at the same time or does it alternate between flow directions? the latter. the direction of the flow within the pipeline may be changed. TK If the TK latter, perhaps a value could be chosen that better expresses this. the original proposal was loop=yes, because that's the technical term used by the pipeline operators (loop configuration). TK It should also be noted that flow_direction has been discussed as a tag TK for waterways, so if your definition leaves the door open for this TK potential use case, it would be quite helpful. that was the reason to discard loop=* and adopt flow_direction - to have a more generic term to also be used in other cases. this raises one question: should the pipeline proposal be accepted, will it be necessary to start another vote process for flow_direction? or is it sufficient to just add the page to the wiki? cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] pipeline flow direction; was: Feature Proposal - RFC - Pipeline Extensions
MK +1, also this way you give information about the direction of flow relative MK to the osm way, while flow_direction=oneway doesn't imply any specific MK direction, it only states that the direction is not reversible. proposal updated in this regard. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Pipeline Extensions
hi, (I'm cc'ing this to the list; guess that was your intention) f 1. Please do [not] use type (it should by used only for relations) but add f some works like medium_type or pipeline_type. after careful consideration, my GF came up with substance. all other options had some substances that did not fit (content - too static; is sewage a product? well, actually it kind of is ;-)) cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] pipeline flow direction; was: Feature Proposal - RFC - Pipeline Extensions
hi hi f Found one more, loop=* f Some month ago we were talking on this list about flow of waterways and f pipelines. f The far I remember flow_direction=forward/backward/both was mentioned to f tag the direction a pipeline or canal is used. agreed; it is better to define a tag that can also be used in other cases. I glimpsed over the pipermail web pages - can't reply directly, therefore a summary: * there are pipelines which can reverse the flow and others which can't. therefore it is not wise to assume oneyway=yes (or similar) by default. * presumably, the post by Bryan Housel (So my reading of that was that pipelines imply oneway=yes) was made before the loop tag was added to the PipelineExtension proposal. * pipelines are usually built to transport the substance only in one direction. for such pipelines, it is not possible to reverse the flow by just pressing a button. they have to be constructed to do so, which some/most newer pipelines are. * I don't see the point of flow_direction=backward/forward on a pipeline. it doesn't make sense to draw the way in one direction and specify flow_direction=backward. since it (will be) a generic tag, forward/backward may make sense in other cases. for pipelines, I propose flow_direction=both and flow_direction=oneway. if the latter is disputed, using just flow_direction=forward (and never =backward) is a good alternative. * if the flow direction is unknown, just don't add the flow_direction tag. cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Pipeline Extensions
I'd like to bring the following proposal to your attention: https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension it describes a set of tags in addition to the existing man_made=pipeline and pipeline=marker tags. thnx for your attention best regards ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Pipeline Extensions
hi, f 1. Please do [not] use type (it should by used only for relations) but add f some works like medium_type or pipeline_type. type was largely in use at the time the proposal draft was started, therefore I kept it, but I see the point of changing it. pipeline_type rather implies what's now proposed as network, something with medium is more appropriate. I wonder if it may just be medium=*? f 2. We already have support=* which is used with man_made=surveillance f and is much more in use than mount=*. Do we really need two almost f identical tags ? I agree with you on that. any chance to list it on the man_made=surveillance wiki page? cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
