Re: [Tagging] building:levels and flat roofs

On 03.10.23 at 07:24, contrapunctus wrote via Tagging: 1. What value should be given to building:levels=*? 2. Should roof:levels=* be used? If so, how? [...] [1] https://wiki.openstreetmap.org/wiki/File:Multi-level_building_with_flat_roof_in_Adarsh_Nagar,_Delhi,_India.jpeg This building

Re: [Tagging] Tagging proposal On Wheels app 3 - Parking spaces for wheelchair users

On 14.05.23 at 19:59 Yves wrote: everybody is not super accurate in drawing polygons, imagery has a resolution and I doubt a lot of mappers go trough a complete parking lot a measuring tape in their hands. Sure, mappers drawing polygons very rarely use measuring tape. The same is true for

Re: [Tagging] Tagging proposal On Wheels app 3 - Parking spaces for wheelchair users

On 13.05.23 at 18:28 Marc_marc wrote: why not just add this information as amenity=parking_space geometry ? Indeed, amenity=parking_space is usually mapped as a polygon (over 94% of amenity=parking_space tags are on ways, according to Taginfo). This makes it possible to determine the

Re: [Tagging] Door tag

On 03.12.22 at 02:46 Kyle Hensel wrote: Can we change the wiki so that it says “*/An/* entrance tag” instead of “*/The/* entrance=* tag”? It's also ok to use door=* without any additional entrance tag. This is used with Simple Indoor Tagging, as indoor=door isn't actually part of SIT.

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

On 02.12.22 15:02 Mateusz Konieczny wrote: Or is it justifiable because it is outright impossible to do reliably with automatic preprocessing? I would say that's the reason. Of course, it's hard to prove that something is impossible. But so far no one has built a working solution for

Re: [Tagging] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

On 29.10.22 07:13 easbar.m...@posteo.net wrote: I like your idea of not using the except tag but rather something like restriction:value=unrestricted. Actually that would be the first useful combination of restriction and restriction:vehicle that I have heard of. But unfortunately this is

Re: [Tagging] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

On 28.10.22 22:06 easbar.m...@posteo.net wrote: Quite obviously this isn't ideal and as far as I can tell this is the exact reason we have the two approaches (one for excluding vehicles and another for including them). Historically, I'd say the reason we have two approaches is that the

Re: [Tagging] Tagging standards [moved from osmf-talk]

On 23.10.22 21:26 Brian M. Sperlongano wrote: In my mind, the one thing that has been sorely lacking from this discussion is a clear articulation of the problem we are trying to solve here, from both a data producer (mapper) and data consumer (renderer etc) perspective. Standardization is

Re: [Tagging] Lyft and nameless sectioning in OSM

On 11.10.22 21:51 Mateusz Konieczny wrote: Oct 11, 2022, 21:42 by m...@evancarroll.com: I just don't see the value even if everything was done right. That is simply utterly irrelevant. I disagree. People may not always agree about the relative usefulness of some types of data, but

Re: [Tagging] incline=up_and_down

On 26.09.22 02:21 Mateusz Konieczny wrote: But what can be done in cases where there is no real incline but path goes through series of up and down hops? I would intuitively prefer if you put the information about the presence of "hops" into a specialized tag instead of making the value space

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

On 17.09.20 02:35, Taskar Center wrote: > This is yet another example why "sticking" the sidewalks onto the > highway (as a tag) rather than mapping them as separate ways is > appearing to be less and less practical. Please see our sidewalk schema > proposal >

Re: [Tagging] Addition of highway=emergency_bay and priority_road=yes to Map Features?

On 16.09.20 09:57, Martin Koppenhoefer wrote: > emergency bays are quite common in Italy and Germany when there isn’t an > emergency lane. The pertinent question isn't so much if emergency bays are common, but if this particular tagging for them is established. In my opinion, mapping what

Re: [Tagging] How to tag body height limits on attractions?

On 10.09.20 15:07, Mateusz Konieczny via Tagging wrote: > 3 is clearly out, 5 seems overly complex I agree with both of these statements. As this is not specific to attractions (might also apply to aerialways, for example), I would also avoid option 2. Because I feel there's a slight difference

Re: [Tagging] Status of proposed roof:ridge / roof:edge ?

On 31.08.20 20:06, Oliver Simmons wrote: > Does anyone know if this tagging: > https://wiki.openstreetmap.org/wiki/ProposedRoofLines > > Is accepted and ok to use? > > It has “proposed” in the title but there’s none of the usual proposal > stuff saying if it was accepted or not. It never went

Re: [Tagging] Feature Proposal - RFC - more parking types

On 07.08.20 15:36, Matthew Woehlke wrote: > That said... now I'm on the fence. FWIW, the amenity=parking page > mentions parking_space=disabled as being supported by at least one > renderer, while one has to do quite some digging for how to use > access:*. Clearly we *do* need to improve the

Re: [Tagging] Feature Proposal - RFC - more parking types

On 06.08.20 22:52, Matthew Woehlke wrote: > https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking I like it, thanks for working on this topic! Two suggestions: Could you add a short definition of "compact"? I can guess that it's supposed to mean parking spaces for compact cars, but

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

Hi Tobias, congratulations on your successful microgrant proposal! :) Maintenance of existing data is a growing concern as OSM matures, so it's important that we explore workflows for it. On 23.07.20 18:06, Tobias Zwick wrote: > 2. Always record check_date or avoid tagging it where not

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

On 24.07.20 14:13, Peter Elderson wrote: > In comparable cases (non-OSM, but comparible checking schemes), I do not > record the date it has been checked, I record the future date when it > should be checked (again). When it should be checked is opinion-based, though. The date when you last

Re: [Tagging] Automated edit of image tags suggestion

On 27.06.20 11:18, Mateusz Konieczny via Tagging wrote: > unlike other many image gathering sites, images there are > likely to be reusable and with at least basic info being > machine readable None of this changes if the Commons image is linked from the image tag, though. And in fact, I feel

Re: [Tagging] Automated edit of image tags suggestion

On 25.06.20 19:57, pangoSE wrote: > I recently started discussing the problems related to urls and > File:filename.* that links to wikimedia_commons using the tag. See > Talk:Key:image#Discourage_linking_to_commons_files_and_migrate_all_File:filename..2A_values_and_direct_urls_to_wikimedia_commons

Re: [Tagging] Name for new wiki pages about roles of members in route relations?

On 25.06.20 19:46, Joseph Eisenberg wrote: > Should individual pages for these roles be located at something like > Role:main and Role:alternative? So far, I believe roles are typically documented on the wiki page for the relation type, rather than their own pages. I don't think there's an

Re: [Tagging] site relation definition

On 17.06.20 12:27, Martin Koppenhoefer wrote: > Can we remove the "man_made" requirement? I'm ok with removing the requirement for objects to be man-made. I only added this aspect back in because it had been silently lost during the transition from the proposal page to the Relation:site page a

Re: [Tagging] Points vs Polygons

On 19.04.20 20:33, Paul Allen wrote: > On Sun, 19 Apr 2020 at 19:29, Justin Tracey > wrote: > > Another major exceptions where mapping as an internal node is > better, IME, are notable (historical) buildings that currently house > a business. More

Re: [Tagging] Points vs Polygons

On 19.04.20 19:51, Shawn K. Quinn wrote: > I have noticed an issue putting things like the address on large > buildings. Sometimes software that generates routings (OsmAnd) doesn't > handle it gracefully and routes you to the wrong place. My preferred way to handle this is to tag a node of the

Re: [Tagging] addresses on buildings

On 05.01.20 19:22, Rob Savoye wrote: > I assume the right place for tags like 'addr:housenumber' & > 'addr:street' are on the building way, and not a standalone node ? If there is a 1:1 relationship between buildings and addresses, the building way is the most sensible location for addr tags.

Re: [Tagging] state of a proposal

On 08.12.19 18:37, Catonano wrote: > https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area > > What' s the state of this proposal ? Well, I wouldn't hold my breath for a vote unless the author (or someone who takes over the reins) reboots it, but this doesn't necessarily mean the

Re: [Tagging] How to tag pedestrian lanes?

On 21.10.19 12:12, Tobias Zwick wrote: > Though, in regards of software support, I my earlier suggestion is better, > as no modification on existing software is necessary to understand that a > sidewalk without kerb is still for pedestrians and used the same as a > sidewalk, regardless of

Re: [Tagging] Feature Proposal - RFC - (Phone)

On 28.09.19 10:31, Valor Naram wrote: > now I'm ready to open a new proposal which you can see here > https://wiki.openstreetmap.org/wiki/Proposed_features/Phone#Second_proposal_.28pending.29 I agree with the basic goal of ending the co-existence of phone and contact:phone. I don't care that much

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

On 08.09.19 18:26, Janko Mihelić wrote: On Fri, Sep 6, 2019, 15:05 Janko Mihelić wrote: > "*A Wikidata item cannot be connected to more than one OSM item*". [...] > If one wants to tag all route segments with a wikidata tag, I > propose a general usage "*part:wikidata=**" which would

Re: [Tagging] Feature Proposal - RFC - footway=indoor

On 05.09.19 18:41, Jeremiah Rose wrote: > Here's a proposal for marking indoor routes within a building mapped with > Simple Indoor Tagging. I can see some value in mapping routes through a room which is full of obstacles, but I don't like the idea of using this where a routing graph could be

Re: [Tagging] tag templates in the wiki

On 12.08.19 20:27, Martin Koppenhoefer wrote: > AFAIK the template is not filled from wikidata.org but rather from a wikidata > installation on OpenStreetMap-Foundation servers (or for OpenStreetMap but on > another server), with information harvested in the osm wiki. It is a parallel > system

Re: [Tagging] Charging stations: socket::output -- which format for the value?

On 31.07.19 09:34, Warin wrote: > There is no present default unit for power - see > https://wiki.openstreetmap.org/wiki/Map_Features/Units#Default_units > Adding a default would be good Why would it be good to add a default value? I believe explicit units are generally preferable because they

Re: [Tagging] [Indoor] is indoor=level walled ?

On 23.07.19 13:42, PanierAvide wrote: > So according to wiki, indoor=level doesn't involve having a implicit > wall following the geometry. Is it something we agree on ? indoor=level does not add an implicit wall. However, building and building:part probably do have outer walls by default,

Re: [Tagging] Removing an ATM

On 09.07.19 15:04, MARLIN LUKE wrote: > I have an ATM mapped in a street which does not exist anymore > (apparently since 2014). Historic features should not be mapped in OSM: https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_historic_events_and_historic_features Therefore, an

Re: [Tagging] one feature one element

On 05.07.19 11:57, Mariusz wrote: > On 05.07.2019 07:05, Joseph Eisenberg wrote: >> [Examples of bad situations:] "An area object representing a >> single-use building with a point object inside it. Move the tags to >> the area object and delete the point." > > This is common and widly accepted

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

On 08.05.19 01:30, Nick Bolten wrote: > Would it be fair to say you're suggesting something along the lines of > crossing:marking=*, where * can be yes, no, or a marking type? You make > a good point about the simplicity of avoiding a subtag for markings. Yes, this is pretty much what I'm

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

On 07.05.19 23:08, Nick Bolten wrote: > This proposal suggests the deprecation of crossing=traffic_signals and > replacing it with crossing:signals=yes, i.e. placing pedestrian > signalization on a dedicated tag that is separate from crossing=* values. I agree with separating orthogonal

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

On 06.05.19 15:36, Martin Koppenhoefer wrote: > Am Mo., 6. Mai 2019 um 14:06 Uhr schrieb Martin Koppenhoefer > If you can get the second one working I don’t understand why the > first one is different (presuming it is split). For the second one > to work there must also be polygonal

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

e. As I said previously: On 11.04.19 23:28, Tobias Knerr wrote: > Note that the method I describe above does not even try to work for > winding steps (i.e. those which you don't ascend in a straight line). > But there are other algorithms that would work for those, and the two >

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

On 03.05.19 18:20, Paul Allen wrote: > Or this https://goo.gl/maps/TxVMau8EBrLUAaeU6 [...] > You will note that there are narrow, normal-size steps within big > steps.  It's complicated. Yeah, there's absolutely no chance to make that guess from just a polygon OR the relation originally proposed

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

On 11.04.19 23:28, Tobias Knerr wrote: > A decent heuristic is to connect each node from the upper border to the > closest point (not necessarily a node) on the lower border, and vice > versa. Then you place steps at regular intervals along these connections. > > For com

Re: [Tagging] Verifiability wiki page: "Geometry" section added

On 28.04.19 13:51, Mateusz Konieczny wrote: > "A place=hamlet often lacks verifiable borders. Hamlets in farming areas > often have scattered houses and farms extending outward for several > kilometers. In this case the approximate center of the place may be > well-know, but the outer limits are

Re: [Tagging] Verifiability wiki page: "Geometry" section added

On 28.04.19 11:43, Joseph Eisenberg wrote: > Please suggest any improvements to the wording or corrections: > https://wiki.openstreetmap.org/wiki/Verifiability#Geometry I'm afraid I can't support the addition of this new rule. Yes, it's often not possible to agree on a precise border for these

Re: [Tagging] Comments on documenting winter speed limits tagging

es, though. As I said before: > On 3.4.2019 19.40, Tobias Knerr wrote: >> Even if we keep "winter" in the key, the >> ":seasonal" should definitely be dropped. After all, we use >> maxspeed:forward (not maxspeed:directional:forward) and maxspeed:hgv >>

Re: [Tagging] junction=yes as a polygon. Who uses them?

On 19.04.19 18:35, Dave F via Tagging wrote: > Following a discussion on OSM-Carto, I'm curious what software uses > junction=yes as a polygon. Polygons with junction=yes + area:highway=* are part of some variants of street area tagging, e.g. https://wiki.osm.org/Proposed_features/Street_area

Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?

On 14.04.19 11:56, Joseph Eisenberg wrote: > Thanks, Martin! I couldn’t find that link. On many wiki pages, the infobox template will show an icon next to the status (e.g. "approved"). Clicking that icon links to the proposal. The link is based on the "statuslink" field of the template, and I

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

On 10.04.19 00:45, Warin wrote: > But then if they are curved or have corners then in order to project > that correctly form one way to the other they would need to have > corresponding nodes. > Say if is curved at the top but not at the bottom .. if the curve goes > straight down .. ok .. but

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

On 29.03.19 07:05, Warin wrote: > https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps Detailed steps would be great for 3d rendering, so I'm very interested in the topic as a data consumer. However, reading the proposal leaves me with open questions. Could you describe the intended

Re: [Tagging] Comments on documenting winter speed limits tagging

On 28.02.19 11:16, Jyri-Petteri Paloposki wrote: > – maxspeed:seasonal:winter for winter maxspeed, and :forward/:backward > appended as necessary Despite the feedback that maxspeed:conditional would be better suited for this use case, this key has now been documented on the wiki:

Re: [Tagging] Power transformers wiki page translations

On 24.03.19 20:55, François Lacombe wrote: > I lost the template name to indicate the translation is outdated, may > someone remind me its name please? You may be looking for the "translation out of sync" template: https://wiki.openstreetmap.org/wiki/Template:Translation_out_of_sync

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

On 05.03.19 01:01, Nick Bolten wrote: > What would you think > of a new 'associatedStreet'-style relation that would organize the > various features that should be associated between streets and the > surrounding environment? That approach could work, yes – and it's one of the few practical

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

On 03.03.19 20:12, Nick Bolten wrote: > I wanted to get a discussion started to see what people think of > mapping curbs as ways. Can we please first define a solution (e.g. a relation) for connecting such separately mapped components of a road to the highway? Painting lines next to each other

Re: [Tagging] Comments on documenting winter speed limits tagging

On 28.02.19 11:16, Jyri-Petteri Paloposki wrote: > – maxspeed:seasonal:winter for winter maxspeed, and :forward/:backward > appended as necessary Have you considered Conditional restrictions[1]? You mentioned them as one of the existing tagging solutions (you had "80 @ winter" as the example),

Re: [Tagging] sleepable:physical=yes/no? Re: How to map Hostile Architecture? e.g. benches you can't lie/sleep on?

On 28.02.19 16:15, Rory McCann wrote: > What about `sleepable:physical=yes/no`? It's clear that it's about "can > you *physically* sleep on this bench". Seems sufficiently verifiable and neutral to me. If we're going with a single-purpose tag, it's a good candidate. I don't think it's the best

Re: [Tagging] start_date variants

On 15.02.19 11:03, Stephan Bösch-Plepelits wrote: > Example: There is this museum, which openened in 2011, but the building is > much older, it was built in 1725: > https://www.openstreetmap.org/relation/1937535 The root of the issue is that two different features (a building, and a museum

Re: [Tagging] units and notations for maxstay

On 21.02.19 20:15, Andrew Errington wrote: > If there is no limit then omit the maxstay tag. No tag, no limit. Personally, I would indeed not set a maxstay tag if there's no limit. However, even if we never want to tag maxstay=unlimited, such a value would still be useful in the context of

Re: [Tagging] units and notations for maxstay

On 20.02.19 00:46, Warin wrote: > On default units .. I don't think there's a single unit that would be the obvious default for maxstay, as both minutes and hours will be common. Omitting the unit will lead to misunderstandings in that situation. Therefore, I would define no default, treat

Re: [Tagging] tree rows vs individual trees

On 09.02.19 15:23, Tom Pfeifer wrote: > "Tree rows ... This approach can also be combined with individually > mapped trees for further details." [...] > IMHO this violates the one object - one OSM element principle. Either I > choose the coarser approach to map a way for the row, or I refine it to

Re: [Tagging] The actual use of the level tag

On 22.01.19 22:18, Tobias Zwick wrote: > First, I am still in the dark a bit how this affects SIT with S3DB > compatibility, perhaps Tordanik can explain. My comment regarding S3DB compatibility was about the related issues that were brought up in this thread (e.g. indoor features outside of a

Re: [Tagging] The actual use of the level tag

On 21.01.19 22:38, Roland Olbricht wrote: > I do consider both to be SIT compliant. I'm not sure if it's clear from the written text of SIT, but neither fractional levels nor indoor features outside of a building outline were part of SIT's design. (And yes, these are obvious omissions that will

Re: [Tagging] The actual use of the level tag

On 20.01.19 19:37, Tobias Zwick wrote: > - a shop on level M with "level=M" > > - the mall building with "levels=P2,P1,G,M,1-12,14-99" (the order of the > levels). If levels is missing, a numerical order is assumed So essentially, one uses the local level reference in level=*, and provides a

Re: [Tagging] The actual use of the level tag

On 20.01.19 18:06, Roland Olbricht wrote: > I am also a bit surprised: a common interpretation of the text of > https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging > (which is where https://wiki.openstreetmap.org/wiki/Key:level > refers to) is that the level tag keeps the level numbering

Re: [Tagging] The actual use of the level tag

On 20.01.19 14:49, Tobias Zwick wrote: > 2. generally, tagging definitions that are not intuitive to use (in a > region) will not be used consistently (in that region), leading to > ambiguous data. I believe the high number of (potential) errors is temporary, resulting from the relative lack of

Re: [Tagging] Quick Building tracing question...

On 10.01.19 11:28, Allan Mustard wrote: > My understanding of the 3D aspect of building:part is that if you draw a > portion of a building using building:part you have to do the rest of the > building using building:part as well or the whole building will not > render in 3D, since 3D software is

Re: [Tagging] Facts and opinions

On 07.01.19 16:12, Bryan Housel wrote: > we can’t use the same key `service=*` to contain both things like `tyres` (a > few thousands) and `driveway` (a few millions). Sorry, but the > `service=tyres` has to go. These two different meanings of 'service=*' would not need to coexist on the same

Re: [Tagging] amenity=taxi vehicle type

On 05.01.19 02:19, Warin wrote: > On 05/01/19 10:34, Tom Pfeifer wrote: >> taxi_type = car|motorcycle|rickshaw, etc, > > What does 'type' add to the above? The key taxi=* is already in use to tag access permission for taxi vehicles, with values such as yes|no|designated|destination|permissive.

[Tagging] Feature Proposal - RFC - Top up

On 26.12.2018 19:05, bkil wrote:> top_up:phone:‹brand›=yes;no > top_up:transport:‹brand›=yes;no > top_up:credit_card:‹brand›=yes;no > > This is not the same wording as discussed above, but I still like this one. I'd prefer if the supported brands were part of the value – as most brand-related

Re: [Tagging] 2 meaning for crossing=zebra

On 26.10.2018 11:11, Mateusz Konieczny wrote: > In general crossing tag is attempting to tag several different things > at once - for example how I am supposed to tag crossing with island, > traffic lights and zebra markings in Poland? The presence of an island is quite commonly tagged as

[Tagging] 2 meaning for crossing=zebra

On 26.10.2018 16:24, Tom Pfeifer wrote: > Do you see the contradiction? If the crossing is unmarked, the ground > object already does not provide any guidance. As we map what's on the > ground, there is nothing to map. It's not uncommon for a crossing to be physically evident on the ground (e.g.

Re: [Tagging] 2 meaning for crossing=zebra

On 26.10.2018 01:18, Bryan Housel wrote: > Oh! I don’t like `crossing=zebra` either. Not sure whether you caught the > end of that issue #4788, but anyway I've decided I'm tired of hearing people > complain about `crossing=zebra` so going forward iD will support these 2 > presets: > > -

Re: [Tagging] Opening hours too long for OSM

> Am 12.10.2018 um 01:27 schrieb Simon Poole: >> We have a number of keys for which the values can easily exceed 255 >> chars besides opening_hours, lane destinations and conditional >> restrictions are good candidates. Not to mention changeset tags. With >> other words it is a general problem

Re: [Tagging] highway=crossing used on ways

On 12.10.2018 09:25, Gerd Petermann wrote: > In November 2015 I fix nearly all such ways, since then the number increased > again to 488. I don't know about iD, but JOSM prints a warning > when you use this tagging, still many edits were made with JOSM. I wonder if > that means that we should

Re: [Tagging] Traffic_sign discussion

On 09.10.2018 17:42, yo paseopor wrote: > So Please , let's talk about it. What will be the correct way to tag a > traffic sign? How about the existing tagging scheme for traffic signs on nodes, documented at https://wiki.osm.org/Key:traffic_sign ? To sum it up: - Place a node for the traffic

Re: [Tagging] building:min_level, building:max_level, min_level, max_level

On 08.10.2018 15:55, Martin Koppenhoefer wrote: > Version A is used and defined here: > https://wiki.openstreetmap.org/wiki/Key:building:levels > https://wiki.openstreetmap.org/wiki/Key:building:min_level > https://wiki.openstreetmap.org/wiki/Simple_3D_buildings > > Version B mentions the tags

Re: [Tagging] Traffic sign direction tagging..

On 02.10.2018 16:44, yo paseopor wrote: > Also it is not the best call "undersigns" . There are signs too, with > their code, and you can put in on second place or third place , like > traffic_sign:2 as Finnish people does. Or put them in a comma-separated list, which is the international

Re: [Tagging] double doors?

On 17.08.2018 14:10, seirra wrote: > should these be split into two separate door elements, or should it be > tagged as just a really wide door? Assuming we're talking about a hinged door with multiple wings, there's a proposed door:wings key with 178 uses at the time of writing. Using that, you

Re: [Tagging] Put the name in sidewalks and cycleways

On 06.08.2018 05:59, Andrew Harvey wrote: > I like the idea of adding the sidewalk to the associatedStreet relation, > perhaps role=sidewalk? Streets can branch into an arbitrarily complex network where all the branches still share the same name. A single relation containing all streets and

Re: [Tagging] Put the name in sidewalks and cycleways

On 05.08.2018 17:16, yo paseopor wrote: > So what is the correct way to map it: with name? or without name? Adding name tags to separately mapped sidewalks is an attempt to fix just one of the symptoms of a deeper problem: The lack of a machine-readable link between the sidewalk way and the road

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

On 26.07.2018 21:26, François Lacombe wrote: > Then store voltage=40 is far way better but harder to be read by > humans also. I currently prefer explicit units in the database because they document the mapper's intent and avoid ambiguity. Defaults aren't always obvious. For example, people

Re: [Tagging] landuse=sand

On 18.07.2018 07:43, Warin wrote: > I have already changed a few. Are there any comments on changing > landuse=sand, before it becomes like landuse=grass etc,? I fully agree with you that landuse=sand should not be used. Existing tags like natural=sand and surface=sand already cover sand-related

Re: [Tagging] building=clubhouse

On 19.07.2018 05:15, Warin wrote: > Would it not be best to combine all theses into building=clubhouse? I'm not opposed to the general idea of having a sport-independent tag for clubhouses, if we can agree on a suitable tag. However, please remember that the value of building=* does _not_

Re: [Tagging] `amenity=shelter` implies `building=yes`?

On 18.06.2018 17:22, Kevin Kenny wrote: > Would it be feasible to say that building=yes is a default (except, > perhaps, for rock_shelter, sun_shelter) and that mappers are expected to > place an expected building=no on the exceptions? Using building=no is a bad idea, as any object tagged

[Tagging] wall and block that aren't a barrier

On 09.06.2018 23:13, marc marc wrote: > https://upload.wikimedia.org/wikipedia/commons/thumb/2/22/Rehbrunnen_04.jpg/800px-Rehbrunnen_04.jpg Based on this picture, the current mapping is clearly incorrect. This basin doesn't qualify as a barrier=retaining_wall even if we allow for a very generous

Re: [Tagging] brand=* necessary?

On 10.05.2018 16:23, Martin Koppenhoefer wrote: > The reason why it is done differently is not an educated decision but the > result of poor presets and mappers filling them in without further reflection. Sure, but uneducated decisions reveal a lot about people's intuitions and interests – two

Re: [Tagging] access=disabled

On 10.05.2018 05:04, Johnparis wrote: > access=no > disabled=yes > > ...to be consistent with other such, like  > access=no > bus=yes Unlike "bus", "disabled" is not a mode of transport, so it should not be used in the key of access tags. ___ Tagging

Re: [Tagging] brand=* necessary?

On 10.05.2018 09:52, marc marc wrote: > Imho it us the opposite : name should be added only if it us not the > same as brand That approach is different from real-world usage of the tags and appears to offer little practical benefit. As far as I can tell, many – probably most – mappers look at

Re: [Tagging] Small gate only for foot access

On 20.04.2018 14:03, osm.tagg...@thorsten.engler.id.au wrote: > Just because it’s not as often used in this way doesn’t mean it’s wrong. In my opinion, it's indeed wrong, but not so much because of the low number of uses. Instead, it's wrong because it contradicts the relatively well-defined

Re: [Tagging] RFC - Key: spacing=*

Hi Peter, On 18.04.2018 13:53, Peter Elderson wrote: > I am exploring the possibility of proposing a new key for spacing of > more or less regularly distributed objects along a way or over an area. I like the idea. Way back, during the the tree row proposal, it was suggested that either this key

Re: [Tagging] AutoEdit rename roof:slope:direction to roof:direction

On 12.02.2018 01:06, marc marc wrote: > https://www.openstreetmap.org/changeset/56277877 > the POC for the first part Not sure if you're still waiting for feedback on your proof of concept? In any case, I've had a look at those changes, and they're looking good to me! I'd be happy to see the edit

Re: [Tagging] AutoEdit rename roof:slope:direction to roof:direction

On 10.02.2018 17:55, User Rebo wrote: > Update: Since now I have 4 positive responses (via OSM messages or > forum). And no objections. > Can start renaming? I think the consensus is sufficiently clear to proceed. Nevertheless, it would still be nice to create a small wiki page to document your

Re: [Tagging] Proposed definition for surface=cobblestone/sett/paving_stones

On 22.01.2018 17:25, Fernando Trebien wrote: > - sett: hewn stones with flat top (...) [2] (...)> - cobblestone: hewn stones > with slightly arched top (...) images [3] and [4] I don't believe requiring mappers to make a distinction between these two is a good idea. Let's look at your images: >

Re: [Tagging] How to tag shop areas in a shopping mall ?

On 21.01.2018 17:48, OSMDoudou wrote: > When I tag the perimeter with indoor=room instead of building=yes, JOSM > raises an error "Overlapping ways" for the segment B->C in this kind of > layout: [...] > If I change the tags from indoor=wall to building=yes, no error is raised > anymore (but

Re: [Tagging] How to tag shop areas in a shopping mall ?

On 17.01.2018 23:16, OSMDoudou wrote: > There is a shopping mall here [1] for which a mapper detailed the inside > shops with a node for the "identity" and an area for the "physical > perimeter" of the shop inside the mall. [...] > Can you suggest tagging improvements ? My suggestion (based on

Re: [Tagging] area=yes on object without kind

I sometimes use surface=* as a stand-alone tag for areas with an unclear or uninteresting purpose. Doing so captures the physical reality on the ground pretty well in my opinion. From this point of view, the area in question is already tagged correctly. Maybe we can find out what it's being used

Re: [Tagging] Proposal: logo tag. Opinions?

On 19.09.2017 23:41, Martin Koppenhoefer wrote: > AFAIK wikidata's notability requirements should not be an issue, because > it is sufficient there is a link to a commons page [1] to comply. > [1] https://m.wikidata.org/wiki/Wikidata:Notability The notability requirements specifically mention

Re: [Tagging] Proposal: logo tag. Opinions?

On 19.09.2017 16:27, José G Moya Y. wrote: > It's up to > the rendering app creators to decide if they want to display some shops > using its logos. In that case, the app would probably have some other > way to display them. What way would that be? Unless we want each render style author to

Re: [Tagging] Proposal: "slogan" tag. Opinions?

On 19.09.2017 09:46, SwiftFast wrote: > Imagine an app where you'd click a shop, then you'd get a popup with a > logo(see my other proposal), a slogan, and a description. All of these > help a user understand what they're looking it. While I accept the argument that logos allow easy visual

Re: [Tagging] Feature Proposals - RFC for multiple features - Education Reform - Magnetic Levitation Trains

On 17.09.2017 07:54, Erkin Alp Güney wrote: > This brings education key instead of amenity=school. In my opinion, and speaking broadly, the job of the OSM tagging system is to answer two questions: - What kind of feature is this? - What properties does this feature have? The first question can

Re: [Tagging] contact:* for review websites

On 16.09.2017 00:56, Tom Pfeifer wrote: > IMHO these are not means of contact, instead these are review websites. > While I personally think that we do not need them in OSM at all, they > certainly do not belong in the contact:* namespace. I agree that these aren't contact channels, and it makes

Re: [Tagging] Simplify building:part areas

On 18.08.2017 10:01, Tom Pfeifer wrote: > If e.g. the lower floors of the apartment building is wider than the > upper floors, you can tag the outline with both, building=apartments and > building:part=yes and the appropriate 3D-properties, and the narrower > upper floors with building:part=yes

  1   2   3   4   >