Re: [Tagging] Mapillary V3 to V4 migration, image-key

[Cj Malone]

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't.

CJ


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

Re: [Tagging] Mapillary V3 to V4 migration, image-key

[Cj Malone]

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 properly (?!?) and being accused of working for
> Mapillary 
> or OSMand because why else would I even bother (clearly someone
> didn't 
> read the initial rationale), there are now 246.7k valid new API keys
> in 
> the "mapillary" key,

Thank you for your hard work, hard work doing it and hard work
explaining yourself multiple times. This has improved OSM, and I am
grateful for all the effort put into this.


> ** Proposed edit **
> 
> 1)
> 
> 2)
> 
> 3)
> 
> 4)
> 

These all seem reasonable to me. Thank you.

> 
> ** Note **
> 
> As mentioned in [2] as well, objects that link to specific x,y,zoom
> URIs 
> will not be touched. As those are mostly 360° photos where people
> wanted 
> to show an exact point in the image, linking the numeric ID alone 
> wouldn't satisfy the mappers that used that image in the first place.
> 

This seems like a safe option for now, I support it, but maybe long
term there would be a way to encode that in the `mapillary` tag?


> ** Rationale **
> 
> Removing dead links from the image-key sounds like a no-brainer to
> me, 
> even though it might not be with the URI being unavailable
> temporarily. 
> In this case, direct thumbnails are never coming back.
> 
> For non-dead links (i.e. those leading to the mapillary website-
> "app") 
> everything (primarily the wiki page of the image-key [3]) yells at
> me, 
> that the ID should be stored in the appropriate key.
> 

This sort of data clean isn't glamorous, but we need to do it. We need
to do it because it's the right thing to do, we need to do it to make
OSM data consumers lives easier, we need to do it as "PR" we don't want
people put off because we have "dirty" fields.

I just heard that a OSM consumer throws away every `addr:country` and
compute them because x% are invalid. We couldn't expect every consumer
to do the same cleaning.

> **
> 
> PLEASE provide feedback. I hate being shouted at for trying to
> support 
> the community (remember: the reason this came up was an app developer
> who couldn't use the mapillary API v4 with the old keys anymore!).
> 
> Thanks a bunch!
> 

Again, thanks for your work. This is greatly appreciated.

CJ


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

[Tagging] Mapillary V3 to V4 migration, image-key

[Kai Michael Poppe - OpenStreetMap]

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 properly (?!?) and being accused of working for Mapillary 
or OSMand because why else would I even bother (clearly someone didn't 
read the initial rationale), there are now 246.7k valid new API keys in 
the "mapillary" key, with only 7.2k "old" keys left that could not be 
matched to a new existing image, because they have either been deleted 
by the user or where invalid to start with (lower case instead of upper 
case character or something).


I haven't updated the Wiki Page [1] yet, the Community post [2] has some 
more up-to-date info while I was working on the subject.


** This mail is to ask for comments on editing the "image"-key as well. **

Stats: There are around 14.9k objects in the planet file where the regex 
"image"~".*mapillary\.com.*" matches, of which 11.1k also contain 
"thumb" after that. In that case people used the "old" way of linking to 
a thumbnail-image on mapillary, which no longer exists. 10.6k objects 
_also_ have a "mapillary" that is purely numeric - i.e. has been changed 
by the automated edit already and is therefore known to be a correct ID.


** Proposed edit **

1)

(way/194649358) 
image=https://images.mapillary.com/za85be97UcMzVuaPCMZQVQ/thumb-2048.jpg, 
mapillary=207683754228814 



=> image entry leads to same mapillary id, that already exists.
=> Action: remove image-entry because there are no thumbnails available 
anymore.
=> That's one of the 10.6k objects, so the highest amount of objects to 
edit.


2)

(node/5919376334) 
image=https://www.mapillary.com/app/?lat=52.626783214558486=-0.9952875506141936=17=MfEfU0jdHULiSROiCvl0Wg, 
mapillary=MfEfU0jdHULiSROiCvl0Wg


=> image entry is the website link which could also easily be generated 
from the mapillary entry

=> [ask myself why the id wasn't caught as a conversion candidate before]
=> Action: remove image-entry and update correct mapillary id

3)

(node/5140643074) 
image=https://www.mapillary.com/app/?lat=54.04169080554=9.20179652777=17=3YFedo4Ys-k0ThQM8LZgOQ=photo 
, 
mapillary key non-existent
(node/3762262144) 
image=https://www.mapillary.com/map/im/O8OS2R0tVfNEaFyZcFsesQ/photo, 
mapillary key non-existent


=> image entry is the website link which could also easily be generated 
from the mapillary entry

=> Action: remove image-entry and add correct mapillary id

4)

(node/9425856002) image=https://www.mapillary.com/app/?pKey=134015699048525

=> image entry is the website link which could also easily be generated 
from the mapillary entry
=> Action: remove image-entry and move the already correct new id to the 
mapillary key


** Note **

As mentioned in [2] as well, objects that link to specific x,y,zoom URIs 
will not be touched. As those are mostly 360° photos where people wanted 
to show an exact point in the image, linking the numeric ID alone 
wouldn't satisfy the mappers that used that image in the first place.


** Rationale **

Removing dead links from the image-key sounds like a no-brainer to me, 
even though it might not be with the URI being unavailable temporarily. 
In this case, direct thumbnails are never coming back.


For non-dead links (i.e. those leading to the mapillary website-"app") 
everything (primarily the wiki page of the image-key [3]) yells at me, 
that the ID should be stored in the appropriate key.


**

PLEASE provide feedback. I hate being shouted at for trying to support 
the community (remember: the reason this came up was an app developer 
who couldn't use the mapillary API v4 with the old keys anymore!).


Thanks a bunch!

Kai

**

[1] 
https://wiki.openstreetmap.org/wiki/User:Kmpoppe/Automated_Edits/Mapillary_Update


[2] 
https://community.openstreetmap.org/t/begin-of-automated-edit-for-mapillary-key/3426


[3] https://wiki.openstreetmap.org/wiki/Key:image#Usage
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging