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

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] 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

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

[Tagging] Tagging shared campuses: landuse=school?

(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: >

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 >

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 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 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] 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

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

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 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

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

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

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

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

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

Re: [Tagging] Tagging for emojis names

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. Jeroen Hoek _

Re: [Tagging] Tagging for emojis names

ed 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] Confusion bicycle_road <> cyclestreet

lities * 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 cyclestreet=ye

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

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

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 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

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] 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

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

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

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

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] 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

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

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

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

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

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

ing 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

[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

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

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

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

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: