Re: [Tagging] Rio de la Plata edit war
On 2020-08-01 9:26 a.m., Alan Mackie wrote: Perhaps I am an overly literal follower of the wiki, but I had always assumed the coastline should continue inland as far as the tide continues to be noticeable. Mediterranean mapping might be an issue, but elsewhere I think this is fairly clear? Starting locally, the Fraser River has a strong tidal influence 25km upstream of the coastline/riverbank edge. Fishers report a tidal influence 90km upstream. Wikipedia says the Columbia has tidal influence up to the first dam, which is 120km upstream of the coastline/riverbank edge. There are tidal forecasts published for 75km upstream of the edge. Looking in Europe, the Thames is tidal for 80km upstream of the coastline/riverbank edge. If the water is fresh or the waterway still appears to be a river, canal etc, then it seems reasonable that they should also have those tags as well. The coastline and riverbank tags aren't fighting for a common key, so it's not a direct tagging conflict. I would consider an area mapped as water both with natural=coastline and waterway=riverbank or natural=water in error. I haven't seen any cases where this is done. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rio de la Plata edit war
On 2020-07-31 8:21 a.m., Andy Townsend wrote: On 26/05/2020 00:20, Alan Mackie wrote: Has this edit war stabilised? Apparently it has been blocking coastline updates across the whole world for /months /now. https://osmdata.openstreetmap.de/data/land-polygons.html https://github.com/fossgis/osmdata/issues/7 (picking this thread up again because there still hasn't exactly been a meeting of minds here) land polygons have been generated (see https://osmdata.openstreetmap.de/data/land-polygons.html ) and https://github.com/fossgis/osmdata/issues/7 has been resolved by manually "releasing" the coastline. The current situation in OSM is https://overpass-turbo.eu/s/WD8 - at the time of writing this the coastline crosses the river north of Buenos Aires. However, edits are continuing (see https://www.openstreetmap.org/changeset/88787419 ). I'm not convinced that moving to one of two extremes, even a small amount at a time, is a good idea until there's actually been discussion between the proponents of the various positions. For what it's worth, neither extreme position looks the best answer to me - looking at the salinity change between river to ocean at https://www.sciencedirect.com/science/article/pii/S0307904X07000716 (see https://www.sciencedirect.com/science/article/pii/S0307904X07000716 for the key picture) and looking at https://de.wikipedia.org/wiki/Datei:Rio_de_la_Plata_BA_2.JPG suggests a location some way between the two. Despite the NASA photo it looks like there isn't a "step change" in salinity - and of course values will fluctuate based on winds and tides etc I live near the coast and have done coastline processing, including a great deal worldwide during the redaction. Salinity and territorial control have seldom been considerations in where the break between water mapped as waterway=riverbank and natural=coastline that I have seen. The break is chosen as a convenient place for mappers and a common view of where the coast of the ocean is, not based on scientific salinity criteria. For territorial control, look at all the inlets along the BC or Norwegian coasts. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
On 2020-05-07 11:49 a.m., Joseph Eisenberg wrote: So, what's the next step? As a next step, I'd map motorcycle taxis as amenity=motorcycle_taxi. Vote with your mapping. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Route names that aren’t names
On 2020-04-02 2:33 p.m., Yves wrote: Surely this can be fixed if needed, but Osm2pgsql still has a route_name column? osm2pgsql doesn't have any columns. It will produce a database with the columns you tell it to, transformed how you tell it to. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
On 2020-03-06 9:22 a.m., Peter Elderson wrote: That sounds even more odd to me... what if it doesn't match? Do we have authoritative gpx-es for routers? No. There is no one true route between two points, so there can't be an authoritative router. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Apps of delivery
On 2019-05-15 2:32 a.m., Philip Barnes wrote: We have deliveroo operating locally, however I have never seen verifiable evidence on the restaurants that they offer that service. Deliveroo might not, but there are delivery services that are indicated on restaurant doors here. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands
On 2018-11-24 4:38 PM, Alan McConchie wrote: Here's the overpass query for boundary=aboriginal_lands:http://overpass-turbo.eu/s/DV4 There has also been extensive discussion over the years on the boundary=aboriginal_lands page, and it seems like the consensus is that the tag is necessary and better than any alternatives. As one of the people using it, I find it better than any other options. The chief objection to it has been that aboriginal is not the preferred term in US English. Having visited reserves in Canada, US, and Australia, I think it's the best term. It is used in both Canadian and Australian English, which are closer to British English than American. It's not specific like "Indian", which is not recommended in the US or Canada, and has never been used in Australia. But it was never voted on as a proposal. But it's got usage, which I think is more important. In the intervening years, tagging native reservations with boundary=protected_area + protect_class=24 has also gained popularity. This tag combination seems to be popular in South America, Australia, and also in parts of the United States. I can't find any evidence for why people chose this tag combination instead of boundary=aboriginal_lands. It appears that the tags are pretty much interchangeable. Most of the features in Brazil however are tagged incorrectly for the renderer, mixing leisure=nature_reserve with protect_class=24, so that the areas show up on the default renderer with the nature reserve green style. I also find the entire protect_class tag a hopeless mess, but it has some particular problems here. It lends itself to treating a nature reserve like an aboriginal reservation. This is wrong, and depending on the region and history, can be racist. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Traffic sign direction tagging..
On Sep 29, 2018 9:40 PM, Kevin Kenny wrote: Alas, I don't have much hope that the pull request will be accepted. I've asked the upstream developers several times if they could possibly review the proposed functionality (I've at least a draft at a formal proposal - https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql) so that I can know whether I'm entirely wasting my time. I've heard nothng but silenceCould you provide a link to the osm2pgql issue tracker with the issue in question? I don't recall it, but I've been away a lot and haven't kept up with everything.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Truck Parking
On 6/2/2017 4:08 PM, Warin wrote: At present I have; hgv=yes/designated and capacity:hgv=yes/number Are there any others? I am tempted to use both of the above tags - covers any future preference. Thoughts? The first would indicate that the parking is usable or designated for truck parking, while the second is about how many spots there are. Unless they've indicated the number of truck spots, skip capacity:hgv. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Moving forwards with multi-valued attributes
On 1/23/2017 12:46 PM, Colin Smale wrote: Can you point to an illustrative example of leadership on the subject of MVAs? The data model used to support having the same key twice with different values. It no longer does. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Moving forwards with multi-valued attributes
On 1/23/2017 1:42 AM, Colin Smale wrote: This subject has been discussed so many times in the past, over several years. It seems that OSM is incapable of moving forward. The current data model does not accommodate multi-valued attributes It used to, then we moved forward to one that doesn't, because that's what all the tools work with.* Leadership was done, a choice was made on multiple values for a key in the data model, and now people are claiming a lack of leadership in the same choice. * This was before I joined OSM ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-us] destination:street
On 1/19/2017 5:00 PM, Martijn van Exel wrote: Looking at a random one, http://www.openstreetmap.org/way/34154734 / http://openstreetcam.org/details/10767/4194 — I think in the US we would just map this as destination=Carman Road;Iriquois and destination:ref=1 That is how it would be typically mapped in Canada in my experience, although it might have a prefix to the ref. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OSM in French and Dutch [or any monolingual]
On 8/11/2016 9:38 AM, André Pirard wrote: Someone asked on Twitter about a rendering of OSM in Dutch and French to avoid the clutter of bilingual names in the standard rendering. https://twitter.com/iciBrussels/status/762743820358418432 The French render is easy, OSM France provides it. But how about a Dutch rendering? Do you know of one? It might be cool to create a little webmap on OSM.be with the three official languages. If you help me find a Dutch rendering, I can make that (I've just learned the basics about leaflet). It looks rather easy to make a style with mapbox, but you need to extract the data through Overpass for exotic languages like Dutch, so it would be a bit of a job to keep that up to date. I don't understand exactly what the problem is. OSM.org displays the names according to the Language preference of the browser (1). Joost is talking about rendering, not text on osm.org ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Parklets
On 5/9/2016 4:25 AM, Marc Gemis wrote: One of the main characteristics seems to me that it is semi-permanent : "A parklet may be thought of as permanent, but must be designed for quick and easy removal for emergencies or other reasons such as snow removal without damage to the curb or street" This is not true for all parklets. I have seen ones locally which would not be able to be removed quickly or easily in case of an emergency. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Inconsistent road refs
On 2/3/2016 1:35 AM, Martin Koppenhoefer wrote: why isn't it signed any more? Has the route stopped to "exist" and they removed the signs on purpose (but just haven't finished yet hence the signs on the crossing roads)? I would tag "old_ref" for situations where the ref is no longer valid, but might still provide some useful information today. E.g. in Italy a lot of roads have passed from the national operator to the regions (admin entities), and changed their refs accordingly (e.g. SS 4 to SR 4), and they also put some new signs here and there, but they didn't remove a lot of the old signs, so that you can find a lot of old refs still signposted. In this context we have tagged also old_ref to these roads. If on the other hand the refs are still valid, but simply aren't signposted on some stretches anymore, I would keep them in "ref". What do you mean by valid? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Inconsistent road refs
There is a stretch of local highway which used to be signed with a ref, but no longer is. On the other hand, most of the intersecting roads still show that this highway has the old ref. Some other parts of the road remain signed. The two options for tagging seem to be ref=123 or old_ref=123. Thoughts? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations
On 11/10/2015 11:20 PM, Paul Johnson wrote: I thought the problem was a 2000 member limitation in the API This is on nodes per way, not members per relation. There are 164 larger relations. Even if there is no hard limit, I'd consider a 2k member relation past the limit of what is practical to work with. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New proposal: Obligatory tagging of oneway on motorway_link
On 9/10/2015 5:20 AM, Joachim wrote: Define on the wiki page of highway=motorway_link that oneway=* must also be tagged for every motorway_link. If not tagged, the oneway=* status of this way is undefined. Explicitly tagging oneway on links is preferable for obvious reasons, but you need to be careful with must, which is wrong for two reasons. - The wiki can document, but not set out requirements, as people can ignore the current state of the wiki. - Your next sentence discusses the lack of oneway - There is not a concept of formal validity, so must doesn't apply - Data consumers will make their own decisions Tools to help enforcing the obligatory usage: [...] - No routing over undefined oneways The chances of anyone implementing this in their routing engine are approximately zero. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop vs amenity
On 8/27/2015 2:29 PM, Martin Koppenhoefer wrote: not at all, this might be the case in some areas (that I am not aware of) and edge cases, but the typical supermarket is 1 storey, in huge cases 2 (and then one level is typically electronics, or gardening and other non-food articles and tends towards a department store by the selection of products) and doesn't have a representative / expensive outside facade, while department stores tend to have at least 3 floors, typically 4 and more, and do have to have a representative outside, so no, these are not the same kind of buildings. This is not generally true, although it might be where you are. A typical department store here is one or two floors inside, with an outside somewhat like this: https://c4.staticflickr.com/8/7057/6842722906_1b8e4cc101_z.jpg, or maybe on the fancier end, https://www.flickr.com/photos/darrellinyvr/6988854497/. This is the same as in Ontario, and across much of the US where I have traveled. The only 3+ floor locations that come to mind are some old stores downtown. Meanwhile, with moving ramps capable of taking carts, some new supermarkets are on an elevated level. Do you have any real example of a supermarket becoming a department store or vice versa? Yes - local to me, the Woodward's location used to be a department store, and has been a Zeller's (discount retail), parts of a Safeway (supermarket), fitness center, and now has a Walmart moving into part of it. You should not assume that the architecture you are familiar with is common across the world. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=derelict_canal
On 8/24/2015 3:35 PM, Andy Townsend wrote: That's not so bad in lua, but imagine writing ... and not disused=yes into every cartocss rule! Fortunately, we will not have to do that in OpenStreetMap Carto, as we will not be supporting the style of tagging where one tag says what something is, then another tag saying it's not really that, but used to be, or will be. We do not want to encourage the use of disused=yes, abandoned=yes, or similar tags. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rural Alley?
On 7/8/2015 2:44 AM, Andrew Errington wrote: They're not really tracks, as they are proper roads, with a concrete or tarmac surface, But, they don't really go anywhere. Tracks can be paved - tracktype=grade1 normally is paved, or is built to equivalent quality. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rural Alley?
On 7/8/2015 1:25 AM, johnw wrote: [trimmed] The issue is that these “small windy roads that go everywhere” go nowhere. the land they access is for farming the subdivided sections ... lead you on a tour of the local rice plots and hills. it is basically access for the farmers, which then have a network of (private?) tracks and paths that break the sections down further. they just loop around a big rice field, or connect to other roads which service other rice fields or logging plots: nothing of interest - not even a house - is there. Only the local farmers need use of them, but they are public. it’s the purpose of the road - the lack of shoulders and other road standards, and expected curves, turns, and other “classifications” of the road. From what you've said about the purpose, it sounds like highway=track. The conditions (paved or not, etc) would then dictate the tracktype and other tags. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=stream oneway=1
On 7/4/2015 12:57 PM, Mike Thompson wrote: Is it really necessary for a way that is tagged waterway=stream to also be tagged oneway=1? Isn't this implied? oneway indicates that traffic is restricted from traveling the other direction. I suppose this might happen in a busy canal system, but on virtually any stream or river, it is in error. Please see this example: http://www.openstreetmap.org/way/306529208 note it appears that after I originally entered the way its direction was reversed (i.e. it now flows uphill). Perhaps someone with a better understanding of the history tools could confirm this. Version 2 indicates that the direction of flow is southwards. Version 1 indicated that the direction of flow was northwards. In addition, version 2 indicates that the direction of travel was southward. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Draft tag for Airport Security Zones | Non-voting procedure
On 6/15/2015 10:01 PM, Bryce Nesbitt wrote: Are these functions still handled in (mappable) part of the building? Entry into the different zones is at fixed points Are the restrooms and charging stations assignable to a zone that is constant? No. In practice, this isn't typically an issue because the closest facilities are normally in the same zone as you are, both for security and customs. They also tend to be less useful features because it's easier to look up for a restroom sign than use a device. And this is leaving aside flights that arrive, where they may send you on at least two sets of internal passages leading out of secured areas, or into the general waiting area at the gates. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Draft tag for Airport Security Zones | Non-voting procedure
On 6/15/2015 5:42 AM, johnw wrote: The only way I could be wrong is if they have a “Schengen” terminal or something like it : special*facilities* at the airport*separate* from the normal domestic and international style terminals. Not a separate Schengen line at immigration, or a security checkpoint, but if there is a distinct area that is different from Domestic and International. EU residents care to chime in? As someone who has been doing too many flights lately, in Canada airports often have domestic, international, and trans-border. Trans-border is for flights to or from the US and have a special customs arrangement. This is, unfortunately, unmappable. Which gates are part of which terminal can shift around depending on time of day and what flights there are, and there is no specific schedule. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Locating the voting page for a tag
While looking into some issues around a bad import, I ran across http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights_Data_Model but was unable to find a page with voting or discussion. Although the tag voting process has many flaws, this doesn't say it was added because it is what was commonly used. Does anyone know where the voting page is? I've gone and fixed some of the flaws. For example, the page was implying that something is render a certain way, but was really just making rendering suggestions. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Locating the voting page for a tag
People are adding these tags to OSM, presumably based on the wiki page. They're on the osm.org wiki, how do they not apply to the osm database? Also, I'm not sure what you mean by the OpenStreetMap renderer. There are dozens of renderers that work from OpenStreetMap data, of which OpenSeaMap is one of them, along with MapQuest Open, osm.org mapnik, osmarender, etc. -Original Message- From: Malcolm Herring [mailto:malcolm.herr...@btinternet.com] Sent: Sunday, March 13, 2011 3:36 PM To: tagging@openstreetmap.org Subject: Re: [Tagging] Locating the voting page for a tag Paul, You must have missed these words at the top of the wiki page: These definitions relate to node tags in the OSM database which will render on the OpenSeaMap charts i.e. The renderings defined are not those of the OpenStreetMap renderer, but OpenSeaMap's own renderer. That is also why you have found no tagging discussions, since these tag definitions are not intended for the Street Map. I have reverted the page. Regards, Malcolm Herring ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Counterflow Lanes
The Massey Tunnel is currently tagged with oneway=no on the reversible section and through the tunnel itself. For the reversible sections (that lead up to the tunnel) they really alternate between oneway=-1, oneway=yes and access=no. For the two parallel tunnels themselves they alternate between oneway=yes and oneway=no. I'm not sure what the solution is, but oneway=reversible isn't a special case of oneway=yes so it would break existing data consumers. -Original Message- From: Nathan Edgars II [mailto:nerou...@gmail.com] Sent: Saturday, February 19, 2011 1:54 PM To: tagging@openstreetmap.org Subject: Re: [Tagging] Counterflow Lanes On 2/19/2011 4:33 PM, Paul Johnson wrote: A better example would be the George Massey Tunnel on 99, which omits the oneway= tag completely on both motorways in the contraflow sections. According to the wiki, highway=motorway* implies oneway=yes (meaning it's always oneway in the drawn direction), so you'd need a oneway tag to override this. But oneway=no is incorrect; oneway=reversible is a reasonable replacement when it's sometimes oneway=yes, sometimes oneway=-1, and maybe sometimes oneway=no. Other tags could then be used to indicate when it's oneway in which direction (if the times are fixed). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - sluice_gate
On Sun, Jan 9, 2011 at 2:36 PM, Paul Norman penor...@mac.com wrote: The question is, what else would go there? Flood gates don't belong there - that's the *usage* of the gate, not the *type* of gate. From a technical perspective you may be right, but practically speaking, we should design tagging schemes with usability in mind. People are likely to know that there is a flood gate, not that there is a hinged crest gate. So something like: waterway=flood_gate flood_gate=sluice_gate ...is more usable for non-techie nerds than something like: waterway=flow_control flow_control=sluice_gate usage=flood_gate Most of the sluice gates around here are not flood gates. For some of the ones I've mapped I'm not sure if they're flood gates or not, but I know they're sluice gates because that is obvious from a quick look while to say if they're flood gates or not I would need to know how they're being used, when they're opened, etc ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - sluice_gate
Based on feedback, I've modified http://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate -Original Message- From: tagging-boun...@openstreetmap.org [mailto:tagging- boun...@openstreetmap.org] On Behalf Of Paul Norman Sent: Saturday, January 08, 2011 7:36 PM To: 'Tag discussion, strategy and related tools' Subject: Re: [Tagging] Feature Proposal - RFC - sluice_gate From: Steve Bennett On 5/01/2011 3:18 PM, John Smith wrote: Perhaps a more generic approach would work, eg waterway=flow_control flow_control=weir|sluice_gate|flood_gate|spillway_gate| Yeah something like that would be reasonable. What I'd like to see a lot more of is planning ahead: coming up with a scheme into which all future subtags can be slotted. It's very hard to change a tag once it's become popular. So perhaps: waterway=dam (a wall with water on one side) waterway=weir (a wall with water flowing over the top) waterway=flow_control (an opening through which water sometimes flows). flow_control=sluice_gate|flood_gate|spillway_gate|lock_gate... Then we get people who know this stuff to try and find exceptions that don't fit into the above scheme, and redesign it. I've been looking into this. How does this sound? waterway=dam and waterway=weir remain unchanged. waterway=flow_control - a device for controlling the flow of water flow_control=sluice_gate|discharge|... sluice_gate: a sluice gate. discharge: A discharge point like http://en.wikipedia.org/wiki/File:Howell-Bunger_valve.jpg The question is, what else would go there? Flood gates don't belong there - that's the *usage* of the gate, not the *type* of gate. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - sluice_gate
From: Steve Bennett On 5/01/2011 3:18 PM, John Smith wrote: Perhaps a more generic approach would work, eg waterway=flow_control flow_control=weir|sluice_gate|flood_gate|spillway_gate| Yeah something like that would be reasonable. What I'd like to see a lot more of is planning ahead: coming up with a scheme into which all future subtags can be slotted. It's very hard to change a tag once it's become popular. So perhaps: waterway=dam (a wall with water on one side) waterway=weir (a wall with water flowing over the top) waterway=flow_control (an opening through which water sometimes flows). flow_control=sluice_gate|flood_gate|spillway_gate|lock_gate... Then we get people who know this stuff to try and find exceptions that don't fit into the above scheme, and redesign it. I've been looking into this. How does this sound? waterway=dam and waterway=weir remain unchanged. waterway=flow_control - a device for controlling the flow of water flow_control=sluice_gate|discharge|... sluice_gate: a sluice gate. discharge: A discharge point like http://en.wikipedia.org/wiki/File:Howell-Bunger_valve.jpg The question is, what else would go there? Flood gates don't belong there - that's the *usage* of the gate, not the *type* of gate. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Aqueducts?
On 7/01/2011 9:19 AM, M∡rtin Koppenhoefer wrote: What do you think about waterway=aqueduct ? Around here there are quite some historical aqueducts (e.g. [1]). Most are ruins, but they are still impressive. I tag them waterway=aqueduct, ruin=yes Some are bridge-like (arches), but others are solid underneath. Hmm. It could get increasingly difficult to objectively distinguish between all the different types of man-made water channel: canal, drain, aqueduct. (Incidentally, taginfo shows 40,000 uses of waterway=artificial - anyone know what that is?) I guess the difference in the above is the purpose: transport, stormwater, and drinking water respectively. How is one supposed to tag an irrigation channel? Around here, waterway=ditch. This completely sidesteps the question of wider irrigation channels, but I don't have to worry about those since they don't exist out here. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - sluice_gate
They both have elements of flow control, but function in quite different ways and look very different. A weir is used to raise the water level or control flow, with water flowing over the top. A sluice gate is essentially a valve for small waterways. -Original Message- From: tagging-boun...@openstreetmap.org [mailto:tagging- boun...@openstreetmap.org] On Behalf Of Ulf Lamping Sent: Monday, January 03, 2011 2:04 AM To: tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - sluice_gate Am 03.01.2011 02:59, schrieb Paul Norman: I've set up a proposal for sluice_gates, which are typically found on small waterways in agricultural areas at http://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate What's the difference to waterway=weir? http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dweir Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - sluice_gate
All the sluice gates I've seen are on the scale of 1m in opening size. A quick google image search also seems to only turn up small gates. I suppose there could be some large gates out there, so the proposal might need to include ways or even areas. As for riverbanks, the ones I've seen are near riverbanks, but not actually on them. In the case of a sluice gate that is actually on the bank, you'd have a node that is shared between the small waterway (waterway=ditch or waterway=stream), the riverbank, and is tagged with waterway=sluice_gate -Original Message- From: tagging-boun...@openstreetmap.org [mailto:tagging- boun...@openstreetmap.org] On Behalf Of Peter Wendorff Sent: Monday, January 03, 2011 1:52 AM To: tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - sluice_gate Hi. I'm not very familiar with waterway tagging, but AFAIK these are tagged as riverbanks, too. Your proposal doesn't say anything about how to map sluice gates at these bigger rivers as it proposes the usage on nodes only. As sluice gates assumably will be more on bigger waterways, that seems to be an important point to add for me. regards Peter Am 03.01.2011 02:59, schrieb Paul Norman: I've set up a proposal for sluice_gates, which are typically found on small waterways in agricultural areas at http://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - sluice_gate
I've set up a proposal for sluice_gates, which are typically found on small waterways in agricultural areas at http://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Carpool
-Original Message- From: tagging-boun...@openstreetmap.org [mailto:tagging- boun...@openstreetmap.org] On Behalf Of Rodolphe Quiedeville Sent: Friday, November 12, 2010 12:06 AM Hi, I propose a to add parking=carpool for carpooling. I'm not english so please be kind with my bad grammar, I do my best and be happy if you fix the mistake in the wiki. http://wiki.openstreetmap.org/wiki/Proposed_features/Carpool Why not amenity=parking with access=no and hov=yes using existing tags? Additionally, under your proposal, how would you tag an underground carpooling lot? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Proposing additions to features
I'm wanting to propose a number of additions to the highway=street_lamp feature, but I'm unclear on the process. The wiki only covers new tags, but the changes I would propose would add a significant amount of information that could be inputted. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] How to tag landscaping
Bring me a shrubbery! While doing some small-scale mapping, I came across an area of landscaping roughly outlined in http://wiki.openstreetmap.org/wiki/File:Landscaping.png Landscaping typically has small trees, shrubs, flowers, and other decorative plants. Being artificial, the natural=scrub and natural=heath tags are not suitable. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
