[Tagging] IndoorOSM 2.0

This is really just a heads up on the ongoing discussion in the indoor forum http://forum.openstreetmap.org/viewforum.php?id=67 and the competing proposals https://wiki.openstreetmap.org/wiki/IndoorOSM_2.0 and https://wiki.openstreetmap.org/wiki/F3DB . I have to admit even though the IndoorOSM

Re: [Tagging] interpolated housenumbers on single objects

Am 20.08.2014 12:11, schrieb Ilpo Järvinen: ... lots of stuff from past experiences ... There is no reason not to immediately enter the address data, preferably as entrance nodes if the building outlines exist, if they don't, placing an address node at an appropriate place is far easier if you

Re: [Tagging] interpolated housenumbers on single objects

tricycle) and you still end up with having to post process, which again takes more time than doing it properly (at 1st glance slower) in the fist place. Simon Am 20.08.2014 13:52, schrieb Ilpo Järvinen: On Wed, 20 Aug 2014, Simon Poole wrote: Am 20.08.2014 12:11, schrieb Ilpo Järvinen: ... lots

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

Am 25.08.2014 16:46, schrieb fly: . Did you have a look at the three existing proposals about complex junctions ? .. IMHO one of the nice aspects of variant 4 (using an area) is that it really doesn't collide with however the routing aspects of the junction are mapped.

Re: [Tagging] default value for oneway

I believe that you haven't explicitly said so, but probably essentially want to be able to find streets that haven't been surveyed and potentially need a oneway tag and avoid false positives (aka such that are actually bi-directional). I don't believe you'll get any further with the oneway tag,

Re: [Tagging] default value for oneway

Am 28.08.2014 17:07, schrieb Xavier Noria: ... That makes me also wonder as a side-effect about the implication of the current contract and the usage patterns it promotes. Implications in particular for turn-by-turn indications, but that was secondary, my main motivation is the one above.

Re: [Tagging] default value for oneway

Am 28.08.2014 19:10, schrieb Xavier Noria: ... But for example, every single client software of OSM that is out of control of OSM is assuming that contract. That's what I believe makes a reset (no NULLs in the database) plus semantic change for NULLs would not be possible. No way to

Re: [Tagging] include smoothness=* in JOSM presets?

As somebody who participates in at least two outdoor activities in which road conditions are an important comfort factor* (inline skating and riding a road bike) it would be great to have a reasonably reliable indication of what to expect on a certain road segment additionally to the pure

Re: [Tagging] include smoothness=* in JOSM presets?

I don't think anybody was complaining about the words used for values per se, they will still be good for a chuckle in 20 years from now. However the wiki definition of how the values should be determined is simply FUBAR, and in no way defines each value pretty good. There is no point in

Re: [Tagging] include smoothness=* in JOSM presets?

A last try at illustrating the insanity of the smoothness definitions. Switzerland has an extensive network of signposted inline skating routes, including the world longest single route at something around 400km (see http://skating.waymarkedtrails.org/en/ ). For readers that have never used

Re: [Tagging] sport= non-physical tags and the exceptions people come up with...

Am 20.10.2014 20:37, schrieb Janko Mihelić: What people probably want to tag are waters that are interesting to scuba divers. Maybe we should make a tag like leisure=scuba_diving_attraction. . I beg to differ, there is a fairly wide range of restrictions at least on inland bodies

Re: [Tagging] oneway=no spams

Am 28.12.2014 um 19:20 schrieb Andy Street:. These tags are far from information-less as they convey the fact that a mapper has considered the property in question and wishes to record that it does not apply. I'm afraid that you are kidding yourself in a big way. Nearly all massive, I will

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

Am 28.03.2015 um 16:10 schrieb Hubert: That's not what I wanted to say. A cycleway is mandatory if has one of the signs 237, 240 or 241 AND it is parallel to a road. A sign by itself doesn't make a cycleway mandatory. You have something confused there. Germany has two (forgetting about

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

Am 28.03.2015 um 15:31 schrieb Hubert: For example a lot of cross country cycleways (like this one https://commons.wikimedia.org/wiki/File:Altmarkrundkurs.jpg ) can't possibly be mandatory, since there is no road next to it. But they are designated and official. There is no such thing as

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

Am 28.03.2015 um 14:23 schrieb Hubert: I believe this is the issue here. For me bicycle=designated and bicycle=official don't say that a cycleway is mandatory. It only says that this way is meant for cyclist or is built for cyclist only. And while bicycle=official is mostly used for

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

I have to say that this adds yet another value to the bicycle tag that doesn't solve any problems (note: if at all it naturally should be mandatory however that is not my primary concern). We have bicycle=designated and bicycle=official for mandatory use cycleways (where the concept of such

Re: [Tagging] Wiki edits on junction=roundabout

The background is an osm2pgsql issue, the wiki edit itself is IMHO mistaken see: https://github.com/openstreetmap/osm2pgsql/issues/304 Am 23.02.2015 um 08:43 schrieb Martin Vonwald: Hi! Can someone please explain these edits to me:

Re: [Tagging] [Wiki Talk] Why OSM and not another collaborative mapping service?

I'm really not sure what this discussion is doing on tagging and have redirected follow ups to talk (it has in the matter of a few mails already gone substantially off-topic though). The page in question is actually a fork of http://wiki.openstreetmap.org/wiki/Google_Map_Maker which was written

Re: [Tagging] Long Tail ( was Removal of amenity from OSM tagging)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 19. Mai 2015 03:18:14 MESZ, johnw jo...@mac.com wrote: there’s no preset “I want to add a business” or “I want to add a park” tutorials that walk through the basics and hold your hand, bring up options and ask you natural language

Re: [Tagging] Long Tail ( was Removal of amenity from OSM tagging)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 We don't have access to non - editing accounts, speculating on the composition of them is just that. We do know that not all of the roughly 1.5 million are spammers, See my two recent diary posts for more, On 19. Mai 2015 04:55:30 MESZ, Bryce

Re: [Tagging] Long Tail

Am 19.05.2015 um 14:40 schrieb Daniel Koć: W dniu 19.05.2015 14:25, SomeoneElse napisał(a): Also, it's worth mentioning that despite people sometimes describing OSM as unfriendly the vast majority of changeset discussion comments, especially to new users, are very friendly and happy to

Re: [Tagging] Opening hours specification

BTW while it is still work in progress (now mainly because the android UI isn't finished yet) https://github.com/simonpoole/OpeningHoursParser is a JavaCC based parser which attempts to implement the full spec, undoubtedly I've probably missed one or two special cases, but it is fairly

Re: [Tagging] "What can I ask ..." list for browsing people

You click on "Help" then on "Beginners Guide" Am 01.11.2015 um 19:10 schrieb André Pirard: > ... > > What can I show to Mr X? > This is extremely off topic btw. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list

Re: [Tagging] new access value

People, sometimes creatively, put lots of stuff on signs that don't necessarily correspond to the set of values that is actually supported by law*. It frankly doesn't make sense to try and capture each fine semantic difference (wit visitor vs. destination), particularly as it may simply be

Re: [Tagging] new access value

Am 06.10.2015 um 11:29 schrieb Friedrich Volkmann: > ... > It's *not* destination, see my other posts. > To put it more clearly: > "destination" targets a location, while Anrainerverkehr targets people. > You can also see it like this: > "destination" is about where you go, while Anrainerverkehr

Re: [Tagging] new access value

Am 06.10.2015 um 12:02 schrieb Martin Koppenhoefer: > > > Yes, I didn't imply this. There's another possibility: split it into > several tags, that can be combined to describe the actual situation > (e.g. 2 or 3 rather than one tag). Each of these could have specific > (global) meaning, and

Re: [Tagging] new access value

Am 06.10.2015 um 11:15 schrieb Martin Koppenhoefer: > ... > whether the routers do evaluate these rules specifically should not > matter to us. We should try to capture the reality, also in subtle > details, so that someone _could_ interpret the data precisely if he > wanted to. > ... The proper

Re: [Tagging] new access value

Am 05.10.2015 um 12:01 schrieb Friedrich Volkmann: > ... > Many people have been using (motor_)vehicle=destination for this, but that's > just wrong, because "destination" would mean that you are allowed to drive > in to take a walk or shoot photos. In exchange, "destination" would prohibt >

Re: [Tagging] new access value

Am 05.10.2015 um 14:56 schrieb Volker Schmidt: > .. > The wiki http://wiki.openstreetmap.org/wiki/Key:access explicitly > mentions the German "Anlieger frei" and to the best of my knowledge > that is equivalent to the Austrian German "Anrainer" And to the Swiss Zubringerdienst ...

Re: [Tagging] new access value

Am 05.10.2015 um 16:36 schrieb Richard: > ... just trying to imagine the poor router trying to decide how to > route such an area. While some of the OSM specific routers haven't implemented it at this point in time, in general routers have no issue at all with it. The rough US-equivalent from a

Re: [Tagging] RFC - Level:ref=*

This seems to lead to tons of unnecessary redundancy as proposed: as an extra tag on POis that already has a level tag. I would rather be looking for something that fits in with SIT (http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging) better. Since SIT works really well (see OpenLevelUp),

Re: [Tagging] RFC - Level:ref=*

Am 30.11.2015 um 10:26 schrieb Martin Koppenhoefer: > > 2015-11-29 22:05 GMT+01:00 Simon Poole <si...@poole.ch > <mailto:si...@poole.ch>>: > > I would rather be looking for something that fits in with SIT > (http://wiki.openstreetmap.org/wiki/Simple_Indoor_Ta

Re: [Tagging] Agreement on units and tagging for maxstay?

The German version of the wiki page specifies minutes when no unit is given and this is what is in use in JOSM and Vespucci. Simon Am 09.12.2015 um 23:00 schrieb Bryan Housel: > We recently got a request to add the `maxstay` field to iD’s parking > preset. This seems like a useful field, but

Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path

This one of the more bewildering threads I've ever seen on tagging. Surely we have more than enough tags to indicate the physical attributes of ways for movement by foot or single track vehicles, and yes as nearly always there is a some overlap and grey area between when you would use a footway

Re: [Tagging] Tagging of Multi-Use Building

Either nodes and/or SIT (http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging) openlevelup.net can be used to visualize. Simon Am 28.06.2016 um 13:05 schrieb jeffrey.rho...@geogr.uni-giessen.de: > Hello, > I'm currently working on a Campus Information System via OSM for my > university,

Re: [Tagging] Feature Proposal - RFC - access:electric = * - Access key for vehicles powered by an electric motor

IMHO the main issue with this proposal is that the legal and technical situation is in flux and it is rather unlikely that access will be based on propulsion technology itself. For example access could be emissions based (as in the German "Umweltzonen"

Re: [Tagging] building=yes for multiple building

IMHO we always allow and support progression from rough to more detailed. If actual building outlines are difficult to determine then one outline for the complex is completely OK. Typical example: medieval cities. Am 16.03.2016 um 15:47 schrieb joost schouppe: > Is it OK to map multiple

Re: [Tagging] building=yes for multiple building

We are really discussing two different issues here. - use of building key for buildup areas that should be landuse=residential or other landuse variants, don't think anybody disagrees that building is misplaced is such situations - use of one building outline for a complex of potentially more

[Tagging] sloped_curb, kerb and god knows what left in limbo ......

Accidentally I noticed today that iD was suggesting a sloped_curb tag for crossings, it piqued my curiosity a bit and it seems that we have the situation now, that we have two different tagging systems in moderate use (~20'000 occurrences of slopped_curb and kerb each). But no documentation for

Re: [Tagging] JOSM preset with strange tag values

Two observations - the motorcycle preset in its present form (well with the exception of an improvement from yours truly) exists since at least JOSM 3498 6 years ago ... debating the motivations of whoever added the sale key is rather moot at this point in time. - pure motorcycle rental

Re: [Tagging] Draft of proposal tag 'sells' for shops..

It really really really really is not a good idea to pollute the key name space with an indeterminate number of sub-keys* instead of placing values in the, no surprise there, value part. it essentially guarantees that nobody will ever evaluate any of the information and even if the proposal would

Re: [Tagging] sloped_curb, kerb and god knows what left in limbo ......

Am 03.03.2016 um 11:23 schrieb Martin Koppenhoefer: > > 2016-03-02 17:42 GMT+01:00 Simon Poole <si...@poole.ch > <mailto:si...@poole.ch>>: > > While the abandoned proposal seems to be more complete and I can't say > anything about the other

Re: [Tagging] sloped_curb, kerb and god knows what left in limbo ......

question was solely if there is some consensus that the kerb proposal is actually how it should be tagged now or if it is truly defunct and the original tagging scheme should continued to be used (as iD does). Simon Am 03.03.2016 um 11:58 schrieb Martin Koppenhoefer: > > 2016-03-03 11:43

Re: [Tagging] sloped_curb, kerb and god knows what left in limbo ......

Recently I believe in this case was 2010 . Simon Am 07.03.2016 um 19:39 schrieb Andy Mabbett: > On 2 March 2016 at 16:42, Simon Poole <si...@poole.ch> wrote: >> While the abandoned proposal seems to be more complete and I can't say >> anything about the other variant b

Re: [Tagging] sloped_curb, kerb and god knows what left in limbo ......

07.03.2016 um 19:39 schrieb Andy Mabbett: > On 2 March 2016 at 16:42, Simon Poole <si...@poole.ch> wrote: >> While the abandoned proposal seems to be more complete and I can't say >> anything about the other variant because of the lacking documentation, I >> don't really care

Re: [Tagging] setting proposals to abandoned

Slightly off-topic but there is a renewed effort to improve the childcare/pre-school education under way on the German forum. Naturally the issues that you touched on have not gone away and it remains tricky to get find a solution that is reasonably simple to tag and at the same time tries to

Re: [Tagging] Suggested way to map disputed country borders

As somebody who regularly has to respond to complaints from officials and others on boundary matters, I fail to see how mapping additional borders (and a lot of them, given that there are nearly no countries without disputes) is going to help. Matter of fact it is guaranteed to make things worse

Re: [Tagging] Artworks inside the Louvre

Isn't this a bit of a non-question, given that neither the indoor, nor the level tag is currently imported in to the rendering database, so you really only have the option of testing if the object in question is in a building outline or not (which may be a bit expensive). Simon Am 24.07.2016 um

Re: [Tagging] Layer and highway=steps

Bjoern The layer attribute is only used for overlapping OSM elements to indicate their relative position ( indoor mapping should be using "level" (the SIT tagging scheme has already been referenced). In a pure indoor scenario I would consider layer unnecessary (JOSM will naturally complain

Re: [Tagging] "no right turn on red" tagging?

The defaults per territory concept exists since a -very- long time (2008) ... http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions In this case IMHO given that the sign doesn't actually change access/routing it simply modifies the meaning of the traffic signal, any tagging

Re: [Tagging] Feature Proposal - RFC - CoreIndoor

Currently nothing breaks when SIT is used and additional ways are added as a stop gap measure to enable "current" routing engines to work a bit in such areas (just as it is common to do with pedestrian areas and so on), and nobody has suggested that such mapping be outlawed (if that was at all

Re: [Tagging] access: motorcar and goods, how to read the hierarchy

Mistake #1: assuming that there is a vehicle class hierarchy (of any kind). Typically law-makers see no reason to conform to computer science niceties when drafting regulations (rightly so) and will simply add or deduct vehicle properties in ways that make sense for the regulation in question

Re: [Tagging] Tagging of Country Names

the reasons we end up with these multiple names names), but much less so than territorial claims. > > Some problems don't have good solutions. > IMHO trying to make everybody happy wrt such claims is outside the scope of OSM and unlikely to be possible in any case. Simon > > On

Re: [Tagging] Tagging of Country Names

preferred? Which would nicely cover the case of India Andy was referring to. @andy btw the whole is about making easier to express local preference, not harder. Am 26.10.2016 um 14:34 schrieb Martin Koppenhoefer: > > sent from a phone > >> Il giorno 26 ott 2016, alle ore 10:38, Sven Geggus >>

[Tagging] Pedibus / Walking bus routes

Yes that seems to be a thing (see https://en.wikipedia.org/wiki/Walking_bus and https://de.wikipedia.org/wiki/Pedibus). We've locally (CH) received a question as to how to map such routes and there doesn't seem to be any established tagging outside of using route=foot in France which likely is

Re: [Tagging] Tagging of Country Names

As an inhabitant of one the countries mentioned with multiple official languages may I quickly chip in: our previous solution was to simply leave the name tag empty given that stuffing the 4 official language variants in to the name tags was rather unwieldy and even so none of them are actually

Re: [Tagging] Tagging of Country Names

Am 26.10.2016 um 21:56 schrieb Martin Koppenhoefer: .. a lot of things that are likely right But nobody was discussing removing minority and similar status language name:xx variants and further they don't normally get included in the "name" tag as is. Difficult to see why you believe

Re: [Tagging] Solar shop

I believe the correct expression is photovoltaic (which would exclude hot water generation etc though). Am 31.07.2017 um 09:07 schrieb SwiftFast: > The word "solar" alone is a synonym for "Diesel Fuel" in some countries > and can cause confusion. I'd advise using solar_equipment or >

Re: [Tagging] Beautified JSON presets for natural=tree

On 22.07.2017 20:28, Dave Swarthout wrote: > ... > > Can you expand and clarify your comment for me? > > Just as I wrote, and nothing that I invented, it is considered a) good practice to tag source on the changeset. Which in turn implies that if you are using more than one third party data

Re: [Tagging] Beautified JSON presets for natural=tree

On 22.07.2017 16:35, Pander wrote: > Rarely used tags also take up valuable space in apps such as Vespucci. > Just to clarify: optional tags are, as the name says, optional and do not use screen real estate except if already in use, or explicitly added

Re: [Tagging] OSM+Wikidata intro video

Am 15.06.2017 um 22:02 schrieb Yuri Astrakhan: > Sorry for the delay - I have updated the license on the license page > to point to ODbL and OSM -- http://88.99.164.208/wikidata/copyright.html > > This service is still looking for a proper home. If you have an extra > 700GB of space on a server,

[Tagging] shop=appliance vs. shop=electronics

And another one from the ragged edge of tagging. iD has a preset for shop=appliance http://wiki.openstreetmap.org/wiki/Proposed_features/Appliance_Store , I assume for shops that sell larger electrical goods washing machines, dryers, fridges and so on (in German so called  "weisse Ware"). It

Re: [Tagging] Fwd: How to map a bin with dog excrement bags dispenser

I agree with this, bin=yes is already a well established attribute tag and for the typical combined dispenser/bins that you see here (1000s of them) it would seem to be the most correct tagging. Naturally there are other set-ups with separate bins potentially simply nearby, they should obviously

Re: [Tagging] shop=fashion

I'm afraid we would start running out of usable words real fast if we could only use those with non-confusing meanings in their original and other languages (maybe Kindergarten, oh perhaps rather not :-)). Seriously the term boutique is so firmly anchored in the English language that doing away

Re: [Tagging] shop=fashion

Am 30.08.2017 um 10:01 schrieb Marc Gemis: > It would be nice if shop=boutique would show an icon with clothes or > something similar instead of a dot on the default osm-style. So people > would see they made a mistake. Not only that.  Any translations and the like should (naturally) give a

Re: [Tagging] shop=fashion

Sorry that was wrong, JOSM uses "Haute Couture" Am 30.08.2017 um 11:05 schrieb Simon Poole: > > Translations for shop=boutique > > iD: Petit magasin de mode > > JOSM: Boutique > > > Simon > > PS: vespucci didn't h

Re: [Tagging] shop=fashion

Translations for shop=boutique iD: Petit magasin de mode JOSM: Boutique Simon PS: vespucci didn't have a translation, now it is the same as iD signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] shop=fashion

The other place where shop=boutique was translated to Boutique was on the OSM website, fixed that too. Am 30.08.2017 um 11:09 schrieb Simon Poole: > > Sorry that was wrong, JOSM uses "Haute Couture" > > > Am 30.08.2017 um 11:05 schrieb Simon Poole: >> >> Tr

[Tagging] shop=fashion

Working on this issue https://github.com/simonpoole/beautified-JOSM-preset/issues/27 the question turned up if shop=fashion (with 5000 something uses) should not be deprecated (==not offered for new use) due to overlap with shop=boutique (~11'000 uses) and shop=clothes, clothes=fashion (not

Re: [Tagging] shop=fashion

> > On 26. Aug 2017, at 11:15, Simon Poole <si...@poole.ch > <mailto:si...@poole.ch>> wrote: > >> the question turned up if shop=fashion (with 5000 something uses) >> should not be deprecated (==not offered for new use) due to overlap with >> shop=boutiq

Re: [Tagging] shop=fashion

new shop type > or decide whether it's MORE one type of shop (bicycle vs. motorcycle > vs. car or similar) > in case they offer very various things. > > Cheers, > Thilo > > > Am 26.08.2017 um 13:13 schrieb Martin Koppenhoefer: >> >> >> sent from a p

Re: [Tagging] Tagging data where position is not yet known

Not quie sure why this is on tagging, but anyway: a clear yes to adding the data. Add a FIXME tag stating that it is a rough, village level position for late surveyors and consumers. Naturally you might simply be able to sit down with the contributors and squint at aerial imagery to locate the

Re: [Tagging] Road barrier

In general the access categories and rules for "traffic at rest" are different, than for moving traffic. As to sign C, 3a (Vienna convention), the OSM access wiki page is a bit unclear in that it doesn't clearly state that when used in a prohibitory fashion "motorcar" includes all other dual

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

A large number of landuse=village_green seem to be due to an import in the Czech Republic, where is has been used for essentially any grassy area. Lots of the leisure=common seem to be actually be leisure=park with the exception of the HOT helicopter "landing areas".  I would suggest that maybe

Re: [Tagging] New tag for major recipient postcodes

Am 17.12.2017 um 21:22 schrieb Warin: > As they are not related to a physical address then why use the address > space? The addr tag space is for postal addresses, that are not guaranteed to be physical at all (for example addr:city is the postal city, which might be completely un-surveyable).

Re: [Tagging] Feature proposal - Voting - Education Reform

You numbers look slightly off, wit: https://taginfo.openstreetmap.org/tags/amenity=childcare Am 18.11.2017 um 19:05 schrieb Erkin Alp Güney: > I am offering this proposal into voting as no replies arrived since last > month. > > Yours, faithfully > Erkin Alp > > >

Re: [Tagging] Feature proposal - Voting - Education Reform

[Christoph pressed send before I did, sigh] While I'm a bit undecided on if we need an education reform at all and you need to make clear what the voting is actually on, the underlying proposal is far from ready for any kind of vote or usage at this point in time. You need to at least provide a

[Tagging] Replacing POIs with landuse

Maybe some will want to weigh in on the discussion of the obvious trend: https://github.com/simonpoole/beautified-JOSM-preset/issues/27#issuecomment-341898723 signature.asc Description: OpenPGP digital signature ___ Tagging mailing list

Re: [Tagging] Retag: craft=sweep => craft=chimney_sweep

The aftermath of the (IMHO very unnecessary) change: https://github.com/openstreetmap/iD/pull/4504#issuecomment-341980655 We now have - 62 chimney_sweeper - 36 sweep - 1 chimney_sweep and one confused chimney sweep Am 04.10.2014 um 20:39 schrieb John F. Eldredge: > Chimney sweeps still

Re: [Tagging] brand=* necessary?

On top of all what has already been said, what you -should- be doing (after discussion) is adding the tags to https://github.com/osmlab/name-suggestion-index instead of embarking on a lone crusade to show everybody the light. It can be argued that the name suggestion index it is a bit at odds

Re: [Tagging] tagging of one-way cycle lanes

Am 11.05.2018 um 17:40 schrieb Paul Johnson: > > Why the almost religious doctrine level of resistance to change?  Even > the Linux kernel rewrites entire subsystems from time to time when a > superior approach comes around. > Try to change the semantics of an existing LINUX system call (which

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

Just as a further data point, we had this discussion in 2016 here http://lists.openstreetmap.ch/pipermail/talk-ch/2016-October/003827.html Am 20.05.2018 um 10:38 schrieb Selfish Seahorse: > On 19 May 2018 at 21:20, Martin Koppenhoefer wrote: >> route=walking_bus? >>

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

Am 08.06.2018 um 11:53 schrieb marc marc: > Le 08. 06. 18 à 11:34, Rory McCann a écrit : >> Replicate data from OSM, applying your data transformation programme > it's already what nearly all use of osm is doing. > it's named "preprocessor" or alias > it's waste that nearly all data use need to

Re: [Tagging] I can't support transit:lanes

Just as Bryan does, I can see supporting special casing transit relations (as we already have to do the same for turn restrictions). I am -very- reluctant to support one-off tag semantics that require special code to handle them. Note with respect to the parallel discussion on tagging

Re: [Tagging] I can't support transit:lanes

Am 11.06.2018 um 17:19 schrieb osm.tagg...@thorsten.engler.id.au: > > *From:*Bryan Housel > *Sent:* Tuesday, 12 June 2018 01:12 > *To:* osm-tagging > *Subject:* Re: [Tagging] I can't support transit:lanes > >   > > I’ve already written plenty of code to deal with turn restrictions. >  There

Re: [Tagging] emergency=first_aid_kit

If I may say so the page seems a bit weird. Name on a first aid kit? Draw an area around the shop outline? Assuming that are simply C errors, I'll fix things in nobody has any objections. Simon Am 20.06.2018 um 19:31 schrieb Bryan Housel: > Just following up after a week - there wasn’t any

Re: [Tagging] emergency=first_aid_kit

bably be a feature that sits on points only (like > `emergency=defibrillator`) - the “shop outline” stuff doesn’t make sense. > > Thanks, Bryan > > > >> On Jun 20, 2018, at 1:46 PM, Simon Poole > <mailto:si...@poole.ch>> wrote: >> >> Not to mention fir

Re: [Tagging] iD presets

Just a couple of comments: - both the JOSM and Vespucci default presets are in general under a lot less pressure and in the end less scrutiny than iDs because they are end user replaceable and extendable. Naturally the choices made by the devs still affect tagging, including, oops, errors. - I

Re: [Tagging] emergency=first_aid_kit

Not to mention first_aid vs first_aid_kit what it is supposed to be now? Am 20.06.2018 um 19:40 schrieb Simon Poole: > > If I may say so the page seems a bit weird. > > Name on a first aid kit? Draw an area around the shop outline? > > Assuming that are simply C errors, I'll fi

Re: [Tagging] Multiple offices at the same address - (Multiple values for one key)

IMHO three nodes is the solution, add level tags if they are not on the same floor. If the address was on the building polygon duplicating the address information on the POI would not be necessary, but knowing Dutch numbering schemes, that likely doesn't make sense. I consider this problem

Re: [Tagging] Nonbreakable spaces in name tags

IMHO we should in general treat all unicode space variants as a nomal ASCII space for processing and comparision purposes and leave it at that. And we don't have the issues just in name tags, see SKIP : {   "\r" | "\n" | " " | "\t" | "\u200A" | "\u2009" | "\u00A0" | "\u2008" | "\u2002" |

Re: [Tagging] Nonbreakable spaces in name tags

Am 31.01.2018 um 19:33 schrieb Simon Poole: > IMHO we should in general treat all unicode space variants as a nomal that should have been "normal" signature.asc Description: OpenPGP digital signature ___ Tagging mailing

Re: [Tagging] Lane geometry in OSM

Am 03.08.2018 um 16:30 schrieb djakk djakk: > I think it is less verbose.  > That isn't necessarily a positive (just as in programming languages). > There can be multiple ways to express something in osm, like in the > Ruby language ? > While that is certainly the case in OSM, introducing

Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

Am 10.08.2018 um 20:19 schrieb Paul Allen: > Because if I'm in > a strange location, looking at a map that labels a street "Foo Lane" > that's what I expect to see on the sign.  Anything > else is misleading and unhelpful. Couldn't agree more. Note: we do have "official_name" for

Re: [Tagging] Tagging request: missing admin_level tags

I would have to second this observation, this would seem to go exactly against what we've tried to fix with multi-polygons (not to mention a future area object type). Not to mention that a single way can be a member of multiple different borders at different admin levels, so this would seem to be

Re: [Tagging] wetap specific tags

Am 23.03.2018 um 14:37 schrieb Volker Schmidt: > No, obviously, not in the sense that we do that systematically, but > the problem exists in real terms. Drinking water is in many places of > the world one of hose pieces of information that would be nice to be > able to tag: have been here today,

Re: [Tagging] iD presets

Btw, I've done some work on automatically generating presets from taginfo in Vespucci 11 (going further than what iD does), and if you so will the ultimate democratic presets, that I'll likely be touching on too. Simon Am 20.06.2018 um 11:41 schrieb Simon Poole: > > Just a couple of co

Re: [Tagging] Opening hours too long for OSM

Am 12.10.2018 um 18:37 schrieb Frederik Ramm: > Hi, > > On 10/12/2018 12:54 PM, Tobias Knerr wrote: >> I agree that this problem calls for a general solution, as it's not >> specific to opening hours. > ... > > Or can we afford to just skip mapping that detail? > It is all fine and dandy for us

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] Opening hours too long for OSM

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 which should be tackled with a general solution. One would

  1   2   3   >