Re: [Tagging] Tagging of individual terraced houses?

2020-09-08 Thread Cj Malone
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 don't map to the renderer but it's a nice
side affect.

Cj



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging multiple images on one object

2020-08-26 Thread Cj Malone
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 start
> messing with this new format and can just load that simple url.

The beauty of HTTP Accept is that both the server and the client can
fall back gracefully.

If a client only supports receiving jpg images, the server would send
the primary image, if it only supports HTML it would send a HTML page
with the images embedded. If it supports our gallery format it would
get them all. One URL, multiple responses.

So if we had a POI with image=
https://image-host-1.example/images?id=123456 and you opened that in a
web browser (that wouldn't support a native gallery format) it would
send something like "Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=
0.8". The server knows that the browser doesn't support the gallery
format and prefers text/html application/xhtml+xml image/webp,
then application/xml, then anything else (*/*), in that order.
The server would respond with a HTML page that shows all the images.

With something that supported the gallery format to would send,
"Accept: application/gallery+json,image/*;q=0.9,text/html;q=0.8". Then
if the server understands the gallery format it would reply with all
the images and metadata. If the server didn't understand that mime type
it would respond with a image, or HTML.

This problem isn't just an OSM one, and this solution isn't really
related to OSM. But it does mean OSM isn't locked to a single image
provider like Wikimedia Commons.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging multiple images on one object

2020-08-26 Thread Cj Malone
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 gallery, it
also needs to be programmatically fetchable so downstream OSM consumers
can use the images directly.

HTTP already has the capability for this with the Accept header.

- If a given URL is loaded in a browser (Accept: text/html) it can show
a HTML page with multiple images in.

- If it's requested by a client like OsmAnd (eg Accept:
application/gallery+json) it could return a JSON blob with details
about the images, there licences, alt text, etc to be embedded in the
app.

But we'd need server support.

Cj



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-23 Thread Cj Malone
> 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 agree, it's a non obvious system and and reviewing
changesets should be encouraged more. I would consider myself an
advanced mapper now, and I've never reviewed a changeset. I never even
knew how to.

However as an anecdote, the current system seems to work, when I
requested a review of my first 3D building I not only got one, but it
got fixed. [1] [2]

Cj

[1] https://www.openstreetmap.org/changeset/70583513
[2] https://www.openstreetmap.org/changeset/70610688


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-22 Thread Cj Malone
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 follow-up. If someone knows the
> osmid I would like to know how long this error was present in OSM)

https://www.openstreetmap.org/way/712475718/history

1 - It was introduced by a novice mapper, presumably as a typeo.

2 - Nikolas von Randow fixed it about 9 months later, presumably with
some kind of QA tool (maybe just a overpass query).

3 - Another local novice mapper also edited it, and fixed another issue
at the same time. Presumably noticed via a rendered map.


Before criticising the mapper, it should be noted that it was a novice
mapper and the existing building data in the area isn't of great
quality anyway. This wasn't a regression. And accidents happen anyway,
I've done a similar thing via StreetComplete where I entered the house
number in the building levels quest.

The big companies doing QA on OSM data (Mapbox and Facebook) have a
high focus on vandalism. They are trying to stop "Jewtropolis" from
ever happening again.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-26 Thread Cj Malone
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 new more current and/or detailed
> source became available.
> 
> In Hamburg, we are lucky that the public authority provides us with
> really detailed up-to-date satellite imagery that are far beyond bing
> but there is no easy way to see which buildings and road geometries
> have still been mapped on the basis of bing and which are already
> using the better source.
> 
> So in a nutshell, the topic of how to find things based on old
> sources is also very relevant for remote mappers.

Technically there is survey:date and source:date that may be on the
object, or (preferred now?) the changeset. So a quality assurance tool
could check that, however in practice they aren't nearly in use enough,
(editors using them by default would help), and there often isn't a
date attached to satellite imagery.

I also think they'd have to do multiple api calls to work it out, so it
could definitely be streamlined with a new api endpoint.

Cj


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-24 Thread Cj Malone
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 could "touch" a tag to rev it's edited timestamp
> > without
> > actually changing the value.
> 
> OSM does not store edit timestamps for individual tags, only for the
> object as a whole. Finding out when a tag was changed requires a
> review of the entire history. I had to do this once when I saw a
> clear highway=motorway_link tagged as highway=motorway, with me as
> the last user to edit that road segment. Turns out the original
> mapper was the one to make the tagging mistake, not yours truly, but
> I only found this once reviewing the history.


Yeah, that option would require a new API and work done on the OSM
server to both calculate the last time a tag was edited, serve it and
store the timestamp when "touched" or updated. But once that's done
it's done for multiple clients, not just StreetComplete.

Otherwise StreetComplete would need to use the History API one each
individual nwr and try to calculate the age of a tag.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-24 Thread Cj Malone
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 with the construction site), so for example a
> bus stop, I might be asked to check all the attributes (is there a
> seat? is there a bin? is there still a shelter?) and flag the whole
> bus stop as 'checked'.
> Could StreetComplete quests be built for confirming all attributes of
> an object, or are they limited to one (and hence your need to flag
> individual attribute checked dates)?

+1

Doubling (or near enough) the amount of tags on a given nwr seems a bit
excessive. StreetComplete could do a kind of wizard where is shows each
tag and asks the user to validate it, and only once all the tags are
shown to the user is an nwr considered confirmed, and adds a tag to say
it was surveyed or checked.

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 could "touch" a tag to rev it's edited timestamp without
actually changing the value.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] 回覆﹕ Re: Feature Proposal - RFC - shop=bubble_tea

2020-06-27 Thread Cj Malone
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 donut.
> > 
> 
> In British English, that is exactly the meaning of cafe

Which one? That sentence has an "or" in it.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Automated edit of image tags suggestion

2020-06-26 Thread Cj Malone
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.

+1

I don't think `flickr` should be separate, if images in OSM are going
to be in multiple tags I think it should be based on the fetching
method. `flickr` is a standard URL, that the UserAgent sends a standard
HTTP request and gets a standard HTML response. That should be the
`image` tag. I think I'd argue the same for `mapillary` even though
they aren't currently stored as standard URLs, the rest is the same.

UserAgents that support it could then decide based on the URL if there
is an alternate way to fetch the images, like the Mapillary API and
easily fallback to a link when it doesn't.

There is another issue with `image` and that's that the UserAgent
doesn't know if it's going to receive a single raw image (eg image/png,
image/jpg), or a single image wrapped in HTML, or multiple images
wrapped in HTML. I've got an idea on how to solve this, using
the Accept HTTP header, but that relies on the image servers so I doubt
it'd get much traction.

Cj



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Adding mapillary tags to every building

2020-06-19 Thread Cj Malone
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 type games. OSM can't compete on that
kind of ease of development. I think Facebook will come out with
similar APIs to try and stop Google growing it's map data market share.

This is the iOS vs Android fight, except Google is Apple and Facebook
is Google. Competition is a good thing.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-10 Thread Cj Malone
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 website=*.
> >
> > I think I stand by that quote, but I'm happy to discus it. I'm not
> > arguing that over night we should stop people using the phone tag.
>
> But "gradually deprecating" means that this tags will be eliminated,
> what seems to me to have the same meaning as "wanting to get rid of".
>
> Whatever it will done in 24 hours or 24 years is not changing that
> goal
> of tag deprecation is to utterly eliminate it.

I don't hate the phone tag because if it's name and want to fight
everyone so they have to type contact:phone because I want to utterly
eliminate phone. That's silly.

The goal is quantifiable and usable data.

If the end of this discussion is explicit tags for edge cases, and
phone only used for the contact phone number that's fine by me. Sure it
might look better with a contact: namespace and be easier to describe,
but that doesn't matter. It's the definitions that do.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-10 Thread Cj Malone
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 saying.

Any yet what I described was a phase out with 3 steps.

> Replacing tags isn't easy.  There is inertia from various parties
> involved.
> Carto has a rule of "no aliases."  Which means that however
> compelling
> you feel that replacing a=b with x=y is a good idea, they'll almost
> certainly
> reject it because "no aliases."  The editor people have their own
> foibles, too,
> but they're more likely to decide they don't like a=b or x=y and go
> with
> p=q.

I thought this mailing list was the official avenue for disusing,
changing and adding tags in OSM. I didn't realise you had to get the
editor permission.

> Oh, and there's all the legacy usage you have to clean up, except
> we don't like automated edits.  But without cleaning it up, you make
> database queries more complex.

I don't have any arguments against automated edits, bulk edits, machine
assisted edits. In any dataset they are needed, especially one this
massive. But it's not a fight I have the effort to fight right now.

> I am far from convinced that a contact phone number is not a phone
> number.
> If I see a phone=* on a phone box I know it is not a contact number.
> If
> I see a phone=* on a business I know it's a contact phone number for
> the business.  What extra utility does having contact:phone provide?
> And is it worth the hassle of manually editing all the existing tags
> to
> fix?

That's just one edge case with the phone tag. Another one being phone
on parking. Is that the number you call to pay, or is it the number you
call to contact the operator because there is something wrong.
¯\_(ツ)_/¯ who knows.

I believe there are more edge cases we still aren't thinking of, and if
we aren't the user agents defiantly aren't.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-10 Thread Cj Malone
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 coming from a point of view like "They are coming for the phone tag
again". I'm not, I wasn't part of any previous discussions on the phone
tag or contact namespace. I just want to help improve OSM, any way that
I can.

If you are a little annoyed because you've had this discussion multiple
times that just means it's a hot topic for people and discussions will
help everyone understand all the other opinions.

> > and gradually deprecating the generic tags.
>
> And there you go, wanting to get rid of phone=* and website=*.

I think I stand by that quote, but I'm happy to discus it. I'm not
arguing that over night we should stop people using the phone tag.
Currently phone has at least 2 uses. A contact number and an incoming
number for a phone box. We should split these out. If we are left with
totally_new_tag_for_phoneboxes and phone, where
totally_new_tag_for_phoneboxes is defined as incoming phone number and
phone is defined as the contact number. I'm OK with that too, it's the
definitions that really matter.

As this conversation has gone on, I now believe that contact:phone and
phone are separate things. As such I believe phone is massively misused
as a contact number and so should actually be contact:phone. Lets
gradually move people away from this.

- We can start with documenting the differences between the tags on the
Wiki.
- Lets get the editors to push mappers use the accurate tag, is this a
contact number, or another form of number.
- And then lets start informing OSM maintainers about the ambiguous use
of phone and give warnings to use a more quantified tag.

The above 2 paragraphs might be easier to think of context of website
and contact:website. I have previously misused them, I have been adding
contact:website that are web pages for the specific store, but just
have a contact number and address. That's not a contact method and so
doesn't belong in contact:website.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-10 Thread Cj Malone
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 that are not contacts.  As long as
> this is understood, I don't have a problem with contact:phone and
> contact:website.  If, however, people insist on replacing phone and
> website completely, then I will not be happy.

I agree, not all phone tags convert to contact:phone, same with the
others. I don't think anybody is talking about a mass edit of the
database.

I think we should actively encourage more precise tags like
contact:phone when it's a contact number. We can do that through the
wiki, and defaults in the editors, and gradually deprecating the
generic tags.

During the transition to more quantified data we will see edge cases
like public phone boxes, and others we don't yet know about, and we
should discus new tags for them.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-10 Thread Cj Malone
> 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 website as a whole.

Surely that's an argument for new tags as well as contact:website, for
example description:website where a user agent could give users a "Read
more" link. A website tag is generic, which has the obvious benefit of
used widely and easily, but more precise tags like contact:website give
user agents much more flexibility.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging