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
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
are
> 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
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
> is,
> eradicate with the passage of time. It may not be what you mean, but
> it's what you keep
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-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
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
On Sat, 2020-08-22 at 09:32 +0200, pangoSE wrote:
> Building upon it can lead to strange things. E.g.
> https://www.nyteknik.se/popularteknik/mystisk-jatteskrapa-dok-upp-i-flygsimulator-6999771
> (building:levels=212 was entered erroneously and committed to the
> database without any kind of QA
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
> 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
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 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.
On Sat, 2020-06-27 at 17:15 +0100, Paul Allen wrote:
> On Sat, 27 Jun 2020 at 17:03, 德泉 談 via Tagging
> wrote:
>
> > 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 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 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 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 Mon, 2023-04-10 at 20:21 +0100, Cj Malone wrote:
> We couldn't expect every consumer
> to do the same cleaning.
That's a typeo, I meant shouldn't. I'm sure some people would argue we
could expect every consumer to do the same work, but IMO we shouldn'
On Sun, 2023-04-09 at 19:53 +0200, Kai Michael Poppe - OpenStreetMap
wrote:
> Good evening and happy easter to those celebrating!
>
> After a ton of work and being yelled at for making too many
> changesets,
> making too many changes, making too few changes, not discussing the
> automated edit
18 matches
Mail list logo