[Tagging] Changing amenity=bear_box to amenity=bear_cache
Based on a discussion that was had on the discussion page[0] of tag:amenity=bear_box, I am proposing a change of this tag from amenity=bear_box to amenity=bear_cache with an additional tag of bear_cache:type=* to better clarify what type of bear cache is here. The term "bear cache" seems to be a better definition of "bear box" and is defined in Wikipedia[1] to include both boxes, poles, and other structures that are designed to keep animals, specifically bears, out of your food while camping. There are only sixty-seven (67) instances of tag:amenity=bear_box in the database as of 2023-06-19 so changing to the new tag won't be a huge lift. Thoughts? R, Eric "Sparks" [0] https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dbear_box [1] https://en.wikipedia.org/wiki/Bear_cache ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] coastline v. water
You cannot point to other area that may, in fact, be improperly mapped as an example when they are like that because locals have been shouted down for doing it correctly. The fact that this keeps coming back up literally means that there is not universal agreement that "marginal seas", whatever that means, are to be mapped with natural=coastline. The Chesapeake Bay is an estuary that, by definition, opens to the sea. It can't be a sea and open to a sea at the same time. In this environment, it is different from the ocean in which it opens into and is also different from the tributaries that feed it. These are protected waters for ships. You won't find any high seas forecasts for the Bay unlike the ocean. The Bay is also brackish and not defined as salt water, unlike the ocean. If the rendering engine isn't showing it correctly, fix that; *that's* what's broken. Eric ‐‐‐ Original Message ‐‐‐ On Saturday, November 21, 2020 1:14 PM, Joseph Eisenberg wrote: > Eric, > I don't think the previous discussion is quite as inconclusive as your > evaluation. > > While it is true that there is not widespread agreement on where the > natural=coatline ways should transect a river mouth or river estuary, there > is nearly universal agreement that marginal seas, including bays, are mapped > with the natural=coastline. > > Using the rendering at https://www.openstreetmap.de/karte.html - which > differentiates the marine water polygons outside of the coastline from lakes > and rivers, by using slightly different colors, we can see how bays are > mapped in other parts of North America and the world. > > For example, check out Delaware Bay, just up the coast from your area: > https://www.openstreetmap.de/karte.html?zoom=10=39.14649=-75.07302=B000 > - it is mapped as a natural=bay with natural=coastline around it, not > natural=water > > Upper and Lower New York Bay are mapped as bays outside of the > natural=coastline - you can see the line where the waterway=riverbank area > starts just at the north end of Manhattan island (though this placement is > somewhat controversial) - > https://www.openstreetmap.de/karte.html?zoom=10=40.63628=-73.93525=B000 > > Tampa Bay: > https://www.openstreetmap.de/karte.html?zoom=10=27.80801=-82.63368=B000 > - outside of the natural=coastline > > Galveston Bay: > https://www.openstreetmap.de/karte.html?zoom=10=29.49869=-94.94249=B000TT > - outside of the natural=coastline > > San Francisco Bay and connected bays: > https://www.openstreetmap.de/karte.html?zoom=10=37.79939=-122.06911=B000TT > - outside of the coastline > > Puget Sound - while Lake Washington on the east side of Seattle is > natural=water, also most of the ship canal connecting them: > https://www.openstreetmap.de/karte.html?zoom=11=47.59544=-122.39252=B000 > > I would like to request that the tidal channels and estuaries around > Chesapeake Bay be re-mapped with natural=coastline. If you wish to keep the > natural-water polygons for the estuaries that is not a problem. > > But it would be contrary to normal practice to map the main body of > Chesapeake Bay as natural=water because it is clearly part of the sea - there > is no barrier between it and the open ocean, since there is an open channel > through US 13 where the tunnel is. While it is an estuary by hydrological > definitions, so are the Baltic Sea and all fjords and Puget Sound and San > Francisco Bay - all of which are mapped as outside of the natural=coastline. > > Also please consider that the community here approved the proposal for > waterway=tidal_channel which said that the area of tidal channels (aka tidal > creeks) should be mapped with natural=coastline at their edges - see > https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dtidal_channel#How_to_Map > and > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel > - most of the "creek" features along the Bay are tidal channels. > > -- Joseph Eisenberg > > On Thu, Nov 19, 2020 at 6:46 AM Eric H. Christensen via Tagging > wrote: > >> ‐‐‐ Original Message ‐‐‐ >> >> On Wednesday, November 18th, 2020 at 11:34 PM, Brian M. Sperlongano >> wrote: >> >>> This was fascinating reading. I do agree that we ought to have a definition >>> for what gets tagged natural=coastline, and I think it's fine if that >>> definition has some subjectivity. >>> >>> I would offer something as simple as: >>> >>> "The coastline should follow the mean high tide line. In some cases this >>> rule would result in the coastline extending an unreasonable distance along >>> the banks of tidal rivers. In those cases, mapper
Re: [Tagging] coastline v. water
‐‐‐ Original Message ‐‐‐ On Wednesday, November 18th, 2020 at 11:34 PM, Brian M. Sperlongano wrote: > This was fascinating reading. I do agree that we ought to have a definition > for what gets tagged natural=coastline, and I think it's fine if that > definition has some subjectivity. > > I would offer something as simple as: > > "The coastline should follow the mean high tide line. In some cases this > rule would result in the coastline extending an unreasonable distance along > the banks of tidal rivers. In those cases, mappers should identify a > reasonable choke point at which to terminate the inland extent of coastline > tagging." I would just classify it as "where the ocean meets the land". Any other water that isn't ocean should be mapped as water and tagged appropriately. That makes the map more accurate and detailed. R, Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] coastline v. water
‐‐‐ Original Message ‐‐‐ On Wednesday, November 18th, 2020 at 5:04 PM, Christoph Hormann wrote: > > Eric H. Christensen via Tagging tagging@openstreetmap.org hat am 18.11.2020 > > 21:19 geschrieben: > > > [...] > > First: the matter has been discussed at length previously so i would advise > anyone who wants to form an opinion on the matter to read up on past > discussion where essentially everything relevant has been said already. Most > relevant links: > > https://lists.openstreetmap.org/pipermail/tagging/2020-July/054405.html > > and resulting discussion: > > https://lists.openstreetmap.org/pipermail/tagging/2020-August/thread.html#54434 > > https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement Whew, after reading all of those messages, my take-away is that it's mostly what the locals see the water as. > Third: > > While this is ultimately not relevant because the delineation of tags in OSM > should be based on verifiable criteria obviously i have never seen any map > that displays ocean water and inland waterbodies in differentiated form that > shows the Chesapeake Bay as inland water. > > Classical examples with differentiated rendering are TPC/ONC (caution: links > go to large images): Pilot maps don't usually have lines deliniating sections of water. Marine charts do, however. R, Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] coastline v. water
‐‐‐ Original Message ‐‐‐ On Wednesday, November 18th, 2020 at 3:31 PM, Joseph Eisenberg wrote: > Consider that the natural=coastline is defined as representing the mean high > water springs line, that is, the line of the highest tides. If the line on an > open ocean beach is at the high tide line, it makes sense that all tidal bays > and estuaries should also be included in the area outside of the coastline. Then why the ability to mark natural=water as tidal and as salt? Clearly the ability to use those attributes leads me to believe that just being tidal does not make it be coastline. --Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] coastline v. water
After a few days of much work, a recent collaborative project to turn the Chesapeake Bay from a nothing space outlined by natural=coastline to what we considered to be a more accurate relation of natural=water, we've received some negative feedback. The difference of opinion seems to lie in the definition of what we're mapping. The use of coastline is for "seas"[0] while the use of water is for "inland areas of water"[1]. Even though the Chesapeake Bay is tidal, there is no question that it is an inland waterway (it is completely surrounded by land except for the mouth at its southeast side). The idea of using coastlines for basically creating an edge between the land and the nothingness of the ocean makes sense when, as far as the eye can see it's only water. Now, some of the feedback that has been presented[2] is that because it is tidal it is part of the sea. I have pointed out that many rivers and streams (and ditches!) are tidal; does that make them part of the sea? I would not think so. In fact, there are named seas on this planet that are not even connected to other water formations (the tiniest, according to the National Geographic, is the Sea of Marmara which has an area just less than 12,950 sq km, larger than the Chesapeake Bay). But, tagging the Chesapeake Bay, and its tributaries, as "water" brings several benefits to the map and the users. First, it helps identify the sections of water that exist in these areas (this can't really be done with node points as there is no way to define start and end points of an area). There are many defined bays, rivers, and streams that make up the greater Chesapeake Bay area. What one may see as one large mass of water is actually many smaller defined segments each with their own history. Second, we can speed up any updates (fixes) to outlines of the polygons that happen in these water areas without having to wait for the entire Earth's coastlines to be re-rendered. I suspect having less coastline to render would also speed up the rendering of coastlines as well? I would like for the tagging community to clarify the different between "water" and "coastline" and when to use each. The definition on water seems to say to use it on inland water but there seems to be, at least, and open interpretation of the word "sea" for coastline that is dragging many inland waters into that category. Thanks, Eric "Sparks" Christensen [0] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline [1] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater [2] https://www.openstreetmap.org/changeset/94093155#map=10/37.1620/-76.1581 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Evacuation Routes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ‐‐‐ Original Message ‐‐‐ On August 9, 2018 11:57 AM, Eric H. Christensen wrote: > I'm opening up my Evacuation Routes proposal[0] for voting. I think we've had > two good sessions of discussions for ironing out the bugs and it's time to > get this thing out the door! > > [0] https://wiki.openstreetmap.org/wiki/Proposed_features/Evacuation_routes This has had its two-week marinating period and I've had all positive votes (along with two comments). I'm claiming victory on this and will begin updating wiki pages later this afternoon. I'm planning on sending a message out on the talk-us list to better announce this new feature. Are there any other lists that may benefit from getting the word on this so we can go ahead and get these routes mapped? Thanks, Eric -BEGIN PGP SIGNATURE- Version: ProtonMail Comment: https://protonmail.com wsFcBAEBCAAQBQJbgAssCRCAdqveAkuz0QAAryUQAImXRAzSr8InHDTWuY1s aTsuXFBUouDC/RyFr+1qAyxaBx2GFf7aQ9S3SV0IbBnKhmBuomuFnfGAvtBZ 20Y2h6IgYoX2/PpEIQ0HfZ1UBdb4I66cXddYBgJ920ACwdmVQVuI7jx+3eaj q/Ps1vqGgWEzr4lHKofv0eLSR0GWAH1olMsWl0qCpUC1iNSTzCjgYf3d+qtH Tikl7GVbR7JGiMd24fnuSipj18OojgjWYjATDUJvdt07a/YHjZ9tbx+QYOrD 89ITfPgSw+qlDzNjahPouoRZBGOc9+kGwnXe02RwMfs8Fyp0lpeZ6vjzF410 i4j6jj1PO8B4ubX0ymLIqW5ztVaYc8BgV/qOqbuMpsWouRkaIMYQP3XLHdfn 8+XEQ7gfkr1nQT1G1bXc7zJZvT8SoQ59/Eny6NGO3Sejjcdg/OiAsjBt1Q6E Y+98rfEGYakXCaBN5+7/R+JhqQBNcvzKOziqgbZ85Z7xQhTBqspPvPECkp9d dL6yj7yX7bQAZap7BcTwu2h/zsKyWfxdtuaTcoNEJSpG+ZOARgiNzJrWifHv RP2C7Q2SQl0+HrPAhMPKqDAvWxfB7Je0LGOZxZESBYfOdiOwLnDZuR7TP4JT 8tFBO0Xfo0cjkqArIf9eQP1p7n2sW/CMxFhSImzFgRITvRSMMwEm/ZwzxizA 6kZ6 =NeGb -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Evacuation Routes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm opening up my Evacuation Routes proposal[0] for voting. I think we've had two good sessions of discussions for ironing out the bugs and it's time to get this thing out the door! [0] https://wiki.openstreetmap.org/wiki/Proposed_features/Evacuation_routes Thanks, Eric -BEGIN PGP SIGNATURE- Version: ProtonMail Comment: https://protonmail.com wsFcBAEBCAAQBQJbbGRRCRCAdqveAkuz0QAAOIAP/Rd0/+Clv4wMesiWU4Lu 2476V4MTaKpF7wmuHuwnXlf2hti07mxu6H0dt8FzCQAQ1wF9O2+j4o06jWpy i8qThaSGraU6eiazHrzJQ8cA9doEPFKRZ+piUAapRo7CS6rTOftEGva1jCIa JfW8KJ3kX2urQ332DTtQ/mc42ifJ7aVfuOp9UcwJ3K9uYHH7bUPlqENB3/DN vAbbnIl+YlAHtc6/Ye+ZmYKx1NgHgR/xV4iF2wyo2i021Q1C7ykAde8t7yOL 4HMY/O62gv9Ibtp1zE0m0Hr4gzLjMNeOH1047x8+hjNQa0csfucVw3t1pnhm /TfMLkpLwv5obU4YqPPoiTnziFMeI4hiUtXaXPiIuo1bUJTpQq2pIc+JEceK lWbsei//6HglwNYsFNYCqS/mgr7sYX9gJXHfrnZ7CPXeOCDRTh4Mrnp1K1AY q0Uo/Ml/lii0YBj0kBHCNNLx7aTPd2f9HOz7RlQoxLZpDQzuEqo10xW3UpWP ScjSj9aLZv1BgdyGD86YJEyFoJnhdbzQPF1+vfc/kLB5Q+ndI5oAUdEFHJkL pWxebiLoTgOZ1tWELdt7gnVG1/8v4tO1BmLY+OhFgOGryJJsRqMcAG+f97HE 6diB7HhvpJfqtLom9VDoyTdY4ol0ET/DPg+JCbwNQ9m8Y2YRF8NZwk7CwoAC 0WdT =rSoA -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Evacuation Route
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 -‐‐ Original Message ‐‐‐ On August 7, 2018 11:27 AM, Martin Koppenhoefer wrote: > > On 6. Aug 2018, at 06:30, Warin 61sundow...@gmail.com wrote: > > And it might be better to place it directly in the emergency key? > > Say emergency=evacuation_route??? Humm emergency says it is not for > > relations. Arr well. > > I think there shouldn’t be “relations” at all as category for objects to > which a tag can apply. Nodes, ways (linear), areas (ways) would seem > sufficient for that. Relations can be set to unknown for everything ;-) > > The relation category is misleading anyway because it doesn’t include > multipolygon relations, and nobody knows what kind of relation will be > invented or is already used that creates all kind of geometric thing where a > tag could apply to or not. I'm not certain of all the categories. I'm envisioning this being more like an overlay route like what is used for bicycle routes and bus routes and the like. What are those? Eric -BEGIN PGP SIGNATURE- Version: ProtonMail Comment: https://protonmail.com wsFcBAEBCAAQBQJbabwpCRCAdqveAkuz0QAAQhoP/jILBF94dPUshbEMOWy4 P/A+GOUNUW7IvEZSTjngPiT1xillNb2s529fBQQKB7mgj730r1qhLlJeNAQr jMI5ffqX2K1DehBrhCd6AJD3bizYqiywHVhqmHPtJ0Zg0eQ26YV5HBLmUPcf yol64IhWm27zhgdR//ZwGHv40d48O4672KEXYKJK6kZblvQWmV1t0uZaWy2/ wdnTJngLqkgnXxOxl7t45k3N7o4RppxjwemKwf5vAxDsmUO2S3Ap8eWj7orF +qIGiU8N+WIcr5p700xDy/DygFNXReMUKuKLTjnfRYzQEOvzaSGd98SdZ6PC u8FarWX5n90To2539D4RruuPgEzWjrAYt6JK5gUQdTJuIeGIDHmXqDwKnGFe 5hfnqV5kFXvOZoqgdxURLFKgwR4jFiPagwzCtEwt+1DG6MsLTOkXqOUEMwBg Lj8bj7PFVxlAPrWyMCPjeHr/OU0v252yqo3/knk3C1QjPakF+UFxEpbAUpJ2 IZBE0EzPVuo4jDna/ifEY/VDgQe5JHXAtso8tHZTRsaGL+rff9uDOxOrlsjA dTpq630s19Jwn2cwZNdPz/sTAUMaBlZ6gv30PIZmpssMvmtq9JSKcrWYhX72 Q82uILVn/oohQ77hIFi9wdPhfg9kWwCS4Eq3IDYAnY08wxJXrCrCCIQDQbYa e5sr =+kwJ -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Evacuation Route
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ‐‐‐ Original Message ‐‐‐ On August 6, 2018 2:02 AM, Warin <61sundow...@gmail.com> wrote: > On 06/08/18 15:27, Eric H. Christensen wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > ‐‐‐ Original Message ‐‐‐ > > On August 6, 2018 12:30 AM, Warin 61sundow...@gmail.com wrote: > > > > > I'd think this should be a relation - not a way. > > > At the moment the proposals says it is only a way. > > > And it might be better to place it directly in the emergency key? > > > Say emergency=evacuation_route??? Humm emergency says it is not for > > > relations. Arr well. > > > We went down this path, I think, last summer. The expectation is that > > > these route made up of roads. I'm not sure why one would include a node > > > in this. This is likely going to be part of the emergency project but > > > probably not the emergency key which isn't really for routes. > > I have not mentioned 'nodes'. > On the proposal page - in edit mode there is: > {{Proposal_Page > |name = Evacuation Route > |user = Sparks > |key = evacuation_route > |value = * > |type = {{IconWay}} > > The type should be {{IconRelation}} not {{IconWay}}. > As it is with {{IconWay}} there will need to be new ways created for the > evacuation route > rather than use the existing ways that are roads/paths etc as members in a > relation. > > And I would think there need to be rules for the relation, for example; > start at one end and have each member/way in sequence to the finish, the > finish might be required to be in/near the 'safe place'. > This would save the forwards backwards thing, just like in Public transport > v2. Ahh, yes, sorry, I see what you're talking about now. > > > Rendering... yes .. a rendering for emergency use would be good. > > > Possibly this can be done for small areas rather than the world. > > > Emergency evacuation centres, routes etc. > > > I'm not sure I understand this. I suspect these types of routes are > > > preplanned in many different countries. > > Yes. But I'm thinking of the rendering. I think that would be done for local > areas, not the entire world. Yeah, this would definitely be more smaller areas (towns, regions, states, islands). > > > > Evacuation routes may also be made for other things .. e.g. fire .. so > > > I'd add a '/*' at the end to accommodate things we have not though about. > > > Even if you create a route for a fire, and I'm assuming you're talking > > > about a building fire, you'd be showing routes inside of a building which > > > would require ways. I don't think the existing proposal would prevent > > > someone from expanding to such things but I'm trying to tackle the > > > problem of evacuation routes along roads that have been preplanned for > > > emergencies and disasters. > > Wrong kind of fire .. though those too might one day be mapped. > But I mean forest fires/wild fires/bushfires depending on what part of the > world your from. > But I would tag them as 'fire' rather than do all the different ways that > people refer to them. > I'd still add the '/*' to it. Just in case. Oh sure. --Eric -BEGIN PGP SIGNATURE- Version: ProtonMail Comment: https://protonmail.com wsFcBAEBCAAQBQJbaFNDCRCAdqveAkuz0QAAH0kQAJW09vrmW4ZGwdbO88P9 lUb2f/0AlgOMaRezh91SZqoqhoDfOhMr8qB63IGU2xbvvde9Scsj1U06Clob zr+OOvyWZIhAa/ayKPlxhkHtjAlj3VxNCaLg1T/1kUJN2avYFgMD43ahdwGP Cn2bmUcQijcfEZXOW5r5JeF0Xy+DeNOg2ST2T3e4EGSUIWZpC2FWnGdpQ5nA G1pNfGX6GbMafYjZMQ245VlpfzOe5qeU76nAAQ3Ek9Rk5L3eFa/HegeV2Pwm QhPBR6jz5rGA51a15gvOpDUQXiVcbmqyg0eNx6yQi8IdXo51RVvb8oT+nZCQ monRbHeR5BX149hTqFQTaUJC/F2qmzgGg2ZsmlCXeyDfkEzYTj7WttePD/QU /r8rLs5po0mSVli4OzYrhzkdfb0jPHhJwu+XDQ6zHqD8onWZDEMBbL70lWfZ 5n/H1qJZJBLxD2coR4uujESA/DTkzlY9aAteME/I7yb4JQr5+NEgNk7pYH2Y vcTkpTZ5TwpE9YpMIwDc+eHKSHtW84oETiJ+o8lHpjO3ormZpspYisPz7l07 teQYrJPHYwYcMvZ45EV20PMURKOCkxErgIa6uOft9jBqDE2B3klc7ovDsp4l RZIvMbQji/keed3cHEN56fX1sRjc52C0SPCZprkmHFcp2padKbRpv1oVgxub KTBa =N+HH -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Evacuation Route
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ‐‐‐ Original Message ‐‐‐ On August 6, 2018 12:30 AM, Warin <61sundow...@gmail.com> wrote: > I'd think this should be a relation - not a way. > At the moment the proposals says it is only a way. > > And it might be better to place it directly in the emergency key? > Say emergency=evacuation_route??? Humm emergency says it is not for > relations. Arr well. We went down this path, I think, last summer. The expectation is that these route made up of roads. I'm not sure why one would include a node in this. This is likely going to be part of the emergency project but probably not the emergency key which isn't really for routes. > Rendering... yes .. a rendering for emergency use would be good. > Possibly this can be done for small areas rather than the world. > Emergency evacuation centres, routes etc. I'm not sure I understand this. I suspect these types of routes are preplanned in many different countries. > Evacuation routes may also be made for other things .. e.g. fire .. so I'd > add a '/*' at the end to accommodate things we have not though about. Even if you create a route for a fire, and I'm assuming you're talking about a building fire, you'd be showing routes inside of a building which would require ways. I don't think the existing proposal would prevent someone from expanding to such things *but* I'm trying to tackle the problem of evacuation routes along roads that have been preplanned for emergencies and disasters. Eric -BEGIN PGP SIGNATURE- Version: ProtonMail Comment: https://protonmail.com wsFcBAEBCAAQBQJbZ9xPCRCAdqveAkuz0QAAWZIP/3+0RLerwgB5ODpYHu45 JBZQmuaccYarcF9vWP20nN9lxhm0RCNQfXodBnPQgF9Ms1w+LW/lobLYyViV cRy8Rbvgt68OzZi+Ll5KovsJbiAAD+03SZmZfVnW4W+kZ5A9TDk7MQjucpMh dDnI6K/lxEC/jEuGj5R5nflVn24PZdcDseiK1SEvNg+qlLG/tatbpQB0p0nu C+T/eAJA+uRWQiRlevoQ6notgOnxTDp/1k74O8tnD/P85+Pystf7UbUWJcCV bXf8uG9TtKN9ccY3tXC1VD5TbAf+NQeSPoTvuMomBUXWBPI66+EyjS+gdUd7 eZJitOYChN3TWM6ydovwKc1PBj0u7jjz8w+CIQhDVtmPGRR+8WHiyCbIWxn+ PuwSJ4Lq88QcVPL4/qQ0+9dYilF4sF5dmC5byrxIVnAqyH2tccoLiIJTBwyE pPQOjPOtxp3FAPj3DSHBPJfWfsCrDHS9a0fYus6p6OwepjElX5T1Nx2O7+b4 xw6iBmGopsh9RkI1XuH8SCXr1hxrGAnTcCFNi17Ch18c6wXd67n4qRb10OGk fzqoPlsLGeTxhCg+j53fu1T2rurIOWqKqqHID9OdZ67pXVPjyH94KUCMU8BG budfddKeR03CGxTt7oejpP2kDHfp9pyJv/tC9viDQVHVQMo1kvDw9mh+dYcU JaVs =XRZZ -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Evacuation Route
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Last year I made a feature proposal[0] last year regarding evacuation routes. There were a couple of recommended changes to the RFC[1] and while I agreed with them I 1) failed to make them and 2) got side tracked on a couple of other initiatives. Now that it's hurricane season, again, here in the Eastern U.S. I've come back to this and am hoping to get this completed this time. I've changed this from being a key to being a route, which makes better sense. Does anyone see any other changes that need to be made or can we go ahead with a vote? Thanks, Eric [0] https://lists.openstreetmap.org/pipermail/tagging/2017-September/033340.html [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Evacuation_routes -BEGIN PGP SIGNATURE- Version: ProtonMail Comment: https://protonmail.com wsFcBAEBCAAQBQJbZ7GNCRCAdqveAkuz0QAAglIQAID9i9veNNDUZiFVvNyl J4GA3cEsCxfYZCDvE2d/SPcZoGWN322FKgsvtW8VUaGB5ZsYFBs0nE70VDHY WLxmURjOPb3l+w5w0r32TAuMzWxpz9rMHephgTfbmOWsvV3JNt3cTkXcgY47 2cxZu/CcFn2yemJsgPVx7ENeWdUTjwzdvOe6lWlqCt6yK6A+1VjZEDOK54CW fGaWlEQe7HRq+oVyTSAgNUEKjjViyLjx2BDuH7Sx1GVW98AocJqrYmDl3vEq LTl8pbBJ39iSXjBB6B5alN9JYWegtaF40TSBPT8m1ey3Fy0YF9hbZbL8qXTu kMQIvfDcw+vabO+ZeJkhozsMi/0IQvBZzHsJrYOJW2hbiSZHg1508pbiugJv juMqaYJvzie7cPNBmW/fI3d06/4GeenzBBKgF6TwANbEKyfgjZrROVjug1A9 p+RHXchjYIxLrrHKCmLQzD+LjmMcBvjxrGBnAEnpdzizz2fkuwM0P2tpaAO8 bkNIBcXUJW0d+Ev8pnOzf28gCDJNvdP3FHfTvDOcDnTCmFBKtLOf7O4pNuE4 lNBnwLa4xes25pOgZId5Pn+B/qJ5TH9s9EVUJwYFW33n/IU2yScDTTYGsa+V 4YEFvyU2G5Ch4N5zCLKtgP4ItYYFGg3MpiXV5Jm3M6quuhmwGCTllRYODY9a xxkH =BWIM -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
On August 17, 2017 11:38:10 AM EDT, Richard Weltywrote: >On 8/17/17 10:25 AM, Eric Christensen wrote: >> >> That's not really what's being discussed here. A non-pressurized >> hydrant wouldn't be attached to a tank at all. It would require a >fire >> engine to suck the water out. It does not look like a traditional >fire >> hydrant at all. >there are always exceptions. not far from me, there's a traditional >hydrant of the type normally used with pressurized systems, but >it's sourced from a pond. the reason is that the pond is elevated, some >distance from the road, and they need to keep the barrel empty >when it's not in use for the usual reasons. > >richard > >-- >rwe...@averillpark.net > Averill Park Networking - GIS & IT Consulting > OpenStreetMap - PostgreSQL - Linux > Java - Web Applications - Search > > >___ >Tagging mailing list >Tagging@openstreetmap.org >https://lists.openstreetmap.org/listinfo/tagging Then that is a pressurized system and doesn't require drafting (there is gravity at work if the pond is elevated above the connection point). The whole point of a dry hydrant is to make drafting easier. Drafting is the pulling of water up by use of a pump. If the water is coming down then you don't need to pull the water and can do damage to many water systems if you do. Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging