Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2
> Am 04/lug/2014 um 17:48 schrieb François Lacombe > : > > * tower:type is already used a lot with man_made=tower > tower=* and pole=* got some values to replace tower:type=termination and > transitions like tower=air_to_ground or tower:type=air_to_ground I think we should not mix up man_made=tower and power=tower and suggest to use power_tower:type or sth similar rather than tower:type for your proposal cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Suggestions for the correct tagging of Field borders
Ok, you’re right. I was a bit confused about the inconsistent usage of landuse and natural tag. Sometimes it’s not clear why there is used the natural or landuse key. For forrest you have both (landuse=forrest and natural=wood) but it seems to be the only one where you can decide whether it is managed or not. So I thought a new key would fix it in my case. But it seems to be a general problem, so it should discussed about in general and not in my specific topic. That means I agree with you. Option 1 or 2 would be the best choice. In my opinion the options only should be recommendations, the user should be free to decide the best option by himself. So what is the next step for me? How can I announce this value? Is a proposal-page in the wiki needed? Greetings Simon/descilla 2014-06-29 21:30 GMT+02:00 Martin Koppenhoefer : > > > > Il giorno 29/giu/2014, alle ore 20:09, Simon Wüllhorst < > m...@simon-wuellhorst.de> ha scritto: > > > > What do you think about theses options? > > > I prefer options 1 and 2 as I don't think that "trees" or "scrub" are > (sub)types of this feature, they are rather orthogonal ways of > seeing/describing the same spot of land. > > cheers, > Martin > ___ > 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] Feature Proposal - Voting - Port and terminals
Dear all, after almost six months from the original proposal, now I would like to ask you to vote these two new tags. Accepting the tag landuse=port would improve the detailed tagging of port areas, for example to tell apart container terminals (easily distinguishable from satellite imagery) from passenger terminals and so on. Alongside I ask you to vote the tag man_made=intermodal_terminal (areas where freight traffic is moved between different transport modes, for example from rail to trucks). For port proposal and voting page see https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dport For intermodal terminal proposal and voting page see https://wiki.openstreetmap.org/wiki/Proposed_features/Intermodal_Terminal Voting is starting today, and it will end Saturday 19 July at 12pm GMT. Thanks and best regards, Stefano ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=pipeline - is onewayness implied?
Hi, so you would call the Mittellandkanal, connecting Elbe and Weser in Germany a lake? I agree with Bulwersator. A canal does not necessarily have a flow direction. It may be built for water transport (then it might have one), it may be built inclining - indicating a "natural" flow. It may even have alternating flow when water is taken out on either side depending on weather or something like that. But it's definitly not a lake just because there's no flow direction. regards Peter Am 22.06.2014 12:58, schrieb Martin Koppenhoefer: > > >> Am 22/giu/2014 um 11:35 schrieb bulwersator : >> >> Canal is just man-made channel for water and existence of ones without flow >> is possible. >> I encountered some (between lakes). > > > when there is no flow it is a lake itself ;-) > > cheers, > Martin > ___ > 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] Suggestions for the correct tagging of Field borders
> Am 05/lug/2014 um 11:08 schrieb Simon Wüllhorst : > > Is a proposal-page in the wiki needed? It is Not strictly needed (you can use the tag straight away), but it is recommended in order to have some documentation remaining. I'd also suggest to put a link (see also) on landuse farmland cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=pipeline - is onewayness implied?
> Am 05/lug/2014 um 14:50 schrieb Peter Wendorff : > > so you would call the Mittellandkanal, connecting Elbe and Weser in > Germany a lake? no, and I can't imagine how you read this from my posting, the Mittellandkanal had indeed a lot of flow, besides transportation bringing water to industrial users is one of its purposes. cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=pipeline - is onewayness implied?
Am 05.07.2014 20:25, schrieb Martin Koppenhoefer: > > >> Am 05/lug/2014 um 14:50 schrieb Peter Wendorff >> : >> >> so you would call the Mittellandkanal, connecting Elbe and Weser >> in Germany a lake? > > > > no, and I can't imagine how you read this from my posting, the > Mittellandkanal had indeed a lot of flow, besides transportation > bringing water to industrial users is one of its purposes. Well... > when there is no flow it is a lake itself I chose the Mittellandkanal as a famous example without incline (except the built-in locks). Nevertheless - even without any incline and without any locks, without water taken out and put in leading to reasonable flow, it would IMHO not be a lake, but stay a canal. ;) regards Peter ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2
014-07-05 10:59 GMT+02:00 Martin Koppenhoefer : > > I think we should not mix up man_made=tower and power=tower > and suggest to use power_tower:type or sth similar rather than tower:type > for your proposal > Hi Martin, Actually, there's no mix up between man_made and power since only power=tower/pole are used in my proposal The only place where man_made=tower is mentioned is in the history section to say it has been tried but there is no need about this any more https://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#History It is also suggested to replace tower:type usage in power context by the simpler tower=* and pole=* because tower:type is used in a wider field of knowledge. Introducing power_tower=* and power_pole=* to store values instead than tower=* or pole=* may be a possibility. Do you agree ? *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=pipeline - is onewayness implied?
On 2014-07-05 14:50, Peter Wendorff wrote : Hi, so you would call the Mittellandkanal, connecting Elbe and Weser in Germany a lake? I agree with Bulwersator. A canal does not necessarily have a flow direction. It may be built for water transport (then it might have one), it may be built inclining - indicating a "natural" flow. It may even have alternating flow when water is taken out on either side depending on weather or something like that. But it's definitly not a lake just because there's no flow direction. regards Peter Lakes usually flow, and I would guess more than canals that are not water ducts. They're mostly a river meeting a hole, filling it and overflowing at the other end. And if you think of the Lac Léman and the river Rhone, that may be quite a flow. Unless it parallels a river, a canal like the Mittellandkanal is usually for navigation between two rivers or other canals of two different basins. In that case, it is prevented to flow with locks but it still flows a bit, naturally. Normally, some middle point of it is higher than each end, else, the water would have flown without digging a canal and the canal would be of the river diverting kind. And the water flows from that middle point in both directions towards the two basins. The slight flow is fed in from some rivers. So, typical canals are bi-one-way if I may say. Cheers, André. Am 22.06.2014 12:58, schrieb Martin Koppenhoefer: Am 22/giu/2014 um 11:35 schrieb bulwersator : Canal is just man-made channel for water and existence of ones without flow is possible. I encountered some (between lakes). when there is no flow it is a lake itself ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Where do source tags belong?
Hi, A short summary of my thoughts and a reply. source:XXX=* describes an object attribute, not a change attribute, and should hence be an object tag. To benefit from overpass queries based on source:XXX=*, it must be an object tag. Forcing mappers to split changes so that each part has appropriate source tags and to repeat the same source tags for different versions is a real hassle and is no improvement at all over object tags. A bulk import totally complete in one operation may put a confidential source in changeset, but... In the example case of a set of objects being checked and copied by mappers from a BusCo--mm.osm file to update OSM, it is necessary that the copied objects contain a copied source tag containing the date -mm of the new version. Let's call this witness the update marker. By querying the update marker with that date, overpass can build the list of objects that are already mapper-processed and that can be expunged from the BusCo--mm.osm remaining-to-do-file. Replies inline... On 2014-06-30 18:40, Jo wrote : Just like everybody else I started several years ago by adding source tags on the objects themselves. The whole reason why the imports list says source tags belong on the changeset has something to do with an import of millions of buildings in France, each and every one with: source=cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre. Mise à jour : 2013 To avoid this kind of clutter in the future, I read all the time on that list source tags should go on the changesets and I agree, even if it complicates things a bit. The number of bus stops in Wallonia is much much less than the houses and other features of France. They're even a tiny fraction of the other source tags that the mappers must use in the same region. Once again, if the French Cadastre don't mind a confidential source mention, the answer is in my previous message: a tagset source is all-right for a bulk, robotized, one shot import import, thing done, OSM update, but not for BusCo piecewise, mapper-made, update needing a marker. Only by curiosity: 1000 × that source=... line compression ratio: zip: 262, bz2: 1600, xz: 2718 !!! I've seen ADN like Y1 Y2 Y3 Y2 Y3 Y1 on the French border with ways more recent than their nodes ;-) Having the source on the objects doesn't work either, anyway. It does work and it's the good way to achieve what's wanted. If you insist on putting them on the objects, take the prepared osm file. Select all objects, and add the source tag you like. For a detailed description on how to do so, see my previous message. Apparently things seem too complicated or unwieldy when described in too much detail. No need to explain me how to do that, I made a complete osm file myself. Don't expect other people to do so as well. That is indeed the worst way. Or the best way to have missing or unrecognizable source tags. That is indeed why that tag must be copied from the *.osm source file like said in my previous message. OFF topic, sorry... Since not all the stops will have source tags, another system will be needed to know where there is still work to be done. ??? That is indeed why that tag must be copied from the *.osm source file like said in my previous message. Should some mapper somehow fail to copy the update marker, the bus stop will remain in to-do state in the osm file and the problem will be spotted that way. This is not very complicated. Every bus/tram stop has a ref. Compare the refs, compare the other tags. If not present, the object is still new. If the other tags differ, the object needs updating, either upstream or downstream. Once again, what I said is not very complicated indeed. If some OSM tag and the corresponding *.osm tag differ, we cannot determine if it is because the tag was not copied or because the *.osm data is incorrect and the mapper made a correction of it. Hence, the update marker is necessary in the object tags to witness that the update was processed. That doesn't prevent checking mandatory equality of, for example, the "ref", but data li
Re: [Tagging] [OSM-talk-be] Where do source tags belong?
off list: André, I'm in the process of ending the addition of 37000 stops of De Lijn to OSM. None of them have the holy source tags and still I'm able to compute which ones still need to be done. So I'm not worried about getting bitten in the back. I have a system in place which works and which doesn't rely on source tags. It only relies on ref tags (and operator for the Overpass query) I know that you know how to bulk add source tags, the explanation was only there for when you were going to insisit on adding them yourself. You can, if you want, but I'm not going to. Just like I stopped doing so for the ones of De Lijn. That's right*, *I started by adding them just like anybody else would. Then I started reading the imports list and came to the conclusion they clutter the DB AND it's not clear afterwards which tag they refer to anyway, or whether they refer to the position. So I tend to understand your concern, but I don't happen to share it and this is based on practical experience built up over the past years, doing exactly what we want to do with the TEC data: importing stops and creating route relations based on them. Jo PT.overpass Description: Binary data PT.cmd.REMOVEME Description: Binary data ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
