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

2020-09-18 Thread Tobias Knerr
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?

2020-09-16 Thread Tobias Knerr
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?

2020-09-12 Thread Tobias Knerr
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 ?

2020-08-31 Thread Tobias Knerr
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

2020-08-07 Thread Tobias Knerr
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

2020-08-07 Thread Tobias Knerr
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

2020-07-24 Thread Tobias Knerr
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

2020-07-24 Thread Tobias Knerr
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

2020-06-28 Thread Tobias Knerr
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

2020-06-26 Thread Tobias Knerr
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?

2020-06-26 Thread Tobias Knerr
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

2020-06-17 Thread Tobias Knerr
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

2020-04-19 Thread Tobias Knerr
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

2020-04-19 Thread Tobias Knerr
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

2020-01-05 Thread Tobias Knerr
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

2019-12-08 Thread Tobias Knerr
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?

2019-10-21 Thread Tobias Knerr
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)

2019-10-05 Thread Tobias Knerr
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

2019-09-08 Thread Tobias Knerr
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

2019-09-05 Thread Tobias Knerr
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

2019-08-12 Thread Tobias Knerr
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?

2019-08-04 Thread Tobias Knerr
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 ?

2019-07-26 Thread Tobias Knerr
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

2019-07-09 Thread Tobias Knerr
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

2019-07-05 Thread Tobias Knerr
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

2019-05-22 Thread Tobias Knerr
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

2019-05-07 Thread Tobias Knerr
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.

2019-05-06 Thread Tobias Knerr
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.

2019-05-04 Thread Tobias Knerr
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.

2019-05-04 Thread Tobias Knerr
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.

2019-05-03 Thread Tobias Knerr
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

2019-04-28 Thread Tobias Knerr
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

2019-04-28 Thread Tobias Knerr
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

2019-04-24 Thread Tobias Knerr
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?

2019-04-19 Thread Tobias Knerr
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?

2019-04-14 Thread Tobias Knerr
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.

2019-04-11 Thread Tobias Knerr
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.

2019-04-09 Thread Tobias Knerr
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

2019-04-03 Thread Tobias Knerr
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

2019-03-24 Thread Tobias Knerr
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

2019-03-05 Thread Tobias Knerr
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

2019-03-04 Thread Tobias Knerr
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

2019-02-28 Thread Tobias Knerr
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?

2019-02-28 Thread Tobias Knerr
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

2019-02-22 Thread Tobias Knerr
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

2019-02-21 Thread Tobias Knerr
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

2019-02-21 Thread Tobias Knerr
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] units and notations for maxstay

2019-02-21 Thread Tobias Knerr
On 20.02.19 00:08, Warin wrote: > 24/7 is used for opening hours - so for consistency I would tend to go > for that. Maxstay values are durations, opening_hours values (such as "24/7") refer to time intervals. Those are separate concepts, so I don't think consistency is called for. If we want an

Re: [Tagging] tree rows vs individual trees

2019-02-09 Thread Tobias Knerr
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

2019-02-03 Thread Tobias Knerr
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

2019-01-21 Thread Tobias Knerr
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

2019-01-20 Thread Tobias Knerr
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

2019-01-20 Thread Tobias Knerr
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

2019-01-20 Thread Tobias Knerr
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...

2019-01-11 Thread Tobias Knerr
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

2019-01-09 Thread Tobias Knerr
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

2019-01-05 Thread Tobias Knerr
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

2018-12-27 Thread Tobias Knerr
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

2018-10-26 Thread Tobias Knerr
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

2018-10-26 Thread Tobias Knerr
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

2018-10-26 Thread Tobias Knerr
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

2018-10-12 Thread Tobias Knerr
> 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

2018-10-12 Thread Tobias Knerr
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

2018-10-09 Thread Tobias Knerr
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

2018-10-08 Thread Tobias Knerr
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..

2018-10-02 Thread Tobias Knerr
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?

2018-08-17 Thread Tobias Knerr
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

2018-08-06 Thread Tobias Knerr
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

2018-08-05 Thread Tobias Knerr
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

2018-07-27 Thread Tobias Knerr
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

2018-07-19 Thread Tobias Knerr
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

2018-07-19 Thread Tobias Knerr
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`?

2018-06-18 Thread Tobias Knerr
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

2018-06-11 Thread Tobias Knerr
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?

2018-05-10 Thread Tobias Knerr
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

2018-05-10 Thread Tobias Knerr
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?

2018-05-10 Thread Tobias Knerr
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

2018-04-20 Thread Tobias Knerr
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=*

2018-04-18 Thread Tobias Knerr
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

2018-02-18 Thread Tobias Knerr
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

2018-02-11 Thread Tobias Knerr
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

2018-01-22 Thread Tobias Knerr
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 ?

2018-01-21 Thread Tobias Knerr
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 ?

2018-01-18 Thread Tobias Knerr
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

2018-01-12 Thread Tobias Knerr
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?

2017-09-20 Thread Tobias Knerr
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?

2017-09-19 Thread Tobias Knerr
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?

2017-09-19 Thread Tobias Knerr
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

2017-09-17 Thread Tobias Knerr
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

2017-09-16 Thread Tobias Knerr
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

2017-08-18 Thread Tobias Knerr
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

Re: [Tagging] Formally informal sidewalks

2017-07-16 Thread Tobias Knerr
On 15.07.2017 19:06, Nick Bolten wrote: [...] > It can't properly describe > crossings, since they've been condensed into a node, but important > information like length, the curbs at each side (direction of > traversal + curb type both matter), APS directionality, etc, are all > essentially

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

2017-05-22 Thread Tobias Knerr
On 21.05.2017 22:23, yo paseopor wrote: > As you can see in http://imgur.com/gallery/SgE90 with Kendzi3D JOSM > plugin you can locate the traffic signs belonging to a way. Of course it's always possible to guess a place next to the road, but even with your proposed side=* tagging, that's not

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

2017-05-21 Thread Tobias Knerr
On 21.05.2017 14:05, Colin Smale wrote: > So, in simple language, WHY do we put traffic signs into > OSM? The use case I'm interested in is having the location of the physical object available, e.g. for 3D rendering. This is also why I'm in favour of placing signs in their actual on-the-ground

Re: [Tagging] wikipedia links and copy + paste in tag definitions

2017-04-30 Thread Tobias Knerr
On 29.04.2017 22:26, Martin Koppenhoefer wrote: > Don't link to WP, especially not in the beginning (as if their definition > automatically was equal to ours), because even if the current state is fine, > we don't control WP and don't know how they will structure their lemmas in > the future.

Re: [Tagging] Feature Proposal - RFC - bus bay

2017-04-06 Thread Tobias Knerr
On 06.04.2017 19:40, Martin Koppenhoefer wrote: why do you define this as a node? bus_bay=right or left does not make sense on a node, and bus bays have a certain length anyway, I'd make it a way. It should not be a separate way if there is no physical separation. But I agree a node is not a

Re: [Tagging] simple 3D buildings, proposed redefinition of building:levels and building:min_level for building:part

2017-03-09 Thread Tobias Knerr
On 08.03.2017 18:32, Martin Koppenhoefer wrote: building:levels - building:min_level < 0 yes: new no: old I believe you are mistaken here. Consider the following example: building:levels = 2 building:min_level = 1 According to the Simple 3D Buildings standard, this means that there is a

Re: [Tagging] how to map simple buildings

2017-03-04 Thread Tobias Knerr
On 04.03.2017 18:05, "Christian Müller" wrote: Thanks for the examples and conclusion given. This is a strong reason to demand its usage in wiki docs and IMO we should even suggest their usage generally, regardless of the construction site's complexity. Situations complex enough to require

Re: [Tagging] Invalid voting of proposed feature motorcycle_friendly=*

2017-03-02 Thread Tobias Knerr
Hi Michael, On 02.03.2017 20:21, Michael Reichert wrote: Because the proposal violated the guideline, I would like to - remove the status "proposed" from its feature documentation page - reset the status of the proposal to "RFC" - to declare the voting as invalid by adding a note at the top of

Re: [Tagging] Feature Proposal - RFC - CoreIndoor

2017-02-13 Thread Tobias Knerr
Hello Pavel, On 08.02.2017 09:09, Pavel Zbytovský wrote: https://wiki.openstreetmap.org/wiki/Proposed_features/CoreIndoor as one of the authors of Simple Indoor Tagging (SIT), I'd like to comment on each of your proposed changes. So please excuse the wall of text below. :) First, thank

  1   2   3   4   >