Re: [Tagging] Mapillary V3 to V4 migration, image-key
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
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
Re: [Tagging] Tagging of individual terraced houses?
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
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
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 !)
> 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 !)
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
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
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
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
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
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
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
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
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
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
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
> 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
