Re: [Tagging] Confusion bicycle_road <> cyclestreet

ilities * Penalize them in car routing engines It is analogous to highway=cycleway: you can easily use highway=service and add a bunch of tags making it a cycleway in terms of access rights, but a cycleway implies much more than that (like safety and suitability). The cyclestre

Re: [Tagging] "width" on streets: Time for a recommendation

he way-line. It would make aligning these to the middle of the street even easier, and tagging the width less error prone too due to the visual feedback. Jeroen Hoek ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Linking Sidewalks to Highways

On 22-09-2020 00:17, Clifford Snow wrote: > It's the type of connection, going from sidewalk or dedicated bike path, > to road where I've felt we need a highway=footway_link/cyclway_link or > maybe footway_connector/cycleway_connector, to connect separated > sidewalks/cycleways to the street in ins

Re: [Tagging] Linking Sidewalks to Highways

On 22-09-2020 12:30, Peter Elderson wrote: > Jeroen Hoek mailto:m...@jeroenhoek.nl>>: > > I have been applying highway=cycleway + cycleway=link as well to see how > this feels. Some early documentation I have been preparing: > > https://wiki.openstreetmap.

Re: [Tagging] Linking Sidewalks to Highways

On 21-09-2020 12:02, Supaplex wrote: > The main categories of the highway, "name" and its classification like > "primary/secondary", can be assigned to the separate way with Keys like > "sidepath:of" or "sidepath:of:name". Other values like "lit" should > anyway be tagged directly on the separate w

Re: [Tagging] Linking Sidewalks to Highways

On 22-09-2020 23:37, Martin Koppenhoefer wrote: > renderers have all the necessary information to omit name for > footway=sidewalk. It is just a question of the style Granted, for footway=sidewalk renderers could omit the name. The sidepath:of:name approach has the benefit of more explicitly de

Re: [Tagging] Feature Proposal - RFC - parking=street_side

ce of parking areas that really are parking=surface|layby|etc. Kind regards, Jeroen Hoek Co-author of this proposal ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - parking=street_side

On 24-10-2020 15:58, Paul Allen wrote: > What you haven't convinced me of is that it isn't amenity=parking. > By any rational definition it is.  I know of off-carriageway parking > which is controlled by a county council and has a ticket > machine.  The county council lists it as a car park, one >

Re: [Tagging] Feature Proposal - RFC - parking=street_side

On 24-10-2020 15:58, Paul Allen wrote: > I don't see any valid reason for wanting to de-emphasize them and you > do not attempt to provide one. Maybe there is a valid reason but I > don't see it. Thanks for the feedback; we'll clarify that point. From the proposal: > Furthermore, this type of pa

Re: [Tagging] Feature Proposal - RFC - parking=street_side

On 24-10-2020 16:22, Janko Mihelić wrote: > These two variants are mapping for the renderer, and both add false > data. The first one extends the parking over half the road. The second > creates a service road area over half the road. There is no service road > area there, you are just trying to co

Re: [Tagging] Feature Proposal - RFC - parking=street_side

On 24-10-2020 23:54, Paul Allen wrote: > So tagging for the renderer because, in your opinion, these car parking > areas are unimportant. By that line of reasoning tagging highways anything other than highway=motorway is tagging for the renderer. I understand your concern, but no, it is not our o

Re: [Tagging] Feature Proposal - RFC - parking=street_side

On 24-10-2020 22:27, Allroads wrote:> Use area:highway for polygon and parking! I will clarify the relation of our proposal to area:highway, thanks for pointing it out. In brief, the two tagging methods coexist and complement each other. Our proposal focuses on the parking-amenity (and thus ameni

Re: [Tagging] Proposal for admission=* tag

On 25-10-2020 14:55, Janko Mihelić wrote: > Relations are definitely safer, but I wanted to add a unique name > version for new editors that are intimidated by relations. > Also for cases when you would have a lot of admission issuers, so we > don't get some humongous relations. Maybe there's a ven

Re: [Tagging] Proposal for admission=* tag

On 26-10-2020 13:44, Janko Mihelić wrote: > Although, now that I think of it, you can add the whole theme park > to the relation, and add role "admission", that doesn't hurt. I would use a separate role for the poi (point-of-interest) itself, so data consumers know what the subject of the relation

Re: [Tagging] Feature Proposal - RFC - parking=street_side

On 26-10-2020 19:31, Matthew Woehlke wrote: > Alternatively, clients might look at the sort of highway running > through a parking area. A highway=tertiary is probably "street-side > parking", while a highway=service, service=parking_aisle probably is > not. That's not a bad thought, but it would

Re: [Tagging] Proposal for admission=* tag

On 26-10-2020 17:52, Janko Mihelić wrote: > I have a feeling the poi role is a bit vague. I would keep it optional, > with only admission and issue being required for the admission relation > to work. Wouldn't issue be optional as well if any admission:issue:* tags are used? For example, the roami

Re: [Tagging] Feature Proposal - RFC - parking=street_side

On 26-10-2020 21:24, Matthew Woehlke wrote: > If parking is on both sides of the street, the parking area already > crosses the street, and even if it doesn't, logically the parking area > *does* connect to the street. I disagree with the argument that mapping > thus is somehow "wrong", and indee

Re: [Tagging] Feature Proposal - RFC - parking=street_side

On 27-10-2020 09:30, Martin Koppenhoefer wrote: > because in OpenStreetMap everything is “valid”, but both approaches > are not equally good. In this specific case, as soon as > landuse=highway is mapped as an area, having connected the adjacent > landuses to the middle of the street will become ut

Re: [Tagging] Feature Proposal - Voting - parking=street_side​

On 15-11-2020 11:11, Alan Mackie wrote: > Never mind. I've just reread it and it seems I need more coffee. No worries. Enjoy your coffee. :) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature proposal - Vote result - parking=street_side (approved)

Good morning! The voting for the parking=street_side feature proposal drafted by Supaplex030 and myself has run its course. The proposal was approved with 23 votes for and 2 against; there were no abstentions: https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side In the com

Re: [Tagging] Use of crossing:island where crossings and islands are mapped separately

Where there is a crossing with traffic islands, but the highways forming the crossings and crossing the islands are mapped separately, my assumption has been that crossing:island=no is the correct tagging. I agree. My understanding is that you can provide information about pedestrian refuges at

Re: [Tagging] shop=pets/pet=*, are we missing a wiki page?

On 11-03-2023 08:34, Kai Michael Poppe wrote: while mapping a shop for dog supplies (shop=pets), I checked the wiki if the combination with pet=* would be accepted. Behold, Tag:shop=pets shows "Tags used in combination" to include pet=*, yet Key:pet only is a disambiguation page for shop=pet and

Re: [Tagging] shop=pets/pet=*, are we missing a wiki page?

On 12-03-2023 09:27, Kai Michael Poppe wrote: I will be getting on with documenting the most common values when I get back home. I've taken the liberty to reword and clarify Key:pet, Key:pets, and Key:pets_allowed a bit, feel free to improve. I've also opened the Talk-page for Key:pet: htt

Re: [Tagging] Tagging for emojis names

corresponding country. Of course the proposal should reflect on how to ensure the correct Regional Indicator Symbol pairs are added. One way to do this, is by using the exsiting ISO3166-1:alpha2 and flag keys, and verify that the flag rendered via Regional Indicator Symbols matches the flag-value.

Re: [Tagging] Tagging for emojis names

e:Zsye will be updated before at least half of the other name-tags is. Jeroen Hoek ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

This update has the unfortunate side-effect of breaking the rendering of over 1 hedges in the Netherlands. We have been very fortunate to have access to highly detailed mapping sources via our government, including both satellite images and tile-services for street-level features, including hed

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

On 05-02-2020 15:46, Christoph Hormann wrote: > the semantic ambiguity of the > 350k cases where barrier tags are currently > used as a secondary tag on > landuse/leisure/etc. polygons to incidate the polygon is enclosed by a > linear barrier. The PR specifically removes the filled rendering fr

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

On 05-02-2020 16:10, Paul Allen wrote: > 4) Where the only tags are barrier=hedge + area=yes then render > as before, a hedge that has area. There are some additional tags that should be allowed for. Including (mainly?) `height=*`. > 5) Introduce, and render, landcover=hedge so we can tag an ob

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

On 05-02-20 20:17, Christoph Hormann wrote: > But that is not in any way sustainable and it would be highly > confusing for mappers because the conditions resulting in this > rendering would be unique and could not be derived from any general > principles. I understand the reasoning, but what m

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

On 06-02-20 05:22, Marc Gemis wrote: > My interpretation is the same as Paul's. Including the not thought > through part, as I never needed that. Mine too. There is only a subset of barrier-tags where `area=yes` makes sense, like hedge and (city-)wall. ___

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

On 07-02-20 17:58, Martin Koppenhoefer wrote:> interestingly, for paths and roads there is also an area=yes variant > (which is likely more common than the newer "area:highway" tag, which > has different semantics). To be precise: `area=yes` on a `highway=*` means that the whole area is routable,

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

On 06-02-20 13:29, Peter Elderson wrote: > Joseph Eisenberg >: > > The Netherlands has been claimed as a place where barrier=hedge areas > are used properly and are necessary. I have already downloaded one > whole provicne, Zeeland, which has quite

Re: [Tagging] Tagging small areas of bushes, flowers, non-woody perennials, succulents, etc

On 09-02-20 03:33, Joseph Eisenberg wrote: > In the discussion about `barrier=hedge` areas, it is clear that > mappers want a way to tag small areas of bushes and shrubs, and not > everyone is happy about using natural=scrub for this case. > > Currently there is a tag landuse=grass for small areas

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

On 09-02-20 12:36, Peter Elderson wrote: > For the record, I am not opposed to renderers, data users or toolmakers > reporting a problem or an improvement request and asking the taggers > list to come up with a solution everyone can live with. Information in > the database should be renderable and

[Tagging] Tagging shared campuses: landuse=school?

ringly wrong? I'll write up the proposal (subsuming the current landuse=school proposal) and documentation if there is enough support for this. Kind regards, Jeroen Hoek ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging shared campuses: landuse=school?

On 04-04-19 11:25, Mateusz Konieczny wrote: > > Apr 4, 2019, 9:55 AM by m...@jeroenhoek.nl: > > Then, landuse=school (~5000 in use) > > Note that about 80% of landuse=school was added by automatic edits: > https://user-images.githubusercontent.com/5439713/47250831-3d2e6b00-d429-11e8-9aef-1ba

Re: [Tagging] Tagging shared campuses: landuse=school?

On 04-04-19 13:51, Martin Koppenhoefer wrote: > why not overlap the amenity=school (one for each school, including the > grounds)? This allows to show that it is a common campus, while > otherwise you only associate the buildings with the school and make no > statement about the campus, other than

Re: [Tagging] Tagging shared campuses: landuse=school?

On 04-04-19 15:55, Martin Koppenhoefer wrote: > for the shared name of several schools I would suggest the group > relation. Just add the schools as members and add the shared name to > the relation. Wouldn't that leave only the collective schools' relation with a searchable name, rather than a

Re: [Tagging] Tagging shared campuses: landuse=school?

On 04-04-19 15:41, Florian Lohoff wrote: > Schools have forever been landuse=residential as schools belong to > residential areas. This is not always the case, especially in cases where schools share a common campus. > Introducing yet another special landuse is just more confusing and it > does

Re: [Tagging] Tagging shared campuses: landuse=school?

On 05-04-19 23:10, Markus wrote: > There is a minor thing, but i think that the landuse=* value should > rather be educational (adjective) instead of education (noun). This > makes more sense and fits better to other landuse=* values like > residential, industrial or commercial. I strongly agree.

Re: [Tagging] The endless debate about "landcover" as a top-level tag

JOSM developers to incorporate new presets it probably won't progress beyond a permanent 'proposed' status. Kind regards, Jeroen Hoek ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The endless debate about "landcover" as a top-level tag

On 06-06-18 16:13, Mateusz Konieczny wrote: For start - is there a well written proposal? Is there a JOSM preset that people can manually enable? Is there a well written issue proposing support in JOSM, iD, Vespucci (if already Good points. Perhaps I'll give it a go to write a concept for

Re: [Tagging] The endless debate about "landcover" as a top-level tag

own private arcana to understand — I fear that would create a gap between occasional new mappers contributing through ID, and experienced mappers who can map major infrastructural projects without breaking a single bus route, but nothing in between. Semantics matt

Re: [Tagging] Tools and mass-retagging

On 08-06-18 13:37, Leo Gaspard wrote: * for all objects with natural=wood, add landcover=trees * for all objects with landuse=forest, add landcover=trees Why not consider documenting that natural=wood and landuse=forest imply landcover=trees instead? It seems like a sensible default (simil