9_tab's Comments
| Changeset | When | Comment |
|---|---|---|
| 164113191 | node/14014504302/history/1 showed up since, but maybe the report is just too strict. BTW Shouldn't it be Mo-Fr ? |
|
| 186225542 | changeset/186225542 Please delete way/1185891197 if that is gone too. |
|
| 186198813 | It looks more like personal annotations, possibly not even meant for publication here. That could explain the edit summary too. |
|
| 181903951 | > No worries, correcting these typos is easy :) Agree, even if it seems it isn't always welcome. Some even get annoyed if the pragmatic imperfection of our approach gets pointed out to a random (most recent) mapper by OSMOSE ;) > I thinks it's counter-productive to add many (different) `ref`s (of any kind) to objects in OSM. Honestly, I think that a better place for these is Wikidata, and the link to them on the OSM side should be the Wikidata ID. We quickly discussed this in the Swiss IRC channel, but haven't really figured out a plan. My idea is to deprecate *all* the `swisstopo:*=*` IDs in Switzerland and only keep `ref:ch:bfs` on the boundary relations to keep the matching working in boundaries.osm.ch. Some mappers who are more experienced than me might prefer to deprecate the "swisstopo:*"-ones before actually removing them. The problem with ref:ch:bfs (compared to ref:CH:bfs:HISTID=* ) is that the border are those of a given HISTID and not of a BFS municipality number. It can lead to confusion when the same BFS municipality number is applied to multiple OSM features or merger/split aren't applied immediately. A possible alternative could be swisstopo:SHN=* but as Swisstopo's borders get adapted when added to OSM, it would be more suitable as a source:-tag. A general problem with adding only to Wikidata is that it adds another source of discrepancy: be it errors or many-to-1 or 1-to-many matches. In general, the swisstopo:*=* tags are less problematic than openGeoDB-tags. I find those on OSM-features where I don't think they should be, but people might prefer them for historic reasons (database history). |
|
| 185832019 | There is no standard key for this website. And the website is "booking.com". Please don't do such changes. |
|
| 183419844 | Good to hear: at least we agree on the mapping. Happy Mapping. |
|
| 185832019 | I think you made an error here. What did you try to "correct" |
|
| 177397664 | It's about way/1468117950 it seems. Names should be in name tags, not "note" |
|
| 183419844 | @DWG: Please send me by internal message the relations that need fixing. Thanks. |
|
| 184515411 | Thanks for the following-up on this, Can. Above I had asked where on the wiki page you read a definition or description of the practice of your editing team, but didn't get an answer. I think you should update the wiki if you think my interpretation diverges from the practice you follow. Also, as this is part of a coordinated effort, I think OSMF wants you to draft a page outlining what you plan to do. Maybe @d_berger wants to add some points. |
|
| 185498300 | Read: note/5386910 |
|
| 184854060 | In changeset/185391619 you might have had problems with already existing descriptions. Is that why there aren't any on the others? |
|
| 164113191 | You might want to go through all cantons at https://opening-hours.pages.dev/schweiz-suisse-svizzera-svizra/ and check the defibrillators. There is an option "apply fix" (if possible) that allows you to correct them and then upload for that canton. |
|
| 185342741 | About building:levels:names:equivalent=* see for the general question: osm.wiki/Talk:Key:building:levels#Names_of_levels Sometimes it's not obvious what the equivalent is and one might not know all building levels and their ref. So building:levels:ref:equivalent=* can help. I'd prefer this over note:building:levels:ref=* |
|
| 164113191 | https://opening-hours.pages.dev/schweiz-suisse-svizzera-svizra/gen%C3%A8ve has quite a few
|
|
| 111105269 | A recent report https://opening-hours.pages.dev/schweiz-suisse-svizzera-svizra/gen%C3%A8ve has quite a few
|
|
| 185342741 | Great, I was looking for tags for that, but didn't see those. When changing tags here, it would be good to keep the wiki in sync. The wiki has it that building:level=* is deprecated. So maybe it should be building:levels:ref=* ? As "note" invites freeform and is meant for mappers, I'd use building:levels:ref:equivalent=* |
|
| 181903951 | Thanks. Occasionally I get the abbreviations mixed up or mistype them .. I usually fix them together with other things later. BTW, ref:CH:bfs:HISTID=* could be useful for your boundaries project. osm.wiki/Key%3Aswisstopo%3AKANTONSNUM seems to be deprecated. What's the plan for swisstopo:BEZIRKSNUM=* ? |
|
| 185282669 | concerne: note/5377394 pas l'autre. |
|
| 184854060 | Thanks. Meanwhile I added it to the locally mapped ones (I found more than expected). BTW, about the tracker website: possibly it uses the "snap to road"-feature (see osm.wiki/Recording_GPS_tracks#Prerequisites ) that suggests live tracking, but in areas with bad signal, dense street network and partially updated maps, it may simply plot the shortest theoretical path, looking plausible, but isn't the actual one. |