Re: [Tagging] Topographic Prominence for Peaks
I don't see no issue in mapping prominence for those interested in. Just to mention for the sake of the discussion that 'sufficiently accurate DEM' doesn't exists globally. Yves ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Topographic Prominence for Peaks
On Sun, Sep 23, 2018 at 9:29 PM Bill Ricker wrote: > This all seems like highly specialized, technical data that is not of > general interest, as no one but peak-baggers understand the technical > definition. Many map users seeing this prominence=999m factoid would > jump to the incorrect conclusion that it was relative to where the > (lower of the) watershed(s) drains the mountain and thus a synonym for > the net rise from the valley.(Which is what i read the original post's > introductory remarks as meaning until I read further and got to the > technical definition.) "The (lower of the) watershed(s) that drains the mountain" is a phrase with unclear meaning. If by that you mean the highest origin of a stream on the mountainside, that's usually pretty high up. If you mean "the bottom of the deepest nearby valley", how far downstream do you go, and how do you define where to stop? It's very hard to come up with a coherent, objective definition that stops short of "sea level". For mountains that are close to higher mountains, the prominence is almost always "the height of this mountain above the highest pass on any side", which is as good a definition as any. For mountains that are the highest in their ranges, the prominence is, as you might expect, roughly "the height of this peak above the surrounding plain". The only thing that is "highly technical" is that it is quite difficult to come up with a definition for topographic prominence with the necessary mathematical rigour to make it objective. If you look at a list of mountains of the Earth having the highest prominence, and compare it with the list of the highest elevation, you will see that prominence actually does a fairly good job at capturing "local importance:" By elevation: 1. Everest 2. K2 3. Kanchenjunga, India/Nepal 4. Lhotse I, Nepal/Tibet 5. Makaku I, Nepal/Tibet 6. Cho Oyu, Nepal 7. Dhaulagiri, Nepal 8. Manaslu I, Nepal 9. Nanga Parbat, Pakistan 10. Annapurna I, Nepal 11. Gasherbrum I, Pakistan/China 12. Broad Peak, Pakistan/China 13. Gasherbrum II, Pakistan/China 14. Shisha Pangma, Tibet By prominence: 1. Everest 2. Aconcagua (High point of S. America) 3. Denali (Mt. McKinley - high point of N. America) 4. Kilimanjaro (High point of Africa) 5. Cristobal Colon (High point of Colombia) 6. Mt. Logan (High point of Canada) 7. Pico de Orizaba (High point of Mexico) 8. Vinson Massif (High point of Antarctica) 9. Puncak Jaya (High point of New Guinea) 10. Mt. Elbrus (High point of Europe) 11. Mont Blanc (High point of the Alps) 12. Damavand (High point of Iran) 13. Kluchevskaya Volcano (High point of Asian Russia) 14. Nanga Parbat (High point of Pakistan) The first list is confined to the Himalayas, and contains many relatively obscure entries. The second list has peaks on every continent except Australia, and consists entirely of "This is the highest point in (major geographic feature)" In any case, topographic prominence is very closely related to the theory of surface network modeling, which in turn ties closely into research into the representation of terrain with as few data points as possible. > Is the OSM primary DB the right repository for this? > Have we accepted being the repository for everything that anyone wants to map? > (I don't remember hearing a change from "no".) Do we really want to get into the argument that objectively verifiable attributes of real-world features should NOT be mapped because they are not of sufficiently general interest? "Objectively verifiable," "actually representing objects in the field," and "obtainable by direct survey or from license-compatible data sets" are already a high bar. I had not heard that the decision of what may be mapped also has to win a popularity contest! It isn't a very long step from saying 'topographic prominence should not be mapped because it is of interest only to mountaineers' to saying 'hiking trails should not be mapped because they are of interest only to hikers', or 'navigational aids on waterways should not be mapped because they are of interest only to sailors.' 'Radio repeaters should not be mapped because they are of interest only to Amateur Radio operators." "Specimen trees should not be mapped because they are of interest only to conservationists." Where does it end? Do we need to start conducting a census of OSM users to determine whose interests are important enough to include? I'm sorry, but to me, your message comes across as saying, "this thing does not interest ME and I misunderstood it at first reading, therefore YOU may not map it and must go elsewhere." That's a positively insulting message to be sending. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag a building constructed for a gastronomic purposes?
On Mon, Sep 24, 2018, 7:52 AM Martin Koppenhoefer, wrote: > I’ve recently used building=fast_food_restaurant > but it is not used very often yet. > Can you care to explain why building=retail is not enough detail? I would think that a combination of building=retail + amenity=fast_food (whether on the same polygon or on separate polygon + interior node) is already sufficient. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Topographic Prominence for Peaks
On Mon, Sep 24, 2018, 9:29 AM Bill Ricker, wrote: > Is the OSM primary DB the right repository for this? > Have we accepted being the repository for everything that anyone wants to > map? > (I don't remember hearing a change from "no".) > If people are already mapping whether an amenity=fuel is dispensing a particular octane of fuel, then mapping topographic prominences is surely acceptable, especially since prominence is certainly a more geospatial concept than fuel octanes. One thing I am quite sure of that is true in OSM is that we (within reason) don't prevent people mapping the things they are interested in whether they are peak baggers interested in mountain height stats, pet lovers mapping dog-friendly amenities inside public parks, or conservationists mapping species=* for individual notable trees. But if you insist that this prominence data is out-of-scope for the OSM DB, then at least consider advocating that these peaks and mountains be tagged with their corresponding Wikidata items via the wikidata=* tag. Most Wikidata items on peaks and mountains already have their topographic prominence encoded as can be seen for this Wikidata item for the Matterhorn (prominence is 1031m): https://www.wikidata.org/wiki/Q1374 > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Topographic Prominence for Peaks
This all seems like highly specialized, technical data that is not of general interest, as no one but peak-baggers understand the technical definition. Many map users seeing this prominence=999m factoid would jump to the incorrect conclusion that it was relative to where the (lower of the) watershed(s) drains the mountain and thus a synonym for the net rise from the valley.(Which is what i read the original post's introductory remarks as meaning until I read further and got to the technical definition.) Is the OSM primary DB the right repository for this? Have we accepted being the repository for everything that anyone wants to map? (I don't remember hearing a change from "no".) The definition that has Mt Everest (or K2, whichever is taller :-) ) have its "prominence" defined to sea-level and every other peak on the combined continent is defined to a col which may or may not be actually near is just weird. Yes Peak Baggers need some such rule to avoid every boulder above 4000ft being defined as a Peak but is it a useful definition for any other purpose? Unless it's useful elsewhere, the peak baggers can extract OSM data under the terms of the license and extend their own copy of the data with "prominence" and other useful-to-them meta-data such as official checklist name/number. This Prominence definition is not a number which is signed on the peak nor is it measured at the peak, but is derived data. Which with the right setup, could could and should be calculated in bulk, not by individual mappers. Which suggests to me further evidence it should be computed and hosted at a downstream database clone that has DEMs and mountaineer-specific rendering options. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag a building constructed for a gastronomic purposes?
sent from a phone > On 23. Sep 2018, at 17:13, John Willis wrote: > > Building=retail if it is a purpose-built building for selling stuff ( a chain > restaurant, a McDonald's, etc), as it is purpose-built for retail. I’ve recently used building=fast_food_restaurant but it is not used very often yet. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Topographic Prominence for Peaks
On Sun, Sep 23, 2018 at 5:40 PM Joseph Eisenberg wrote: > Yes, “prominence” here is a technical term that has only a partially > connection to the subjective “importance” of a peak. > > In general, all peaks with high topographic prominence are considered > important by local people (if anyone lives near them) and mountain climbers, > but some peaks with low topographic prominence are also well-known, eg the > Matterhorn. > > I see that the old, abandoned proposal also suggests the possibility of > making a relation to show the parent peak and key col. These sort of > relations may not be useful to data users, but they might help other mappers > to verify the prominence data. > > Personally, I won’t add new relations when the key col and parent peak are > close by, but I will if they are far away. Exactly. None of our data model is set up to say, "you must map all features of a given place." It's more, "if you're mapping *this*, consider mapping *that* as well, and here's how to represent it." And yes, when key col and parent peak are distant, it gets weird. As a quick test, I looked up Slide Mountain in the Catskill Mountains of New York https://www.openstreetmap.org/node/357602650 elevation 1276 m, prominence 1000 m. I would have guessed that its line parent would be on the way to Killington Peak, Vermont https://www.openstreetmap.org/node/3139475460, which is both the nearest higher peak and the nearest more prominent peak, but in fact, the deep valleys of the Hudson and Mohawk rivers mean that the line leads away, with a key col somwhere near https://www.openstreetmap.org/#map=15/42.1653/-76.8190 and the next higher point being an insignificant knoll in the Monongahela National Forest in West Virginia. Who knew? By contrast, it mighn't be worthwhile mapping the key col and line parent for Hunter Mountain https://www.openstreetmap.org/node/357598537 - its parent is Slide Mountain (link above) and the key col is somewhere in the pass near the Bellearyre ski resort https://www.openstreetmap.org/#map=16/42.1447/-74.4915=N In any case, the point remains that topographic prominence is a completely objective metric; it can be computed from a sufficiently accurate DEM; but is computation is sufficiently onerous that it's worthwhile capturing and recording the results. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Emergency=levee_breach_materials
CMF BJ G On Mon, Sep 24, 2018 at 6:55 AM Joseph Eisenberg wrote: > Good idea. It would be nice if these stockpiles of materials could all be > tagged in a similar way. Piles of sand could also be used for flood control > (eg to fill sandbags), while minds gravel and rocks could be used to repair > roads, dikes, and so on. > > BTW, I believe the British English term is “dike” instead of “levee” > On Mon, Sep 24, 2018 at 3:24 AM John Willis wrote: > >> >> > On Sep 23, 2018, at 6:33 AM, Anton Klim wrote: >> > >> > not levee_repair? >> >> Hmm - no one at that location repairs levees. It is a station just to >> store blocks. >> >> I just want it to be unambiguous. >> >> Like the difference between car repair and car parking >> >> Even then, levee_repair might be good enough. >> >> I know there are gravel and salt (bunkers?) Along the sides of roads - >> I'll have to see how they are tagged. >> >> Javbw. >> >> >> >> ___ >> 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] Topographic Prominence for Peaks
Mf Fly Henry H Rhmmm On Mon, Sep 24, 2018 at 6:38 AM Joseph Eisenberg wrote: > Thanks Kevin > Yes, “prominence” here is a technical term that has only a partially > connection to the subjective “importance” of a peak. > > In general, all peaks with high topographic prominence are considered > important by local people (if anyone lives near them) and mountain > climbers, but some peaks with low topographic prominence are also > well-known, eg the Matterhorn. > > I see that the old, abandoned proposal also suggests the possibility of > making a relation to show the parent peak and key col. These sort of > relations may not be useful to data users, but they might help other > mappers to verify the prominence data. > > Personally, I won’t add new relations when the key col and parent peak are > close by, but I will if they are far away. > > Joseph > > On Mon, Sep 24, 2018 at 4:00 AM Kevin Kenny > wrote: > >> On Sun, Sep 23, 2018 at 9:34 AM Michael Reichert >> wrote: >> > (1) If you assume the earth to be a plane, just order the peaks by their >> > elevation. It's so simple that I don't give the necessary SQL query >> > here. If we used a prominence=* key, it would have to be the distance to >> > the next higher peak. If the value were not a number but a term like >> > "most_important", "very_important", "neighbour_of_highest" etc. it would >> > not comply with the verifiability requirement of OSM and invite people >> > to have edit wars. >> >> This misunderstands the concept of topographic prominence. A peak's >> parent in the prominence hierarchy is not the nearest higher peak. It's >> the higher peak for which the least descent is required from a given peak >> a path that joins them can begin a continuous ascent to the higher peak. >> >> > (2) If you assume the earth to be an ellipsoid, it is more difficult but >> > still achievable with ele=* tags in OSM and elevation raster data (SRTM >> > etc.) only. There is an open source solution to do so. >> > https://gitlab.com/nuntius35/extremal_peaks/blob/master/README.md >> > (mentioned in WeeklyOSM issue 423) >> >> That is correct - but SRTM is of insufficent resolution for an accurate >> prominence calculation, and the calculation is extremely expensive for >> an extremely prominent peak, where the key col can be hundreds or >> or thousands of km away. It's worth precomputing and tabulating. >> >> > (3) If we use a tag like prominence=* for peaks two mappers will have a >> > different opinion on the value to choose. For example, the Matterhorn is >> > 4478 m high but Monte Rosa is 4634 m high and not that far away. >> > However, the Matterhorn is more famous and people expect it to appear on >> > maps at the same or lower zoom scales than Monte Rosa. Whose opinion is >> > correct? From my point of view, the mapper using the elevation only >> > because that is the only verifiable fact while the prominence in >> > advertisement is something we don't record in OSM for a very good >> > reason. (Please replace "peak" by "city" and "height" by "population" >> > and read this paragraph again) >> >> Topographic prominence is entirely objective; it's a well-defined >> numerical quantity. It is not to be confused with social prominence. >> Sorting peaks by topographic prominence at a low zoom level would >> be an interesting idea, It would surely not fix the 'Matterhorn' >> vs 'Monte Rosa' problem, but it might well help the situation >> where a low-zoom map shows rather insignificant subsidiary >> mountains rather than the prominent peaks of a range. >> >> About all that I'd have to say about the proposal is that it >> would be useful - and would probably need a new type >> of relation - to tabulate key col location and parent peak >> as well as prominence. The relation would have three >> members: >> parent_peak - A point object representing the parent peak >> subsidiary_peak - A point object representing the subsidiary peak >> key_col - A point object representing the key col >> and be tagged 'type=topographic_prominence'. >> The prominence of a subsidiary peak can then be >> deduced by subtracting the key col elevation from that >> of the subsidiary peak. (Alternatively, 'prominence=' >> could be added as a tag on the relation, but that's rather a >> redundant representation.) >> >> ___ >> 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] Emergency=levee_breach_materials
Good idea. It would be nice if these stockpiles of materials could all be tagged in a similar way. Piles of sand could also be used for flood control (eg to fill sandbags), while minds gravel and rocks could be used to repair roads, dikes, and so on. BTW, I believe the British English term is “dike” instead of “levee” On Mon, Sep 24, 2018 at 3:24 AM John Willis wrote: > > > On Sep 23, 2018, at 6:33 AM, Anton Klim wrote: > > > > not levee_repair? > > Hmm - no one at that location repairs levees. It is a station just to > store blocks. > > I just want it to be unambiguous. > > Like the difference between car repair and car parking > > Even then, levee_repair might be good enough. > > I know there are gravel and salt (bunkers?) Along the sides of roads - > I'll have to see how they are tagged. > > Javbw. > > > > ___ > 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] Topographic Prominence for Peaks
Thanks Kevin Yes, “prominence” here is a technical term that has only a partially connection to the subjective “importance” of a peak. In general, all peaks with high topographic prominence are considered important by local people (if anyone lives near them) and mountain climbers, but some peaks with low topographic prominence are also well-known, eg the Matterhorn. I see that the old, abandoned proposal also suggests the possibility of making a relation to show the parent peak and key col. These sort of relations may not be useful to data users, but they might help other mappers to verify the prominence data. Personally, I won’t add new relations when the key col and parent peak are close by, but I will if they are far away. Joseph On Mon, Sep 24, 2018 at 4:00 AM Kevin Kenny wrote: > On Sun, Sep 23, 2018 at 9:34 AM Michael Reichert > wrote: > > (1) If you assume the earth to be a plane, just order the peaks by their > > elevation. It's so simple that I don't give the necessary SQL query > > here. If we used a prominence=* key, it would have to be the distance to > > the next higher peak. If the value were not a number but a term like > > "most_important", "very_important", "neighbour_of_highest" etc. it would > > not comply with the verifiability requirement of OSM and invite people > > to have edit wars. > > This misunderstands the concept of topographic prominence. A peak's > parent in the prominence hierarchy is not the nearest higher peak. It's > the higher peak for which the least descent is required from a given peak > a path that joins them can begin a continuous ascent to the higher peak. > > > (2) If you assume the earth to be an ellipsoid, it is more difficult but > > still achievable with ele=* tags in OSM and elevation raster data (SRTM > > etc.) only. There is an open source solution to do so. > > https://gitlab.com/nuntius35/extremal_peaks/blob/master/README.md > > (mentioned in WeeklyOSM issue 423) > > That is correct - but SRTM is of insufficent resolution for an accurate > prominence calculation, and the calculation is extremely expensive for > an extremely prominent peak, where the key col can be hundreds or > or thousands of km away. It's worth precomputing and tabulating. > > > (3) If we use a tag like prominence=* for peaks two mappers will have a > > different opinion on the value to choose. For example, the Matterhorn is > > 4478 m high but Monte Rosa is 4634 m high and not that far away. > > However, the Matterhorn is more famous and people expect it to appear on > > maps at the same or lower zoom scales than Monte Rosa. Whose opinion is > > correct? From my point of view, the mapper using the elevation only > > because that is the only verifiable fact while the prominence in > > advertisement is something we don't record in OSM for a very good > > reason. (Please replace "peak" by "city" and "height" by "population" > > and read this paragraph again) > > Topographic prominence is entirely objective; it's a well-defined > numerical quantity. It is not to be confused with social prominence. > Sorting peaks by topographic prominence at a low zoom level would > be an interesting idea, It would surely not fix the 'Matterhorn' > vs 'Monte Rosa' problem, but it might well help the situation > where a low-zoom map shows rather insignificant subsidiary > mountains rather than the prominent peaks of a range. > > About all that I'd have to say about the proposal is that it > would be useful - and would probably need a new type > of relation - to tabulate key col location and parent peak > as well as prominence. The relation would have three > members: > parent_peak - A point object representing the parent peak > subsidiary_peak - A point object representing the subsidiary peak > key_col - A point object representing the key col > and be tagged 'type=topographic_prominence'. > The prominence of a subsidiary peak can then be > deduced by subtracting the key col elevation from that > of the subsidiary peak. (Alternatively, 'prominence=' > could be added as a tag on the relation, but that's rather a > redundant representation.) > > ___ > 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] Topographic Prominence for Peaks
On Sun, Sep 23, 2018 at 9:34 AM Michael Reichert wrote: > (1) If you assume the earth to be a plane, just order the peaks by their > elevation. It's so simple that I don't give the necessary SQL query > here. If we used a prominence=* key, it would have to be the distance to > the next higher peak. If the value were not a number but a term like > "most_important", "very_important", "neighbour_of_highest" etc. it would > not comply with the verifiability requirement of OSM and invite people > to have edit wars. This misunderstands the concept of topographic prominence. A peak's parent in the prominence hierarchy is not the nearest higher peak. It's the higher peak for which the least descent is required from a given peak a path that joins them can begin a continuous ascent to the higher peak. > (2) If you assume the earth to be an ellipsoid, it is more difficult but > still achievable with ele=* tags in OSM and elevation raster data (SRTM > etc.) only. There is an open source solution to do so. > https://gitlab.com/nuntius35/extremal_peaks/blob/master/README.md > (mentioned in WeeklyOSM issue 423) That is correct - but SRTM is of insufficent resolution for an accurate prominence calculation, and the calculation is extremely expensive for an extremely prominent peak, where the key col can be hundreds or or thousands of km away. It's worth precomputing and tabulating. > (3) If we use a tag like prominence=* for peaks two mappers will have a > different opinion on the value to choose. For example, the Matterhorn is > 4478 m high but Monte Rosa is 4634 m high and not that far away. > However, the Matterhorn is more famous and people expect it to appear on > maps at the same or lower zoom scales than Monte Rosa. Whose opinion is > correct? From my point of view, the mapper using the elevation only > because that is the only verifiable fact while the prominence in > advertisement is something we don't record in OSM for a very good > reason. (Please replace "peak" by "city" and "height" by "population" > and read this paragraph again) Topographic prominence is entirely objective; it's a well-defined numerical quantity. It is not to be confused with social prominence. Sorting peaks by topographic prominence at a low zoom level would be an interesting idea, It would surely not fix the 'Matterhorn' vs 'Monte Rosa' problem, but it might well help the situation where a low-zoom map shows rather insignificant subsidiary mountains rather than the prominent peaks of a range. About all that I'd have to say about the proposal is that it would be useful - and would probably need a new type of relation - to tabulate key col location and parent peak as well as prominence. The relation would have three members: parent_peak - A point object representing the parent peak subsidiary_peak - A point object representing the subsidiary peak key_col - A point object representing the key col and be tagged 'type=topographic_prominence'. The prominence of a subsidiary peak can then be deduced by subtracting the key col elevation from that of the subsidiary peak. (Alternatively, 'prominence=' could be added as a tag on the relation, but that's rather a redundant representation.) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Emergency=levee_breach_materials
> On Sep 23, 2018, at 6:33 AM, Anton Klim wrote: > > not levee_repair? Hmm - no one at that location repairs levees. It is a station just to store blocks. I just want it to be unambiguous. Like the difference between car repair and car parking Even then, levee_repair might be good enough. I know there are gravel and salt (bunkers?) Along the sides of roads - I'll have to see how they are tagged. Javbw. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag a building constructed for a gastronomic purposes?
Building=retail if it is a purpose-built building for selling stuff ( a chain restaurant, a McDonald's, etc), as it is purpose-built for retail. If it is a rentable location in a mixed use building (shop spaces on the bottom, apartments on the 2nd floor) we have no suitable building tag for them (so =yes). Very large apartment buildings (15 stories tall) often have shops on the first floor, I would tag that busing as =apartments and pin the shops - it is primarily apartments. If it is some outdoor pavilion for seating to eat food, building=roof might be good, and small tiny eating areas might even be a picnic shelter. For dedicated outdoor seating of a restaurant, I am unsure how to tag a structure it might have. A shop/stall/booth/space/unit/location/suite in a larger building is not a mappable building (if it is indoors), a pin suffices. Outdoor stalls made of temporary materials (but left in place permanently) are mappable, but I don't know what as. If it is purpose-built little stalls in a row that never move and are at least permanently present, building=retiail on the row and pins for the individual shops. Motorway buildings are usually one large building with many pins for different shops and amenities. I forget if there is a unique building type for motorway services, but I would still probably go with =retail for a large SA on the tollway - it is 95% souvenir shops and fast food. Javbw > On Sep 23, 2018, at 9:11 PM, Tobias Zwick wrote: > > Hey there > > Do you have suggestions what would be the appropriate building value for > a building constructed for gastronomic purposes only, such as a > restaurant/café/fast food/food courts etc? > > In context of Europe, I am thinking of: > - inns/taverns (eating only) (de: "Gasthof"), for example in forests, > national parks or other touristic areas, or that typical one inn in a > village > - the fast food place around the corner (de: "Imbiss") > - restaurants and stalls at rest stops > - motorway restaurants, food courts > - staple food buildings (McDonalds etc) > > Tobias > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - assembly_point:purpose
Thanks - I added a small note about the tsunami elevation in the examples. Javbw > On Sep 23, 2018, at 9:14 PM, Daniele Santini wrote: > > Ok, I updated the existing proposal ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Topographic Prominence for Peaks
Hi Joseph, Am 23.09.18 um 02:00 schrieb Joseph Eisenberg: > Elevation and prominence can both be calculated from SRTM data, eg by > using Opentopomap tiles and finding the highest contour lines around a > peak, and the lowest near a saddle. > > Prominence and elevation can be calculated by computer with good data, > but for my part of the world the SRTM data is not high enough quality > to get good results without cross-checking against aerial imagery. > Also the calculations are not simple, and are not precise for sharply > pointed peaks or deeply carved saddles, therefore I believe it will be > useful to include this data directly in tags. > > I also find that calculation the prominence of peaks has encouraged me > to add more ridge lines and saddle points (with elevations), which > should make the database more useful in mountainous areas. > > Do you think I should write up a formal proposal for this tag? I don't think that there is any need for such a tag in OSM for the following reasons: (1) If you assume the earth to be a plane, just order the peaks by their elevation. It's so simple that I don't give the necessary SQL query here. If we used a prominence=* key, it would have to be the distance to the next higher peak. If the value were not a number but a term like "most_important", "very_important", "neighbour_of_highest" etc. it would not comply with the verifiability requirement of OSM and invite people to have edit wars. (2) If you assume the earth to be an ellipsoid, it is more difficult but still achievable with ele=* tags in OSM and elevation raster data (SRTM etc.) only. There is an open source solution to do so. https://gitlab.com/nuntius35/extremal_peaks/blob/master/README.md (mentioned in WeeklyOSM issue 423) (3) If we use a tag like prominence=* for peaks two mappers will have a different opinion on the value to choose. For example, the Matterhorn is 4478 m high but Monte Rosa is 4634 m high and not that far away. However, the Matterhorn is more famous and people expect it to appear on maps at the same or lower zoom scales than Monte Rosa. Whose opinion is correct? From my point of view, the mapper using the elevation only because that is the only verifiable fact while the prominence in advertisement is something we don't record in OSM for a very good reason. (Please replace "peak" by "city" and "height" by "population" and read this paragraph again) Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] JOSM error for a bus lane conditional
Looks fine to me. Perhaps open an issue in the JOSM bugtracker? On 23/09/2018 07:43, Warin wrote: > Hi, > > > There is a past entry of > > lanes:bus:conditional=1 @ (Mo-Fr 06:00-10:00,15:00-19:00) > > > That JOSM says is incorrect. There is a declared 2 lanes there on the way. > > What is wrong with that tagging? One lane for buses between 6 to 10 and > 15 to 19 hundred hours. > > > > ___ > 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] maxspeed:type vs source:maxspeed // StreetComplete
Oh, I think you found an error in the default speed limits document. I will go through the table from A to Z within the next few days or even today to correct this at places where the gross vehicle weight is meant instead of the actual weight. I guess then maxspeed:conditional=xx @ (weight > yy) would be actual weight (de: "Gewicht") and maxspeed:conditional=xx @ (maxweight > yy) would be max gross weight (de: "zulässiges Gesamtgewicht")? The latter is not documented in the wiki. I would add it to the conditional-documentation if everyone here thinks that "maxweight" is the best conditional name to denote "max gross weight". Tobias On 22/09/2018 23:52, Martin Koppenhoefer wrote: > > > sent from a phone > >> On 22. Sep 2018, at 23:48, Tobias Zwick wrote: >> >> What do you mean, what is the difference? >> >> maxspeed:conditional=xx @ (weight > yy) would be the former or the latter? > > > in German: zulässiges Gesamtgewicht vs. Gewicht > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - assembly_point:purpose
Ok, I updated the existing proposal (the link is the same, https://wiki.openstreetmap.org/wiki/Proposed_features/assembly_point:purpose ) moving from assembly_point:purpose= to assembly_point:=* . Cheers, Daniele Message: 1 > Date: Sun, 23 Sep 2018 06:05:59 +0900 > From: John Willis > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature proposal - RFC - assembly_point:purpose > Message-ID: <39497331-d154-430f-85df-f4713c678...@mac.com> > Content-Type: text/plain; charset=us-ascii > > > > > On Sep 22, 2018, at 11:03 PM, Daniele Santini > wrote: > > > > edit the proposal substituting the old tag and values with the new tags > or create a new proposal with the new tags? > > If you feel the original proposal (or the discussion around it) is > valuable, start a new one. If it is of minor or no importance, just rewrite > the existing page. You can note "originally started as > assembly_point:purpose=tsunami, etc., " > > Under "rationale", you can use it as an example where assigning a single > value is not flexible enough to accurately tag the multi-use nature of most > assembly_points. > > This will also document the originally proposed tag's role in refining the > currently proposed one, and show up in OSM searches without leading to a > dead proposal page. > > Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] How to tag a building constructed for a gastronomic purposes?
Hey there Do you have suggestions what would be the appropriate building value for a building constructed for gastronomic purposes only, such as a restaurant/café/fast food/food courts etc? In context of Europe, I am thinking of: - inns/taverns (eating only) (de: "Gasthof"), for example in forests, national parks or other touristic areas, or that typical one inn in a village - the fast food place around the corner (de: "Imbiss") - restaurants and stalls at rest stops - motorway restaurants, food courts - staple food buildings (McDonalds etc) Tobias ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
