On Mon, 2020-09-07 at 23:23 +0200, Martin Koppenhoefer wrote:
> If the whole building is tagged as building=terrace then its parts
> should not get again a building=* tag, rather use building:part=*
Having one building and multiple building:parts also improves vector
map performance. I know we
On Wed, 2020-08-26 at 09:58 +0200, Thibault Molleman wrote:
> That's a good idea actually!
> Although I guess there is a part of me that thinks that having just a
> simple image tag without any fancy stuff is still best for a primary
> image (so that apps that want to implement it don't need to
As mentioned semi colon has issues with URLs. It may also be worth
noting that a OSM value can only have 254 chars in it, a limit that
would get hit quickly with a few URLs.
I've thought about this before, I think we need 1 URL to point to
multiple images. But it can't just be a non standard HTML
> Not exactly a very user-friendly system though, especially if you're
> only trying to review requested changes?
> & with somewhere between 300k - 600k changes sitting there to look
> at, I don't think the chances are all that high that somebody will
> spot any errors!
On the face of it I
On Sat, 2020-08-22 at 09:32 +0200, pangoSE wrote:
> Building upon it can lead to strange things. E.g.
> (building:levels=212 was entered erroneously and committed to the
> database without any kind of QA
On Sat, 2020-07-25 at 16:42 +0200, Tobias Zwick wrote:
> If the date + *source* of the last change made on (the geometry of
> an) element was readily available, through the API or another meta-
> tag (source=bing, anyone? ;-) ), this would help to identify areas
> that should be updated because a
On Fri, 2020-07-24 at 17:48 -0500, Shawn K. Quinn wrote:
> On 7/24/20 17:20, Cj Malone wrote:
> > Alternatively if each storing when each tag has been validated is a
> > direction OSM wants to go, maybe it should be in the API. A client
> > like
> > StreetComplete coul
On Fri, 2020-07-24 at 16:13 +0100, Jez Nicholson wrote:
> There must have been a long discussion on this, and I don't want to
> rehash it, but i'm surprised there was a positive response to adding
> check_date for individual attributesI can understand a check_date
> for a whole feature (as
On Sat, 2020-06-27 at 17:15 +0100, Paul Allen wrote:
> On Sat, 27 Jun 2020 at 17:03, 德泉 談 via Tagging
> > In previous discussion we haven’t clarify that “cafe” is a place
> > serving coffee drinks
> > or
> > a place providing seat for the consumer to have
> > something like coffee or
On Thu, 2020-06-25 at 22:14 +0200, Martin Koppenhoefer wrote:
> Btw, there are also a few images tagged with a “flickr” key (~1200)
> While it could eventually make sense to make an exception for
> wikimedia commons, I do not believe we should create a new key for
> every image hosting service.
It's in Facebooks interest to have OSM be the best it possibly can.
Facebook doesn't want to be dependant on Google for map data, so they
are going to try and commoditise map data to improve competition.
Google just released Google Maps SDK for Unity, an API for app
developers to make Pokemon Go
On Mon, 2020-05-11 at 03:27 +0200, Mateusz Konieczny via Tagging wrote:
> May 11, 2020, 02:36 by cjmal...@mail.com:
> > On Sun, 2020-05-10 at 23:07 +0100, Paul Allen wrote:
> > > > and gradually deprecating the generic tags.
> > >
> > > And there you go, wanting to get rid of phone=* and
On Mon, 2020-05-11 at 02:10 +0100, Paul Allen wrote:
> And yet you, and others, keep saying it. "Deprecate" means "express
> disapproval of." In the context of OSM, it means "phase out." That
> eradicate with the passage of time. It may not be what you mean, but
> it's what you keep
On Sun, 2020-05-10 at 23:07 +0100, Paul Allen wrote:
> But that's what they often imply.
I don't know if this is worth saying or not, but this isn't a war,
there aren't sides. We all just want OSM to be the best it can be.
I am fairly new to OSM, especially the mailing lists but I guess you
On Sun, 2020-05-10 at 22:28 +0100, Paul Allen wrote:
> We can't replace phone with contact:phone in all cases, as some wish
> to do, because of phone boxes. We can't replace website with
> contact:website in all cases, as some wish to do, because there are a
> lot of POIs with websites or URLs
> But not all of them are necessarily contacts. I've added URLs for
> historic buildings that give more information about the
> building. There is nobody to talk to about it. I've added websites
> for companies; there is a contact page on that website but the URL
> I've given is for the company
Mail list logo