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
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
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
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.
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,
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.
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
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
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
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
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
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
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
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
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
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
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:
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
-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
-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
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
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
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
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
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
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
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
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
>
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 ...
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
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),
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
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
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
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,
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"
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>>
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
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
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
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
>
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
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
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,
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
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
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
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
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
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
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
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
>
> 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
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
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
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
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
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).
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
>
>
>
[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
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
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
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
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
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?
>>
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
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
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
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
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
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
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
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
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"
|
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
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
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
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
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,
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
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
.
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
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 - 100 of 202 matches
Mail list logo