Re: [Tagging] Additional detail of Levee mapping via embankments
Sorry, I am continuing to have trouble properly replying to the tagging group, it keeps defaulting to the individual. > On Nov 13, 2019, at 4:48 PM, Joseph Eisenberg > wrote: > > For a levee it can just go around the whole levee If I understand your suggestion correctly, this is impossible. The only place one can “go around” is the finger of a levee that has ended where two rivers merge - but that is a lie too - the inside goes up the small river, and the outer folds and goes back upriver with it as well. There are very few places where inner becomes outer - because the point of the levee is to protect the outer from the inner. There are very few levees that end on the upstream side without going into terrain - still no option for the embankment to loop around. The levee starts in my town (sprouts out of a hill) and continues for 50KM. The river it meets goes for another 100km with full levee protection. They are giant structures. At no point does inner get a chance to become outer. Every stream, tributary, and minor river has levees here. Some merge with “no” flow control. Others merge via culverts with underground sluicegates, others merge via gigantic sluice gates the size of an office building. But the gates still give no chance for inner to become outer. the flood basins I use have extensive weirs and 1Km emergency spillways in the levees - still no place for them to u-turn. Having it “go around” is not really an option. Javbw.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] disguised communication towers
On Wed, Nov 13, 2019 at 01:28:04PM -0800, Eric Theise wrote: > On Wed, Nov 13, 2019 at 1:17 PM ael wrote: > > > On Wed, Nov 13, 2019 at 01:00:29PM -0800, Eric Theise wrote: > > > tower:type=communication > > > tower:construction=concealed > > > > > Not really. I mapped such a tower a few years ago, but would not have > > thought of adding tower:construction=concealed . I suspect that > > scheme did not exist back then. Perhaps I might add it sometime and use > > it in future now that I am aware of it. > > > > Do you recall how you tagged the camouflage of the tower you did map? I didn't. Just tower:type=communication. It wasn't that well concealed - the sort that looked like a slightly strange pine tree. el ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] disguised communication towers
sent from a phone > On 13. Nov 2019, at 22:02, Eric Theise wrote: > > From my morning reading it seems that entities tagged with > > tower:type=communication > tower:construction=concealed > > and either man_made=mast or man_made=tower should cough up cellphone towers > masquerading as cacti, palms, pines, flagpoles, and such. tower:construction seems a tag that describes different orthogonal properties according to the mostly used values. Some describe a structural system (eg. lattice, guyed lattice, tube), others a shape (e.g. dish, dome), others a structural property (freestanding), others a material (stone, steel, metal, concrete). It’s a complete mess, and concealed fits nicely by adding yet another different kind of property to it ;-) Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] disguised communication towers
On Wed, Nov 13, 2019 at 1:17 PM ael wrote: > On Wed, Nov 13, 2019 at 01:00:29PM -0800, Eric Theise wrote: > > tower:type=communication > > tower:construction=concealed > > > > and either man_made=mast or man_made=tower should cough up cellphone > towers > > masquerading as cacti, palms, pines, flagpoles, and such. But apart from > a > > note="pine tree" that jumped out at me I'm not finding much. I have to > > assume I'm barking up the wrong tree (sorry). > > > > Could any of you suggest a better search strategy? > > Not really. I mapped such a tower a few years ago, but would not have > thought of adding tower:construction=concealed . I suspect that > scheme did not exist back then. Perhaps I might add it sometime and use > it in future now that I am aware of it. > I bumped into it at https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtower. It isn't even on the mast page. Do you recall how you tagged the camouflage of the tower you did map? Thanks, Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] disguised communication towers
On Wed, Nov 13, 2019 at 01:00:29PM -0800, Eric Theise wrote: > tower:type=communication > tower:construction=concealed > > and either man_made=mast or man_made=tower should cough up cellphone towers > masquerading as cacti, palms, pines, flagpoles, and such. But apart from a > note="pine tree" that jumped out at me I'm not finding much. I have to > assume I'm barking up the wrong tree (sorry). > > Could any of you suggest a better search strategy? Not really. I mapped such a tower a few years ago, but would not have thought of adding tower:construction=concealed . I suspect that scheme did not exist back then. Perhaps I might add it sometime and use it in future now that I am aware of it. Your lack of results might just be because I am not the only one who had not come across this tag before: I suspect that it is rather recent. ael ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] disguised communication towers
Hi everyone, >From my morning reading it seems that entities tagged with tower:type=communication tower:construction=concealed and either man_made=mast or man_made=tower should cough up cellphone towers masquerading as cacti, palms, pines, flagpoles, and such. But apart from a note="pine tree" that jumped out at me I'm not finding much. I have to assume I'm barking up the wrong tree (sorry). Could any of you suggest a better search strategy? Thanks in advance. Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging
Am Di., 12. Nov. 2019 um 14:15 Uhr schrieb Paul Allen : > from the description, light meals aren’t a hard requirement, or it could >> be seen as satisfied by selling cakes (or ice cream cups in the case of >> cuisine =ice_cream): >> > > I suspect that, over the years, people have forced things into cafe > because it came closest > to what they wanted without having to create a new value and then somebody > later documented > it. Or people bring different cultural assumptions to the term "cafe." > its both, people bring different cultural assumptions for the term "cafe" and hence have amended the page, likely the Germans ;-) In Italy, a very common place to go for breakfast is called "bar". Italian bars often do not provide seating, you will eat your cornetto / croissant standing in front of an espresso and leave within a few minutes. They might change during the day (offer simple lunch, and some may be open at night and serve alcohol and aperitifs, others won't and will close). It is also common that they sell tobacco and lotto / scratch cards, public transport tickets and allow for payments (electricity and water bills, etc.). Personally I tag them as "bar" if they do not provide table service (and usually only have few tables if any) and as cafe if there is table service (and usually more things to eat). IMHO a cafe is a place to stay, a bar (at least the italian ones) is a place to drink a coffee and then go away. As there are already significant differences between bars, pubs, cafes within Europe, imagine how the situation will be globally. > > Question. You've had a busy day. No time to eat breakfast or lunch. > You're hungry. You're > in a strange town. You're looking for somewhere to eat. You look at the > map for cafes. > Would you be happy if you went to one and it sold only ice cream or only > cake? > I definitely would not look for a cafe if I would be looking for something to eat fast. Maybe I would in the UK, now that I've read your comments ;-) > > Questions. We already have tags that can distinguish between a shop > selling ice cream > to take out and a place with tables and seats where you buy ice cream to > eat inside > (possibly with a takeaway option). What purpose does it serve to collapse > these into > a single tag? What purpose does it serve to replace one of them with a > cafe? > I am not sure what you would want to replace, but I am often adding amenity=ice_cream and shop=ice_cream to be sure. Cafe and cuisine is what I would use for places like the one I have posted the link above, and it is among the mostly used tags for ice cream according to taginfo, much more than shop. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Pedestrian lane
Il giorno mar 12 nov 2019 alle ore 23:54 Nick Bolten ha scritto: > You make a very good point! A road can have a pedestrian lane, shoulder, > both, or neither, so it wouldn't make any sense for a pedestrian lane to be > a type of shoulder. The widths do vary quite a bit as well, regionally. > > > You mean a situation like this?: > > > https://wiki.openstreetmap.org/wiki/File:Sidewalk_and_crossing.svg > > One very similar to that, yes! I think I normally wouldn't add > sidewalk=both to any length of the highway=residential. Is that a typical > thing to do? I would assume that meant the highway=residential street had > its own short piece of sidewalk, when it actually doesn't. > > The challenge I'm describing is in reliably associating the crosswalk with > the pedestrian paths. After all, the crosswalk is a node on a different > street way. I know that I could do it 99.x% of the time, but it will > require using some graph traversal approaches that most people aren't > familiar with. Plus, those cases where I couldn't reliably determine it > could be very important. I suspect this is one of the reasons I haven't > found anyone using these data in concert (sidewalk=both + highway=crossing) > to do pedestrian routing. > > Mapping for a router isn't the end-all-be-all of this kind of data, of > course, but it is one thing that would be hard to do with this tagging > schema. I'd be interested to know if there are other data consumer plans > for the data, since use does dictate what the schema looks like. Making > streets be ways was a conscious choice informed by routing, for example! > I didn't know that representing streets as lines was a choice made to support routing Interesting This made routing for cyclists, pedestrians and impaired people more difficult And I hope everyone can see why that's disappointing Choosing a representation always has political effects In this regard, I find this talk quite on point http://opentranscripts.org/transcript/programming-forgetting-new-hacker-ethic/ > > I would simply connect the sidewalk way with the road where the > sidewalk ends (and map a barrier=kerb + kerb=* node) and add > pedestrian_lane=* to the road starting from where the pedestrian lane > begins. > > So there would be a segment of footway=sidewalk that is not actually on a > sidewalk? I've been unsure about what to do in similar situations, like how > to connect footways to roads without implying there's literally a footway > on top of the road. Probably worth its own, separate discussion (it was > discussed previously, but without conclusion), so I won't elaborate. > > > There is a pedestrian lane along the the south-eastern part of the road > Reichenbachstrasse. On the opposite side there are public steps as well as > many (currently unmapped) driveways and private footpaths. Mapping the > pedestrian lane as a separate way would either make it disconnected from > the steps, driveways and footpaths on the opposite side of the road or you > would need to add many highway=footway connections from the pedestrian lane > to the steps, driveways and footpaths, which would make the map very > confusing. > > > Therefore i strongly advise against mapping pedestrian lanes as separate > ways. > > > By the way, the same problem occurs with sidewalks mapped as separate > ways. > > Yes, it's a trade-off: the actual pedestrian path's primary connections > and attributes vs. its association with the street. Neither are actually > perfect options, which is why I'm suggesting the possibility of redundant > tagging. Ideally, we'd come up with a universal strategy for relating these > ways together, but I don't want to monopolize this proposal! > > > I'm not a programmer and therefore don't have concrete plans to use this > data, but i imagine (and hope) that pedestrian routers could use this data > to prioritise roads with pedestrian lanes and to tell blind people on which > side of the road they should walk. > > Maybe it would be helpful to set up a meeting with some organizations that > serve the visually impaired along with programmers that build routing > software. We (Taskar Center) might be able to help with that sort of > meeting, and it would be even better to have organizations from different > cultures and geographies involved as well. As-is, I think the challenge of > reliably associating paths with crosswalks is a big one for mapping for > routing for the blind. > > There are 2 talks given at the last osm2019 that I think are on par with what you are thinking You might want to get in touch with their authors This is the first one: Pedestrian Routing The author argues like effective pedestrian routing in which the author argues how a previous focusing on routing for cars has made pedestrian routing more difficult (and he presents a quite complicated algorithm for extracting information useful for pedestrian routing) https://media.ccc.de/v/sotm2019-1265-routing-for-humans The second one is this one:
Re: [Tagging] Feature Proposal - RFC - Small electric vehicles
On 11.11.19 09:41, Martin Koppenhoefer wrote: if the vehicle class is treated exactly like another one (e.g. pedelec like a bicycle), I agree there is no need to add an extra key for it, on the contrary you should not do it (don't tag your local legislation). If there are differences, we should have a key for every class that makes a difference (this is how we usually do it with access-tags). Hi, I added a section "When NOT to use" - I hope this addresses your concerns about redundant tagging. https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters#Where_to_use ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Additional detail of Levee mapping via embankments
(I mis-sent this email) > On Nov 13, 2019, at 3:44 AM, Richard wrote: > > We need new tags for the bottom of embankmets, top of cuttings, bottom of > cliffs, earth_banks > and maybe a few others if we want to map them. that is very true. I think we can cleanly do this with the ways you mentioned. We need to chose a scheme for these “base” tags that doesn’t reinvent the wheel, isn’t vague, and can easily be interpreted. my mis-reading of embankment led to some big problems, simply because I assumed the tag could document things it couldn’t. Your tags look really good to me. > On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer > wrote: > A relation seems easier to evaluate and explicit, while a spatial query > heuristic will inevitably fail in some cases I think there is a need for a basic relation, if I understand Martin correctly, to simply associate the two lines, (for example, an =embankment and an =embankment_base pair). When mapped, they are not joined. They are merely adjacent. I am not sure of what “type” of relation to choose in iD, but I assume someone will tell us which type to use. When mapping a simple cutting or embankment, you would have only one “base” line adjacent - so there is little ambiguity, and the relationship can be inferred (IIUC), but in complicated tagging, there could easily be a situation where which base belongs to which line is unclear, and lead to problems. Simply putting them into a relation says “these members are related” and the renderer can know for certain that these two ways that don’t share nodes are a pair, no inference needed. This again raises the question of levees - is the levee worthy of it’s own levee relation? do you put all 4 embankment lines into relation with the man_made=dyke line? this seems to be the only solution to: - properly group the embankments with the levee - not have to use super=relations (putting the embankment relations into a levee relation) - providing the most flexibility to weird situations - allowing for the extent of the top of the levee to be defined (large levees have varying width tops with usable areas, as shown, in which a “way” is insufficient ). But I am unsure that this is the “only way” and perhaps putting the two embankment relations + dyke line into a levee super-relation would allow mapping of the embankments to be a uniform process (making mapping the details of levees a bit more complicated at the expense of standardized embankment mapping). Javbw___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
