Re: [Tagging] Lifecycle concepts, REMOVED
2015-01-28 19:25 GMT+01:00 Frederik Ramm frede...@remote.org: If there used to be a castle and now there's a ruin, then we tag that as a ruin (with potential add-on info about its former castle status). If there used to be a building but all that is left is a clearing in the forest, then the clearing will be in OSM, and not a building with a lifecycle tag of removed. generally I agree with you, but there might be edge cases. I looked this up in the wiki because someone on the italian ML asked what to do with a aerialway=cable_car, where the pylons and the cable have been removed, but the stations still exist, and the current tagging for the way was disused=yes and aerialway=cable_car. I answered that I'd remove the way, but in alternative he could retag it to removed:aerialway=cable_car and cancel the misleading disused attribute. This way there would remain trace of the former feature and the stations would be remain in context. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Lifecycle concepts, REMOVED
On Thu, 2015-01-29 at 08:43 +0100, Mateusz Konieczny wrote: Yes, my opinion is that all highway=proposed should be removed. I think this is an absolutely awful idea. after it is obvious the proposed road will never be built sounds nice but always there will be somebody convinced that proposal is real. For example my city has multiple proposed roads - that are in official planes for decades (one since at least 1960s), with start of construction within 25 years since initial proposal. If the proposal was from between 1960 and 1969, within 25 years would have been no later than the end of 1994, possibly as early as 1985. So on those, I would be okay with removal unless construction suddenly becomes imminent, because we are long past that point. On newer proposals, maybe a grace period of 3 months to a year after the stated construction time frame, then get rid of it. If it's built later it can always be re-added. I have a fair amount of proposed roads in my area too, but the freeways which were proposed decades ago and not only were never built, but almost certainly never will be, never were added to OSM. I probably should research the others to see what the statuses of the respective proposals are now, especially those that have been sitting there a while. -- Shawn K. Quinn skqu...@rushpost.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Lifecycle concepts, REMOVED
2015-01-29 8:43 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com: OSM should map current situation - not what was there or what will be. what was there and what will be is part of the current situation. after it is obvious the proposed road will never be built sounds nice but always there will be somebody convinced that proposal is real. For example my city has multiple proposed roads - that are in official planes for decades (one since at least 1960s), with start of construction within 25 years since initial proposal. you don't _have_ to enter this kind of feature, in the end it is up to the mappers to decide what to insert and what not, and in the cases you describe above, it seems of few interest to add these, but in other cases it might make sense. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop for watches
2015-01-26 2:44 GMT+01:00 johnw jo...@mac.com: Or does this go back to it should be shop:jewelry=watches or shop=jewelry + jewelry=watches problem? this would only make sense if all shops selling watches could be considered jewellery shops (btw: jewelry is American English, but we're using BE in OSM). shop=watches is fine, is documented and this discussion could have already ended some time ago ;-) http://wiki.openstreetmap.org/wiki/Tag:shop%3Dwatches cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD pipeline sub tag substance
2015-01-29 5:41 GMT+01:00 johnw jo...@mac.com: if this is the proper term used for pipelines, then this would be the right one, Otherwise, =multi (like sports) would be the best. but you would not need such a tag, since it would be substance=gas substance:detailed=multiphase_gas if you keep it at two levels of detail (water, gas, oil, fuel, sewage, heat, coolant, etc), I'd like to repeat once again that substance doesn't seem to be a nice key descriptor for values like gas, fuel, heat, as it refers to physical matter/material and heat or gas or fuel in its actual meaning aren't materials. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Lifecycle concepts, REMOVED
Warin 61sundow...@gmail.com wrote: removed: (features that do not exist anymore but may still be seen on other sources) [@Martin: leave a mention to the other sources] I see no harm in leaving them in OSM. Untill something is built there or the landuse/cover changes. Leave it there so no one re adds it. Remove it only when new features take its place, so the new features are not confused by the past. In most cases they can be simply removed from database. But here with 'removed:' I propose to leave an outline in OSM DB with the tag namespaced removed:*=* so that they appear on editors but are not otherwise rendered or used. Similarly 'error:' was a proposal for tag namespaced error:*=* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ethnic shops
2015-01-28 19:57 GMT+01:00 Dan S danstowell+...@gmail.com: Hi - my 2p: yes sounds fine. I agree with others who said that culture=* seems a decent choice (since more flexible and less awkward than ethnicity=*) I don't like culture as it is way too generic IMHO, it can mean a lot of different stuff, and you can see from taginfo that none of the currently used values do fit with the here intended meaning: http://taginfo.osm.org/keys/culture Instead they mostly fit into a proposal I made up 5 yrs ago but then abandoned: http://wiki.osm.org/wiki/Proposed_features/culture The flexibility is not a pro but a con, too flexbile ;-) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop for watches
2015-01-25 12:29 GMT+01:00 Andreas Goss andi...@t-online.de: And see also for repairs: http://wiki.openstreetmap.org/wiki/Tag:craft%3Dwatchmaker Or this http://wiki.openstreetmap.org/wiki/Tag:craft%3Dclockmaker -__- Still don't get the difference... a watch is small and you have it on your wrist or in your pocket, a clock is bigger and can stand free or is attached to a support like a tower, a wall, a pole, ... A clockmaker is dealing with stuff like this: http://en.wikipedia.org/wiki/Clockmaker#mediaviewer/File:CentenarioFactory04.JPG A watchmaker is dealing with tiny stuff and typically is using lenses to better see what they are doing: http://en.wikipedia.org/wiki/Watchmaker#mediaviewer/File:Watchmaker.jpg cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Lifecycle concepts, REMOVED
If the proposal was from between 1960 and 1969, within 25 years would have been no later than the end of 1994, possibly as early as 1985 Every few year local government releases new plans - so in 1994 it was planned to start around 2020. Currently there are plans to start construction in 2030 (there is even preliminary project, but nobody has idea how to fund tunnel that even before cost overruns costs more that entire yearly budget of the city). have a fair amount of proposed roads in my area too, but the freeways which were proposed decades ago and not only were never built, but almost certainly never will be, never were added to OSM. Just a simple mapper believing that the projects are still serious is enough to map roads that are de facto fictional. And then it is nearly impossible to remove this data. 2015-01-29 9:24 GMT+01:00 Shawn K. Quinn skqu...@rushpost.com: On Thu, 2015-01-29 at 08:43 +0100, Mateusz Konieczny wrote: Yes, my opinion is that all highway=proposed should be removed. I think this is an absolutely awful idea. after it is obvious the proposed road will never be built sounds nice but always there will be somebody convinced that proposal is real. For example my city has multiple proposed roads - that are in official planes for decades (one since at least 1960s), with start of construction within 25 years since initial proposal. If the proposal was from between 1960 and 1969, within 25 years would have been no later than the end of 1994, possibly as early as 1985. So on those, I would be okay with removal unless construction suddenly becomes imminent, because we are long past that point. On newer proposals, maybe a grace period of 3 months to a year after the stated construction time frame, then get rid of it. If it's built later it can always be re-added. I have a fair amount of proposed roads in my area too, but the freeways which were proposed decades ago and not only were never built, but almost certainly never will be, never were added to OSM. I probably should research the others to see what the statuses of the respective proposals are now, especially those that have been sitting there a while. -- Shawn K. Quinn skqu...@rushpost.com ___ 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] RFD pipeline sub tag substance
Am 29.01.2015 um 10:59 schrieb Martin Koppenhoefer: 2015-01-29 5:41 GMT+01:00 johnw jo...@mac.com mailto:jo...@mac.com: if this is the proper term used for pipelines, then this would be the right one, Otherwise, =multi (like sports) would be the best. but you would not need such a tag, since it would be substance=gas substance:detailed=multiphase_gas if you keep it at two levels of detail (water, gas, oil, fuel, sewage, heat, coolant, etc), I'd like to repeat once again that substance doesn't seem to be a nice key descriptor for values like gas, fuel, heat, as it refers to physical matter/material and heat or gas or fuel in its actual meaning aren't materials. +1 but what do you suggest. Do we need a key for the state of matter or better use water_steam or hot_water or fluid_propane ? using the colon separator would keep from making additional tags (everything would be kept in the substance tagspace) - especially generic tags like fuel= water= gas= which might have uses elsewhere (like the water_tap discussion here earlier) or be confused for other uses (like not a subkey, but a straight key by itself), someone could stick fuel=unleaded_87 onto a gas station. Or does that already exist? Have a look at fuel=* [1]. Nice, we already have the value in key variant and a key=value variant with possibility to use semi-colon. At least, we should consider the same tags for the same substances/fuels. How about substance=wood_pallets. cu fly [1] https://wiki.openstreetmap.org/wiki/Key:fuel ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ethnic shops
Eric SIBERT courr...@eric.sibert.fr wrote: I started modifying the wiki following our recent discussion. For cuisine=*, I added: ... For shop=convenience, I added (in Tags used in combination): ... +1 And latter go on with culture=* for nonfood services? +1 Hi Martin Martin Koppenhoefer dieterdre...@gmail.com wrote: The flexibility is not a pro but a con, too flexbile ;-) Flexible enough (pro) or too flexible (con): YMMV ;) I view 'ethnicity' as not flexible enough and 'culture' as appropriate. At least 'culture' is my preferred proposal so far. Maybe someone can propose something better. I think culture=* is good enough to start using it and document it and get more feedback. I don't like culture as it is way too generic IMHO, it can mean a lot of different stuff I quite agree but argued that Within the context of shops and with the associated values related to nationalities and the like, the meaning of culture=* is rather unmistakable. Other proposals were far more generic (origin) or a little too specific (ethnic/ethnicity, nationality, subculture). I think culture=* is a nice middle ground and a good fit regarding the values that are expected to be used. you can see from taginfo that none of the currently used values do fit with the here intended meaning: http://taginfo.osm.org/keys/culture culture=* is indeed not used yet in the here intended meaning. Because it is a brand new idea and because it is discussed here first, instead of use first and discuss after. Instead they mostly fit into a proposal I made up 5 yrs ago but then abandoned: http://wiki.osm.org/wiki/Proposed_features/culture Already discussed in some details. 84 uses, only tagging errors where culture=X should be replaced by amenity=X or tourism=X. culture=* is available as a tagging option, the current use is irrelevant. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Lifecycle concepts, REMOVED
Richard Z. ricoz@gmail.com wrote: thank you all for the unexpected attention, the problematic text snippet was cutpaste from [[Comparison of life cycle concepts]] where it must have been lurking for some time. [[Comparison of life cycle concepts]] is meant as an overview. I approve very much your edit for reduced section [duplication with lifecycle prefix]. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Lifecycle concepts, REMOVED
Mateusz Konieczny matkoni...@gmail.com wrote: Yes, feature that does not exist anymore (or even never existed!) or is only proposed has no place in OSM. +1. No place on rendered map and apps. +/-1. No place on DB. With possible caveat that features that are extremely likely to be added (recently destroyed building visible on aerial images etc) element with note explaining situations makes sense. +1. Tag:note=* is useful for such cases. But not a full tagging scheme! -1. If you keep the outline in OSM database, removed:building=* instead of building=* is efficient, can be quicker than free-form note=*, clear and informative. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD pipeline sub tag substance
Throwing out my ideas... Disclaimer: These are generic proposals for pipeline sub-tagging with example values for illustration. I do not want to derail this towards water/drinking_water and multi-values (semicolon or namespaced). ;) I propose 3 keys: use/purpose (as main subtag), state/phase and substance/name. pipeline:use = * or pipeline:purpose = * values limited to list eg.: drinking_water, wastewater/sewage, drain/irrigation, transport/transmission, heating, coolant, industrial, communication... [IMO this is the most interesting data to be rendered or externally used: the intent of the pipeline] May clash or need to be merged with the tag for pipeline: usage = * (currently very specific and oilgas oriented). Then additionally, because it can be informative and described with fixed values substance:state = * or substance:phase = * values limited to list eg.: gas, liquid, solid (cables), slurry (=liquid+solid particles), multi (=multiphase, mostly gas and liquid, possibly particles) Then, a bit of freedom with free-form value (possibly multi-values): substance:name = *, eg.: water, fresh_water, grey_water, steam... natural_gas, oil... chemical... cables, optic_fiber... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
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
On Thu, Jan 29, 2015 at 4:07 PM, Rainer Fügenstein r...@oudeis.org wrote: 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. fluid? ___ 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
On 30/01/2015 5:07 AM, Rainer Fügenstein wrote: 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 beam? etc. a native english speaker may come up with a proper expression, but I'd better not change this key once again. Why not, if it is better? After all the values are being considered for re-organisation? I don't understand the reluctance particularly with the present low usage of some 400 items? I too am not comfortable with 'substance' ... transports, carries, transmits, bears are possibilities... but I'm still thinking about it. I think 'bears' is best at the moment as that fits the 'substance=cables' which the others are not so well suited. 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 Good. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD pipeline sub tag substance
On 29/01/2015 3:41 PM, johnw wrote: substance=fuel substance:detailed=drinking_water isn't it just as error prone as substance=fuel fuel=drinking_water ? As the error is on one line it is easier for a human to pick up, either as it is made or on checking. An error that is a relation between two or more lines would be much harder for a human it detect, particularly when there is no error on the individual lines themselves. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD pipeline sub tag substance
On 28/01/2015 10:57 PM, Martin Koppenhoefer wrote: if you want the liquid information, use aggregate_state=liquid IMHO for pipelines it would be more interesting to tag the pressure and the inner diameter of the tube. Agreed in part. If 'we' tag what we see at the site .. then the pipe line it self is first then the outside diameter of the pipe is next. The difference between inside and outside diameters in most cases (except of small pipes .. and they are not something 'we' would be mapping at the moment?) would be small, and probably much less than the mappers error in estimating the pipe's diameter (outer)? Very minor point. To cover any case .. just use diameter? And let the mapper use what ever they think is easiest/best? Does what is inside the pipe need to be tagged? Yes .. because that is the reason for the existence of the pipe. And tells us a lot about where it comes from and goes too. Ok? Pressure and temperature and substance would give the state (if mostly only one substance is present) so maybe the state does not need to be tagged? Water .. why is this such a problem? Because it has so many uses, is so common? And 'we' assume so much about it? So 'we' have to deal with it... I too like 'grey water' .. but its meaning is too specific. I like some descritor that covers water that is not drinking water and not sewerage... that would include grey water, storm and water used for air-conditioning? Or am I trying to be too general? Maybe; potable water grey water - includes storm water industrial water (as used for heating, cooling, washing things etc) [hate that 'etc'!] sewerage 4 categories? I'd like to reduce that to 3 .. but does not look like it is going to happen. Ideas? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] patron saints
On 29.01.2015 13:24, Satoshi IIDA wrote: +1 to use wikidata. I had once thinking about same purpose. :) https://wiki.openstreetmap.org/wiki/Proposed_features/enshrine Sorry that I missed your proposal. Indeed, it seems that the wikidata id makes the tagging of related enshrines superfluous, as the relation between main and related enshrines can be defined outside OSM. But many place of worship in Japanese have multiple dedication gods. And when we would like to express using semi-colon (;), multi-lingual approach would be fail into complex array. e.g. If a shrine dedicates 3 gods. in Japanese Kanji = 天照大御神; 月讀命; 素戔嗚尊 in English = Amaterasu-Oomikami; Tsukuyomi-no-Mikoto; Susanoo-no-Mikoto And each gods has loc_name, alt_name, or alternated writings. I was thinking about dedication:N (like Addr:N) once, but it is a bit troublesome. There's a subtle difference to addrN: addr1:street, addr1:housenumber etc. need to be used in conjunction, while name:en, name:jp etc. are alternatives. Of course, local names or alternated spellings complicate things a lot. Isn't there an official dedication for a given japanese place of worship? We do have that for churches. It's one fixed wording (and spelling) for a given church, just like a birth certificate defines one fixed spelling for a given individual. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD pipeline sub tag substance
On 29 January 2015 at 22:54, Warin 61sundow...@gmail.com wrote: On 30/01/2015 5:07 AM, Rainer Fügenstein wrote: I'd like to repeat once again that substance doesn't seem to be a nice key descriptor for values like ... content ... too static medium ... too spooky product ... is sewage a product? type ... too generic and already in use I too am not comfortable with 'substance' ... transports, carries, transmits, bears are possibilities... I am OK with substance, content, medium or product. 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. Good. Not so good. ;) substance=multi is about OK as a shorthand. Using multi -- instead of actual values -- may also imply you are not going to give further detailed tagging. substance=multiphase is really awkward. In a previous post I advocated for phase/state=multi or multiphase substance=[multi-valued] eg. substance=oil;gas;water ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
