Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)
On Thu, Apr 20, 2023 at 10:11:49PM +0100, Andy Townsend wrote: > To change "shop=veryrarevalue" where it was correct to > "shop=lessrarevalue"without preserving the detail somehow loses detail from > OSM and is therefore by definition a Bad Thing. Some of the entries on your I disagree with that blanket "Bad Thing". It is much more likely that a general map will show shop=lessrarevalue with a specific icon than shop=veryrarevalue. So if you are using shop=veryrarevalue instead of shop=lessrarevalue you might lose detail in the database, but in practice you will gain detail in actual use. There is probably a sweet spot somewhere in the middle, enough detail to allow to differentiate "important" differences while not adding too much detail overwhelming anybody who wants to use the data. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline update process seems to be broken - major costline change near the Gulf of Ob
On Thu, Sep 15, 2022 at 01:05:51AM +0200, Marc_marc wrote: > I have learn about this area and it seem that the Gulf of Ob is an area > affected by tiles. > so the coastline should follow the Gulf as before and not stop somewhere > inside the Gulf it-self > > I have reverted the coastline change in > https://www.openstreetmap.org/changeset/126200089 Thanks. I have manually "unfrozen" the processing now. We'll probably have some other bad edits that make it through this way, but at least the big one is avoided. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions
On Tue, Dec 01, 2020 at 07:36:24PM -0800, Michal Migurski wrote: > Facebook is in compliance with the ODbL license which requires that > attribution be “reasonably calculated to make any Person that uses, views, > accesses, interacts with, or is otherwise exposed to the Produced Work aware” > of OSM’s contribution to a map. FB’s attribution approach in keeping with > best practices seen from other commercial users of display maps. > > Parts of the community have expressed a desire to see attribution that goes > beyond the ODbL. [...] Very interesting way of framing the issue. First you assert that Facebook is in compliance. Then you talk about "Parts of the community" who want something "beyond the ODbL.". But that's a straw man [1] argument. This argument is not about people wanting something beyond the ODbL. This is about a difference in opinion how the license is to be interpreted. Facebook simply reads the license in a different way than other people. This framing is especially interesting, because as board member you would have to defend the ODbL and have a conflict of interest over any issue where different interpretations of the ODbL between OSM/the community vs. Facebook are involved. But you would not have a conflict of interest over anything "beyond the ODbL". So by framing the issue this way you argued yourself out of your conflict of interest problem in this issue. Very clever! [1] https://en.wikipedia.org/wiki/Straw_man Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Updating of land/water polygons (based on natural=coastline) is too slow and unreliable
, the processing stops. When there are no major problems, changes show up within a day which is slower than other changes users do and that's certainly not ideal. Can we improve this process? Sure we can run it more than once a day. But that wouldn't help if it became stuck if there are large changes. It would help if the process could somehow stop the large changes in one area while letting changes in other areas proceed. This would give us some time to fix breakages and to discuss larger changes while not annoying mappers everywhere else. So if somebody can come up with a way of doing this coastline processing in a better way and actually implement it, this would be a great thing in my view. But in the end this is less an issue of the tools, but more of an issue of how the community organizes itself. We have organized editing guidelines and import guidelines for a reason and this case isn't that much different. If you want to do large scale edits that affect a lot of people, you have to discuss them beforehand in a suitable forum. And if you don't do that, we have an established procedure how to handle that: The DWG can step in and revert the change and then we can have that discussion. In the case of the changes in the Chesapeake Bay the mappers seem to have discussed those changes on a Slack channel somewhere probably not realizing how large the change was that they were planning and how many people it would affect, so they chose a forum that wasn't suitable for such a large scale change. We, as a community, could try to better define what kind of changes must be discussed where. But sometimes it is hard to see what consequences some change will have so these things will happen again and that's why it is good to have some safeguards built in like the change check in the coastline processing. I just wish it wasn't me having to deal with that, but some kind of community process. Jochen On Sat, Nov 21, 2020 at 10:37:22AM -0800, Joseph Eisenberg wrote: > Date: Sat, 21 Nov 2020 10:37:22 -0800 > From: Joseph Eisenberg > To: osm > Subject: [OSM-talk] Updating of land/water polygons (based on > natural=coastline) is too slow and unreliable > > I just found out that mappers in the east coast of the USA have been > converting coastal bays and tidal channels to natural=water areas because > they don't like how long it takes to get updated land/water polygons based > on the natural=coastline ways. > > See the comments on this changeset, where Pamlico Sound (a large area of > water at the edge of the Atlantic Ocean, inside of a line of barrier > islands - comparable to the Waddenzee in the Netherlands) was changed to a > natural=water polygon with the natural=coastline removed. > > "That was the reason we started removing the smaller estuaries from the > coastline, so edits to them would show up on the map in a timely fashion. " > > Unfortunately to get faster re-rendering times, mappers are mis-tagging > these areas which should be outside of the coastline. > > Is there any way we can improve the process of checking and updating the > water and land polygons, currently available on > https://osmdata.openstreetmap.de - so that mistakes do not lead to > multi-week waits for new polygons? Right now the last update was 11/11/2020 > - ten days ago. > > Is there any way of getting updates more often than once a day in the > best-case scenario when nothing is broken? > > -- Joseph Eisenberg > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad coastline edits in Sweden
Hi! can you point us to some of the changesets where you left comments? Jochen On Sat, Nov 21, 2020 at 10:54:53AM +0100, Andre Hinrichs via talk wrote: > Date: Sat, 21 Nov 2020 10:54:53 +0100 > From: Andre Hinrichs via talk > To: talk@openstreetmap.org > Subject: [OSM-talk] Bad coastline edits in Sweden > > Hi list! I'm doing a lot coastline fixings all over the world. Normally > only with few pain. But since a few weeks the user Aki_Suokas is doing > very bad coastline edits in the area of Sweden. I've written him several > time via changeset discussion but no reaction. At least he has stopped > in an other area where I was warning him with notifying OSM foundation. > Now he was editing again without any benefit but doing a lot mistakes. > It seems that he is not willing to learn and just do some useless > things. And since he is using the (bad) ID editor it is also nearly > impossible to revert the changesets which created the mess. As of today > you can see the errors here: > http://tools.geofabrik.de/osmi/?view=coastline=20.93588=59.91265=13=coastline,coastline_error_lines,line_not_a_ring,line_overlap,line_invalid,line_direction,questionable,coastline_error_points,unconnected,intersections,not_a_ring,double_node,tagged_node > As my own coastline checker is doing global checks without creating a > map it is hard for me to distinguish the errors in Sweden with other > errors worldwide. As of this I will stop fixing coastline errors now for > a while until this special situation is fixed. I'm asking for help here > how to handle the situation. Maybe the notification of OSM foundation is > ok, maybe not... Andre > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] YouTube Account "OpenStreetMap Deutschland"
Hallo Sören, magst Du vielleicht noch einen News-Artikel für www.fossgis.de schreiben? Am besten gleich als Markdown und als Pull Request auf https://github.com/fossgis/fossgis-webseite ? Kannst auch noch etwas warten bis https://videos.openstreetmap.de hübscher geworden ist -- wie ihr wollt. Jochen On Sun, Jun 07, 2020 at 11:41:02PM +0200, Sören Reinecke via Talk-de wrote: > Date: Sun, 07 Jun 2020 23:41:02 +0200 > From: Sören Reinecke via Talk-de > To: talk-de@openstreetmap.org > Cc: Sören Reinecke > Subject: Re: [Talk-de] YouTube Account "OpenStreetMap Deutschland" > > Hi, > > nun ist es soweit. Unser YouTube Account > https://www.youtube.com/channel/UCjCS5VzsMI2TreDsIxWoIEg ist heute mit > zwei Videos online gegangen. Für Menschen, die YouTube nicht mögen, > gibt es https://videos.openstreetmap.de (Das befindet sich zurzeit im > Aufbau und soll noch einen hübschen Anstrich bekommen, insofern sind > Designideen gefragt :)) > > Wir werden nun nach und nach das Angebot weiter ausbauen. Die > dazugehörige Wikiseite > https://wiki.openstreetmap.org/wiki/Germany/Videos_zu_OSM wird > ebenfalls aktualisiert. Zu Anfang werden wir noch etwas träge agieren, > weil wir noch keine Workflows haben. Aber wir arbeiten daran. > > Wir sind in Moment zwei bis drei die das machen. Einer ist wieder > ausgestiegen. Insofern freuen wir uns auch über OSMler, die ebenfalls > zum Projekt "Videos zu OSM" beitragen wollen. > > Längerfristig soll es auch das Ziel werden, Videos mit veraltetem > Inhalt rauszunehmen und neu zu machen. Hat den positiven Nebeneffekt, > dass man die Videos dabei qualitativ verbessern kann. > > Danke an FOSSGIS e.V. für die Betreuung des Accounts und für die > Bereitstellung der Resourcen. Ich werde mich auch drum kümmern, dass > ich für die Community besser erreichbar werde. So kann man mich bei > Fragen etc. zum Projekt kontaktieren. > > Gruß > > Sören Reinecke alias Valor Naram > > On Sat, 2020-03-21 at 18:44 +0100, Sören Reinecke via Talk-de wrote: > > Hey, > > > > wenn ich mir Youtube angucke, dann finde ich sehr viele > > englischsprachige Videos zu OpenStreetMap in selten guter Qualität > > (eher schlecht oder mittelmäßig). Diese sind aber nicht gebündelt > > sondern bunt durchgemischt (kein offizieller Account, vielmehr kleine > > "Kräuter"). Es gibt z.B. keine mir bekannte Playlist zu "OSM Basics". > > Youtube ist dabei eine Plattform, die von vielen Menschen genutzt > > wird > > um neue Dinge kennen zu lernen. Youtube kann also dazu beitragen, > > dass > > OpenStreetMap bekannter wird und Eintrittsbarrieren nicht mehr so > > groß > > scheinen. > > > > Was sagt ihr dazu? Wir brauchen nur ein Team von Content-Producern. > > > > Gruß > > > > ~ Sören Reinecke alias Valor Naram, > > > > > > Developer of the Babykarte - https://babykarte.github.io > > Participating in MapDiscover project - https://mapdiscover.org > > "Community Supporter" for Trufi Association - https://trufi- > > association.org > > > > Ein Gag zu Hamsterkäufen: https://klopapier.mapdiscover.org id="-x- > > evo-selection-end-marker"> > > ___ > > Talk-de mailing list > > Talk-de@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-de > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Mon, May 20, 2019 at 10:23:07PM +0200, Florian Lohoff wrote: > On Mon, May 20, 2019 at 09:32:25PM +0200, Jochen Topf wrote: > > > besorgt - Problem ist das entgegen der Doku die durch > > > das ST_Simplify doch kleiner werden und schneiden können. Muss man > > > also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus > > > mal seltsame Multipolygone. > > > > Wenn Du alles innerhalb einer Grenze haben willst, kannste das auch mit > > "osmium extract --polygon" machen und die Grenze direkt aus OSM nehmen. > > Wenn Du dann noch die "smart"-Strategie benutzt, dann ist auch die > > Grenze selbst garantiert drin. Vereinfachte Grenzen machen das Ganze > > etwas schneller, aber nicht viel. Und dann musste Dich nicht mit Buffern > > oder so rumärgern. > > Ich habe halt hier für meinen ganzen Auswertungsramsch diverse sub PBFs > von Deutschland die ich derzeit mit osmupdate/osmconvert update > und neu beschneide. Dafür brauche ich halt polys. > > osmupdate/osmconvert ist da ein wenig eigenwillig was das ausschneiden > angeht. Daher ist mir dann OWL/Regierungsbezirk Detmold um die Ohren > geflogen. Ich würde ja einfach auch osmium umstellen in der pipeline > aber da fehlt mir das mit dem dem automatisch update eines pbfs d.h. > download der change files. Das geht mit https://docs.osmcode.org/pyosmium/latest/tools_get_changes.html bzw. https://docs.osmcode.org/pyosmium/latest/tools_uptodate.html > Ich will doch einfach nur ein geographisches .pbf auf dem aktuellen > stand halten. Und das "consumerdevice" um das zu machen ist > halt osmupdate mit dem -B poly und schon läuft das für doofe. "für doofe" würde ich ja nicht sagen. Man muss ja schon wissen, dass man dabei ggf. nicht komplette Daten erzeugt und damit irgendwie umgehen. Aber hast recht, Osmium kann das nicht so einfach (gerade weil ich den User nicht "in Sicherheit wiegen" will). Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Mon, May 20, 2019 at 08:36:18PM +0200, Florian Lohoff wrote: > On Fri, May 17, 2019 at 07:22:06PM +0200, wambac...@posteo.de wrote: > > Moin > > > Am Ende war es vieles - poly von download.geofabrik.de der an einer > > > winzigen stelle einen node schneidet einer boundary. > > > osmupdate/osmconvert mit dem poly schneiden dann da einen teil der > > > boundary weg. > > > > Die Poly-Files der Geofabrik sind fast alle händisch erstellt worden, > > daher einfach und relativ schnell. Wenn sich aber eine Grenze verändert > > haben sollte, kann das (nie wieder angefasste) Poly-File schon mal > > falsch sein. > > > > Mein Tip: / > > /- https://wambachers-osm.website/boundaries// > > > > - bpoly mit einem Buffer von 1-2 km wählen und dann sind die > > *tagesaktuell*. ;) > > Da geht nen buffer? Das habe ich wohl übersehen. Habe mir > jetzt bei > > http://polygons.openstreetmap.fr/get_poly.py?id=73347=0.02-0.001000-0.005000 > > besorgt - Problem ist das entgegen der Doku die durch > das ST_Simplify doch kleiner werden und schneiden können. Muss man > also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus > mal seltsame Multipolygone. Wenn Du alles innerhalb einer Grenze haben willst, kannste das auch mit "osmium extract --polygon" machen und die Grenze direkt aus OSM nehmen. Wenn Du dann noch die "smart"-Strategie benutzt, dann ist auch die Grenze selbst garantiert drin. Vereinfachte Grenzen machen das Ganze etwas schneller, aber nicht viel. Und dann musste Dich nicht mit Buffern oder so rumärgern. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Thu, May 16, 2019 at 10:38:17PM +0200, Martin Koppenhoefer wrote: > > On 16. May 2019, at 21:03, Florian Lohoff wrote: > > > > osmosis --read-pbf file=detmold-regbez-latest.osm.pbf --tf accept-ways > >boundary=administrative --used-node --write-xml output.osm > > > > Grenzen extrahiert - und das ist falsch. Es exportiert eben Wege > > ohne boundary=administrative nicht > > > und wenn Du die Relationen und deren Member evtl. rekursiv mitfilterst? Oder > nur die Relationen mit members? > > Nur die ways klappt natürlich in dem Fall nicht, aber da kann man dem Osmium > keinen Vorwurf machen. Osmium kannste eh keinen Vorwurf machen, wenn dann Osmosis :-) Florian: Warum nimmste nicht einfach Osmium, das ist auch noch einfacher: osmium tags-filter detmold-regbez-latest.osm.pbf a/boundary=administrative -o output.osm Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Coastline/Icesheet extracts moving to new server
Hi! the OSM extracts formerly at openstreetmapdata.com are moving to their new home at https://osmdata.openstreetmap.de/ . If you are using the coastlines or icesheet downloads switch to that site now! If you are using generalized datasets, contact me. These datasets are not available on the new site (yet) and we are trying to gauge interest. Some more background here: https://blog.jochentopf.com/2019-03-07-the-new-osmdata-service.html Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] We're erasing our history in wiki
On Mon, Apr 22, 2019 at 12:03:40AM +0300, Ilya Zverev wrote: > In my research of API 0.6 (which turned ten years old yesterday) I've > stumbled on this page: > > https://wiki.openstreetmap.org/wiki/API_v0.6/Crowd_sourced_Testing > > It was deleted 7 years ago. And this is a disaster. The page was an > important milestone in our history: authors, dates, items on it could bring > some more information on how our current API was rolled out. Nothing is > left. It was deleted an yet you have found it. So not a huge desaster after all. > Please, could we have a deletion policy in our wiki that clearly states "No > obsolete pages here", forbidding deletion of anything except spam or > otherwise harmful pages? Deleting our history is plain vandalism, no better > than physically destroying pieces of human history displayed in museums. Isn't that a bit of hype here... > It's not like we're pressed for disk space there. No, we aren't. But we are pressed for time and human attention. Of we had curators who keep important things organized and findable we could keep things forever. But as it is, all the obsolete crap keeps us from finding and working with what we need now. > Thank internet gods for the Internet Archive, Not the gods but some good people who had a good idea. Let them do their job and keep the history and lets do our job and keep the momentum in the project instead of spending our time looking back. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] An Archive namespace for the OSM wiki?
On Sat, Apr 20, 2019 at 10:02:34AM +0200, Mateusz Konieczny wrote: > What you expect to find by searching for "GPS"? The problem > is not that there are searches that will return many archive pages > (I guess that "rejected" will get plenty of failed proposals), but > that someone is searching for something specific and unable to find > it due to large number of archived pages. Exactly. I expect to find information about GPS, about GPS use in OSM, about GPS receivers, about software to work with GPS traces, etc. So I expect to find exactly what I found. Except that I expect to find 10 useful pages, not 5. If the outdated pages were not there, who knows what useful pages I might have found! Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] An Archive namespace for the OSM wiki?
On Fri, Apr 19, 2019 at 11:07:45PM +0200, Mateusz Konieczny wrote: > Apr 19, 2019, 11:01 PM by joc...@remote.org: > > > One problem with the wiki is that you can't find current stuff because > > of all the old stuff in there. Deleting helps. Marking them as obsolete > > doesn't. > > > Can you give example of situation where this is a problem? > With pages properly marked as obsolete it should add single click. Go to wiki.osm.org. Type "GPS" into the search field and look at the suggestions: * GPS (redirect to "GNSS tracelog", looks okay) * GPS device reviews (helpful page and seems to be maintained) * GPSBabel (still useful software, okay) * Gpsmid (software that seems to be maintained, okay) * GpsPrune (not the newest software, but probably okay) * GPS receiver (meaningless page only referring to a few others) * GPS navigation & maps (page says on top: "No longer maintained since 2015") * Gpsdrive (last version from 2012, does it still exist?) * GPS Units for Loan (totally outdated) * JA:GPSトレースの公開性 (I don't speek Japanese so I can't judge this) So from the 10 suggestions, I would say that half are useful, half are not. The wiki is not perfect and will never be. It is okay if you occasionally encounter something outdated or have to do a "single click" further. But single clicks also add up. And it is not so much about the click but about the need to read the contents of the page first. Might be okay for you and me because we have been around long enough to see quickly what's interesting and what isn't. But if you are not familiar with OSM this is daunting. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] An Archive namespace for the OSM wiki?
On Fri, Apr 19, 2019 at 10:02:48PM +0200, Michael Reichert wrote: > there is currently a voting on a Deletion Policy [1] for the OSM wiki. > The policy was drafted because we had two incidents last year when > someone tried to delete a large number of old and orphaned tagging > proposals in draft state. He claimed that these pages might confuse > users looking for a tag. > > He is not totally wrong with that. These pages can be confusing but > there are reasons why other users (including me) claim that most > proposals should be kept. I just realized that in my other reply to this post I didn't address the question you started with, namely whether tagging proposals are worth keeping. I still think that we should not be overly cautious. We should delete things when in doubt. Otherwise we'll never get the wiki to a manageable level. But there are things worth preserving. And a discussion about tagging might be one of those things. If there is real content, people having different ideas about something explaining their reasons etc., then this is valuable. Tag discussions have the tendency to come back up and often discussions are done again and again because we forget what we talked about the last time or new people don't have the context. So in those cases having some kind of history around could be useful. But there probably are plenty of pages where somebody had some idea that never got any real discussion, maybe about something that found a totally different solution in the mean time. Those pages might not be so important to keep. So as always you have to look at each case. If a page contains content that is still useful for our current world, keep it. But if something is merely interesting for historical reasons then it can be deleted. And yes, there is a gray area there, but humans can be trusted with these decisions and the world will not end if occasionally somebody makes the "wrong" decision. But stalling any progress in the wiki by requiring discussions about any change is certainly not the right way. Look at OSM itself, we allow anybody to delete anything there, too, and it seems to work out mostly. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] An Archive namespace for the OSM wiki?
One problem with the wiki is that you can't find current stuff because of all the old stuff in there. Deleting helps. Marking them as obsolete doesn't. And moving them to a different namespace is even worse, because it breaks links but doesn't make the page invisible. Anything that makes pages invisible (to users and search engines indexing the wiki) but allows switching on a special "archive mode" where you still see those things would be fine. But as long as a search on the wiki or on the search engine of your choice finds all that old crap, the problem is still there. You still have to click through all the pages you found to see that they are marked as outdated. Preserving history is a worthy goal, but not at the expense of making the current information much harder to find and use. Let archive.org do the history keeping. And if all else fails, it should be possible to revive deleted pages from the mediawiki software. Jochen On Fri, Apr 19, 2019 at 10:02:48PM +0200, Michael Reichert wrote: > Date: Fri, 19 Apr 2019 22:02:48 +0200 > From: Michael Reichert > To: OSM talk mailing list > Subject: [OSM-talk] An Archive namespace for the OSM wiki? > > Hi, > > there is currently a voting on a Deletion Policy [1] for the OSM wiki. > The policy was drafted because we had two incidents last year when > someone tried to delete a large number of old and orphaned tagging > proposals in draft state. He claimed that these pages might confuse > users looking for a tag. > > He is not totally wrong with that. These pages can be confusing but > there are reasons why other users (including me) claim that most > proposals should be kept. > > In addition to these proposals, there is a much larger number of > outdated wiki pages about mapping techniques and OSM-related software. > Some can be updated but some can't: Pages about Kosmos document a map > renderer whose binary cannot be downloaded any more. Pages about > unmaintained/historic software like Traveling Salesman [2] or Namefinder > [3] are another example. > > Deleting these pages is deleting memory and history. Rewriting them in > past tense and deleting unimportant content is a lot of work and is on > the borderline to vandalism if the page could be updated. However, such > pages should be treated different to make readers aware that they hit > something old and outdate. That's why I think that there should be a > "Archive" namespace on the wiki where such pages can be moved. > > An alternative to a namespace is a template being added to these pages > informing readers that the page exist for archival purposes only. That > was done with the wiki page about Namefinder. It has already been marked > as "This page describes a historic artifact in the history of > OpenStreetMap. It does not reflect the current situation, but instead > documents the historical concepts, issues, or ideas." > > What do you think? > > Best regards > > Michael > > > [1] https://wiki.openstreetmap.org/wiki/OpenStreetMap:Deletion_policy > [2] https://wiki.openstreetmap.org/wiki/Traveling_salesman > [3] https://wiki.openstreetmap.org/wiki/Name_finder > > -- > Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten > ausgenommen) > I prefer GPG encryption of emails. (does not apply on mailing lists) > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Missing day replicate
On Mon, Feb 11, 2019 at 12:02:23PM +0100, Rory McCann wrote: > I've seen this error before a few times. I thought the file was bad and was > pulling my hair out trying to find the weird bytes (which didn't exist). The > file came from osmosis merging a few osc files together. By deleting that > file, osmosis would make a new one and the problem went away. I guess its time to ditch Osmosis und switch to Osmium/PyOsmium for these tasks... Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Missing day replicate
Hi! this might or might not be related to the hourly change file with the number 56107 being "strange": Osmosis can not read the file 107.osc.gz, it reports a UTF-8 error. But if I gunzip the file, Osmosis can read the file fine. So this points to an error in Osmosis' handling gzip'ed files. Unfortunately Osmosis is no longer maintained. Generally errors like this should probably be reported on https://trac.openstreetmap.org/ or the dev mailing list or #osm-dev IRC channel would be a good place. Jochen On Sat, Feb 09, 2019 at 11:49:45AM +1100, Andrew Davidson wrote: > Date: Sat, 9 Feb 2019 11:49:45 +1100 > From: Andrew Davidson > To: talk@openstreetmap.org > Subject: Re: [OSM-talk] Missing day replicate > > Hasn't worked for three days now: > > https://munin.openstreetmap.org/problems.html#critical > > also the Planet dump is also not working. I'm not sure how we're supposed to > report these, there used to be a status page on the wikki but that appears > to no longer be the appropriate place. > > On 8/2/19 8:22 am, Andre Hinrichs wrote: > > Hi list, > > > > I am missing the day replicate for today (2019-02-07)... > > > > Hour and minute replicate seems to work ok. > > > > Please check the process... > > > > > > Greetings > > > > Andre > > > > > > > > ___ > > talk mailing list > > talk@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk > > > https://munin.openstreetmap.org/problems.html#critical > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Tag zu Id-referenzierten Ways zufügen?
On Fri, Jan 11, 2019 at 05:30:51PM +0100, Holger Bruch wrote: > Mit welchem Werkzeug könnte ich für ca. 1000 über Id identifizierte Ways > einer pbf-Datei ein Tag hinzufügen? > > Ich dachte an Osmosis, dessen tag-transform allerdings noch kein > Matching per Id unterstützt. Da gibts viele Möglichkeiten. Z.B. ein kleines PyOsmium-Skript. Oder Du schreibst ein kleines Skript, was mit "osmium getid" die Ways rausfriemelt, als OPL speichert und darin den Tag ändert und alles wieder zusammensetzt. Ein bischen programmieren wirst Du aber schon müssen. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Ground truth for non-physical objects
On Tue, Dec 11, 2018 at 01:08:35PM +0200, Tomas Straupis wrote: > I had an actual situation 5 or so years ago when an address was > mapped in Vilnius. Address does not exist in official records. The > user sent me a picture of this house number. I contacted municipality > ant they explained that the sign is not an official one, it means > nothing, there is no such address. It seems you haven't understood the on-the-ground rule 5 years ago and you still haven't. For all intents and purposes there is such an address. Mail will arrive there, people can find the house when looking for it. It doesn't matter what the official record says. It doesn't matter whether the address should be there or not according to some authority. The address is there and it should be mapped that way. That is what on-the-ground rule means. It works in practice. It works well. And, yes, there are always corner cases. But that's no reason to discredit the rule. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Illegale Feuerstelle
On Mon, Dec 03, 2018 at 11:12:37AM +0100, Martin Koppenhoefer wrote: > Am Mo., 3. Dez. 2018 um 11:09 Uhr schrieb Florian Lohoff : > > > Entfernen. Ich habe auch auf den Nordseeinseln Wege durch die Dünen > > entfernt. Das waren gemappte Trampelpfade wobei das Betreten der Dünen aber > > untersagt ist. Angenommen jemand benutzt sein Handy als Navi würden > > wir ihn da durch führen. Oder auf der Karte sieht das so aus > > als dürfe man da durch. Und access=no hilft da ja auch nur > > am Rande. > > nach der Logik müsste man alle Wege entfernen, die nicht allgemein > zugänglich sind. Die Existenz eines Trampelpfads beweist ja, dass es dort > einen Weg gibt und der auch benutzt wird. Ich würde da informal=yes und > access=no drauf pappen, und wenn das nicht hilft, dann funktioniert die > Anwendung nicht. Meines Erachtens stiehlst Du Dich damit nur aus der Verantwortung als Mapper. Du kannst noch so viele Tags irgendwo dranhängen, um mit immer mehr und mehr Detail zu unterscheiden, was etwas ist. Natürlich wohl wissend, dass keine Anwendung diese Details unterscheidet. Und wenn sie das tut, der User nicht unterscheiden kann zwischen den 17 verschiedenen Strichlierungen des Weges und was das für ihn bedeutet. Letzlich bleibt es immer eine subjektive Entscheidung. Und wenn ich eh eine subjektive Entscheidung treffe, dann kann ich auch gleich sagen: Okay, das ist ein Weg oder, okay, das ist kein Weg. Das schöne an OSM ist, dass Menschen sowas entscheiden und nicht Algorithmen. Und Menschen können viele Informationen in diese Entscheidung einfließen lassen. Dazu gehört, wie etwas aussieht, aber auch wie die Umgebung aussieht (wenn es in der Nähe einen offiziellen Weg gibt, dann mappe ich den inoffiziellen vielleicht eher nicht z.B.), wie die beobachtete Nutzung durch Leute vor Ort ist usw. Und ja, da macht man Dinge auch mal falsch. Aber das ist okay, weil andere Mapper nach mir kommen und Dinge korrigieren können. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Illegale Feuerstelle
On Mon, Dec 03, 2018 at 11:06:04AM +0100, sepp1...@posteo.de wrote: > Die Prüfung ob legal oder illegal ist doch nicht Aufgabe von OSM - mal vom Sehe ich auch so. Mit irgendwelchen Spezialtags, die keiner auswertet, helfen wir letztlich niemandem. Also wenn da eine "echte" Feuerstelle ist mit eingefasster Feuerstelle, Grillrost oder dergl., dann würde ich es mappen, egal ob das nun legal ist oder nicht (on the ground rule). Wenn der Besitzer des Grundstücks oder die Gemeinde oder Forstverwaltung das nicht will, dass da Feuer gemacht wird, dann sollen die das Ding entfernen. Wenn da einfach nur eine Stelle auf dem Boden ist, wo man sieht, dass jemand Feuer gemacht hat, aber es nicht nach was "offiziellem" aussieht, dann würde ich das eh nicht mappen, weil es kann ja nächstes Jahr schon wieder zugewachsen sein. Sowas ist keine Feuerstelle, nur ne Stelle, wo mal ein Feuer war. Und dazwischen gibts natürlich einen Bereich in dem der Mapper abwägen muss. Und das ist gut so. Wenn ich z.B. weiß, dass da seit Jahren im Sommer jeden Tag jemand grillt, dann trage ich das vielleicht trotzdem als Feuerstelle ein auch wenn ich mir über den legalen Status nicht sicher bin. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnkilometer.ch
On Fri, Apr 20, 2018 at 07:13:16PM +0200, dktue wrote: > ich möchte gerne in der Schweiz die Autobahn-Kilometer pflegen und habe > hierfür eine Seite mit Hilfe der Overpass-API erstellt [1] (lange > Ladedauer!). > > Gerne nehme ich hierfür Verbesserungsvorschläge oder auch Pull-Requests auf > GitHub an [2]. > > Verwundert bin ich über die errechnete Gesamtlänge des Autobahnnetzes, > welche laut OSM-Daten derzeit 3817 km beträgt (entspricht ungefähr 1909km > bei einfacher Zählung beider Fahrtrichtungen) laut offiziellen Daten jedoch > nur 1447 km [3]. Kann jemand diese Differenz von rund 500 km erklären? Ich hab das mal auf andere Weise nachvollzogen: Download der Schweiz von der Geofbarik, dann osmium tags-filter switzerland-latest.osm.pbf w/highway=motorway -o \ motorways.osm.pbf osmium_road_length motorways.osm.pbf (das ist ein Beispielprogramm was bei libosmium dabei ist) ergibt: Length: 3069.67 km Durch zwei geteilt sind das ca. 1535 km, was viel besser passt. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] no_feature_tag_nodes
On Fri, Apr 13, 2018 at 07:02:39AM +0400, Jack Armstrong dan...@sprynet.com wrote: > OSM Inspector tags some individual address nodes as errors. For example, these > nodes located inside the lateral boundaries of buildings: > > https://www.openstreetmap.org/edit?node=5438712543#map=19/39.68899/-104.86454 > > I guess I'm reading it wrong, but I can't seem to locate anything specifically > on the wiki that refers to this. Is there some documentation I can refer to > which addresses this specific situation? Click on the litte (i) icon next to the "View" dropbox. This will take you to https://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Tagging where everything should documented. Btw: It would have made your question easier to understand if you had supplied a link to the OSMI page you are looking at (for that use the "Permalink" on the bottom right). I was looking through the "Addresses" view because you mentioned something with "address nodes" trying to figure out what you meant... Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Do I understand this correctly? You are creating tags in the OSM database for your private tool? I hope there is some misunderstanding here, because that isn't acceptable behaviour. Jochen On Sat, Oct 14, 2017 at 09:33:14AM +, Yuri Astrakhan wrote: > Date: Sat, 14 Oct 2017 09:33:14 + > From: Yuri Astrakhan <yuriastrak...@gmail.com> > To: Simon Poole <si...@poole.ch>, talk@openstreetmap.org > Subject: Re: [OSM-talk] New OSM Quick-Fix service > > ** UPDATE: ** > > The service now supports "reject" button. To use it, your query must > contain " #queryId:... " comment. By default, when a user rejects > something, a tag "_autoreject=id" is created. An object can have multiple > rejected IDs. If the current query was previously rejected, user will no > longer be able to edit the object with the same query. > > Optionally, query may specify a different rejection tag with > " #rejectTag:... ", instead of using the default "_autoreject". I am > still hoping for a better default name. > > Both #rejectTag and #queryId values must consist of only the Latin > characters, digits, and underscores. > > Additionally, the tool no longer allows editing above zoom 16. > > Thanks! > > > On Sat, Oct 14, 2017 at 12:34 AM Yuri Astrakhan <yuriastrak...@gmail.com> > wrote: > > > Simon, thanks for the constructive criticism, as it allows improvements > > rather than aggravation. I propose that "rejections" are saved as a new > > tag, for example "_autoreject". In a way, this is very similar to the > > "nobot" proposal - users reject a specific bot by hand. > > > > _autoreject will store a semicolon-separated multivalue tag. A query will > > contain some "ID", e.g. "amenity-sanatorium", and that ID will be added to > > the _autoreject whenever user clicks "reject suggestion" button. > > > > Benefits: > > * use existing tools to analyse, search, and edit this tag, without > > creating anything new > > * we can use it inside the queries themselves to say "only suggest to fix > > X if the users have rejected Y", or if someone creates a bad query and most > > values are rejected, we can easily find them and clean them up > > * very easy to implement, few chances for bugs, no chances to loose > > rejection data by accident > > * other tools can also use this field to store rejections, e.g. > > mapRoulette or Omose. > > * Query authors can easily search for it to see why they showed up in the > > query result, and fix the original query > > > > The biggest problem is the tag name, any suggestions? > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multipolygon relations and disjunct geometries
On Thu, Sep 28, 2017 at 02:52:29PM +0200, Martin Koppenhoefer wrote: > Recently I was presented with an Error message of my favorite editing > software, when I tried to upload a changeset where several pyramids in Giza > (Egypt) together are known by a common name. > > JOSM told me there was an Error in my data. An Error for the JOSM validator > is something that is most likely wrong and should usually be fixed. > > The reason for the error was that I had created a multipolygon, but had > left tags which are referring to an area, on the member objects (outer > ways). This is something I believe is completely regular and happens as > soon as some property of one of the members is not valid for the relation > as a whole, e.g. because the name is different, etc. > > What is your opinion on this? If the outer ring is a single closed way it is a polygon in its own right and it is perfectly okay that it has its own (polygon) tags. Those tags only apply to this particular way then. If the outer ring is made up of several ways, the tags on them only apply to each way by itself. If those are "line" tags, like highway, or something like a wall, that is fine. But they can't be "polygon" tags like landuse etc. because there is no polygon there. If you need this, you'll need another multipolygon relation combining those ways. This is somewhat different than the older interpretation when we still had old-style multipolygons. But with the new-style multipolygons interpretation, the tags from a collections of objects are *never* aggregated into a larger whole. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Relation zu Poly-File aus PBF
On Sat, Sep 02, 2017 at 12:44:22PM +0200, dktue wrote: > ich möchte gerne kleine Regionen aus einer automatisch aktualisierten > planet-PBF-Datei ausschneiden, aber vor dem schneiden gerne die zum > Schneiden verwendenten .poly-Dateien aktualisieren. > > Am besten wäre es, wenn ich hierzu anhand der Relation-ID diese aus der > planet-PBF-Datei direkt extrahieren könnte. Allerdings kenne ich hierfür nur > dieses Pearl-Script [1], welches nur mit XML-Dateien umgehen kann -- für > Planet ist es keine Option, mit XML zu arbeiten. > > Kennst jemand ein Werkzeug (oder eine Werkzeug-Kette), dass mir aus einer > lokalen planet-PBF-Datei anhand der Relation-ID ein Poly-File schreibt, mit > dem ich dann (mit Hilfe von osmconvert) die Regionen ausschneide? Du kannst das mit Osmium (http://osmcode.org/osmium-tool) machen. Erster Schritt ist mit etwas wie osmium getid planet.osm.pbf -r 1234 -o rel.osm.pbf die Relation rausholen, die als Grenze dienen soll. Dann den Extract machen: osmium extract planet.osm.org -p rel.osm.pbf -o ausschnitt.osm.pbf Eine Poly-Datei brauchste nimmer, osmium kann direkt die OSM-Datei mit der Relation verwenden. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Multipolygon fixing effort done
On Tue, Aug 29, 2017 at 03:54:44PM +0200, Christoph Hormann wrote: > On Tuesday 29 August 2017, Jochen Topf wrote: > > > > > Would the number of visible problems in the map due to dropping > > > broken geometries now, after the fixing effort, be low enough so > > > this change could be made to the main map to give mappers a better > > > feedback about broken geometries? > > > > Osm2pgsql is switching to the libosmium MP code which is more strict > > than the older code before. As far as I know the code is finished and > > should be in the next osm2pgsql version. > > I am aware of that but this does not answer my question if the fixing > effort has significantly reduced the visual impact rolling out this > change to the OSMF servers would have. I would assume it has but the > OSMI does not really allow for a proper assessment here. When the old-style-mp support was disabled on the main map, this left about 50,000 broken multipolygons, in many cases clearly visible on the map. I didn't see a single complaint about this. So, no, I don't think being a bit more strict with broken MPs will be a problem with the map or would be a reason to delay deployment of a new osm2pgsql version. 10,000 intersection problems in 300 million polygons is a rounding error. Note also that Mapbox has been using libosmium code for a while and they are actively fixing large broken MPs every day to keep the map from breaking in a bad way. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multipolygon fixing effort done
On Tue, Aug 29, 2017 at 12:10:47PM +0200, Christoph Hormann wrote: > Date: Tue, 29 Aug 2017 12:10:47 +0200 > From: Christoph Hormann <o...@imagico.de> > To: talk@openstreetmap.org > Subject: Re: [OSM-talk] Multipolygon fixing effort done > > On Tuesday 29 August 2017, Jochen Topf wrote: > > We have completed the 7-months effort to switch away from old-style > > multipolygons and fix a lot of broken (multi)polygons. More about > > this on my blog: > > > > https://blog.jochentopf.com/2017-08-28-polygon-fixing-effort-conclude > >d.html > > First of all congratulations to what was achieved, i.e. a fairly massive > reduction in the number of errors. > > The sad news however seems to be that given the current circumstances > the number of errors will likely be back to near the pre-cleanup levels > in 2-3 years for many types of errors. > > From my point of view this is because in contrast to the old style > multipolygons where > > * the problem was fully eliminated in the data > * the most important data user (the standard map) was changed to not > interpret old style MPs any more after that > * the major editors had already ceased to generate old style MPs long > ago > > the circumstances that lead to the large number of broken multipolygons > are essentially unchanged. We certainly got rid of a number of errors > from bad imports and can hope that future imports will be better in > that regard but the problem that mappers introduce this kind of error > in manual mapping and don't realize they are making an error is > unchanged. What has changed is that now without the complication of the old-style MPs it is easier to check for correctness of the data in editors and other tools. I hope that especially editor developers are looking at this problem more closely to identify common problems that can be fixed by better UI or better checking on their code. > Of the points above both completely eliminating MP geometry errors and > changing the editors not to upload broken geometries are things that > are very hard to accomplish. This leaves the third point and therefore > my question: > > Would the number of visible problems in the map due to dropping broken > geometries now, after the fixing effort, be low enough so this change > could be made to the main map to give mappers a better feedback about > broken geometries? Osm2pgsql is switching to the libosmium MP code which is more strict than the older code before. As far as I know the code is finished and should be in the next osm2pgsql version. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Multipolygon fixing effort done
We have completed the 7-months effort to switch away from old-style multipolygons and fix a lot of broken (multi)polygons. More about this on my blog: https://blog.jochentopf.com/2017-08-28-polygon-fixing-effort-concluded.html Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Draft Trademark Policy
On Sun, Aug 06, 2017 at 03:55:04PM +0200, Simon Poole wrote: > > I suggested it only be allowed if: (i) [THING] is a noun-like word which > > refers to something that is mapped in OSM. (ii) You are making a map of > > that subset of OSM. It might be a good idea to limit it to community > > made, open, maps, or that it must not be massively commerical, and must > > not try to immitate OSM (So no "OpenRoadMap") > I've already given the examples that illustrate why allowing it in > general is a bad idea, and for existing such projects in OSM space we've > said that they would be grandfathered (with a couple of restrictions > that guarantee that the projects remain OSM centric). As a tendency I > would rather prefer not to add more worms to the can going forward, but > I could imagine that we simply have a regime in which the OSMF registers > and holds the domains (something that we've done in a couple of cases in > the past). I don't understand why the "OpenSomethingMap" issue has you so spooked. I don't think anybody but you thinks something like "OpenWeatherMap" is necessarily related to OpenStreetMap in any way. Why wood you? We all know what a "weather map" is, so this is an "Open" one, which doesn't mean much these days. The biggest problem we had with OpenSeaMap was always not that they were somehow leaching from the great name we have, but that they presented themselves as this great project when all they are is a thin layer on top of OSM. They always downplayed their relationship to OSM instead of using it to build their own reputation by piggybacking on ours. I had to explain to many people that, no, they are just this little offshoot of OSM. Albeit with better marketing. Anyway, this is all moot, because nobody believes that the OSMF would actually sue anybody, let alone a small helpless hobby project, to get hold of their domain or force them to sign some agreement. Especially not when all they are doing is using a name that a judge might or might not see as similar enough to the OpenStreetMap trademark. I am sure you have the best intentions of defending OSM against the big bad conglomerates, but I think the best defense is having a large and open community and eco-system, one where you don't have to ask for permission before you contribute. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Draft Trademark Policy
On Fri, Aug 04, 2017 at 07:07:47PM +0200, Simon Poole wrote: > Sorry but that is hyperbole, after the 13 years of OSM the number of > domains affected amounts to something between 30 and 40., not 100s. The > policy is rather clear on what is allowed and what not, and if there are > further questions we can address that in the FAQs. My number was not referring to domains alone, but also to other projects, software etc. See below. And, no, the policy is not clear at all. Maybe to you with your background but not to me and not to many others I would think. The discussion here shows that it isn't. There are obvious further questions that I am asking in this discussion and you are not answering them but referring me to a FAQ that will be written in the future, maybe after the policy has been decided on? Why are we having this discussion here at all? Can somebody please at least try to answer my questions? > Why would we be interested in the names of github repos/projects? We are > mainly interested in use of our marks in commerce and similar/related > activities and registrations that convey exclusive rights (domain and > company names etc)., Ah. You are "mainly interested in". Maybe you should put that in the policy then... And write down what the difference is between "commerce and similar/related activities" and things that are purely hobby, which I suppose is okay? We have been through this discussion a thousand times in relation to copyright and the non-commercial clause in some CC licenses and why it is bad because we can't differentiate between commercial and hobby use really. Why is this different here? Can we differentiate? The policy as it stands now certainly doesn't seem to make a distinction there. Back to the question of software and github repo names: The policy doesn't even mention "software" or "apps" as a category. So I look for the best fitting case which seems to me 4.3 "Publications" for which I would need a license. Is this a wrong interpretation? Do I understand you correctly that I can have a software with the name OpenStreetMap in the title in a github repo and it doesn't fall under this policy? Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Draft Trademark Policy
On Thu, Aug 03, 2017 at 11:07:44PM +0200, Simon Poole wrote: > https://wiki.openstreetmap.org/wiki/Trademark_Policy#OpenStreetMap_Trademark_Policy Can you say something about the rationale behind the split between "Community members" and "Unrelated organizations or individuals" in section 1.3? It seems to me this distinction is difficult to make in a legally strict form. Is one edit enough to be a community member? Or if you come to a mapping party? Traditionally the OSM community has been defined as "everybody who feels like they are a member is a member". But even if the new rule is somewhat stricter, "at least 3 edits" or whatever, this isn't something you can easily build legal distinctions on, because anybody who wants to subvert the policy can easily become a member by making this necessarily low hurdle. (And, by the way, I have seen much more activity from OSM community members than from outsiders that is giving OSM a bad name...) So the distinction has to come not from what you *are* (member or unrelated) but what you *do*. This distinction is used for two things in the document, one is about *what you are* "Community members are generally free to use all OSM marks for community-focused events" (1.3.1) etc. The other is about who the *objects of your activity are* (Community-focused events 3.1 etc). I think the second use makes sense, but the first use is a bit questionable and hides the fact that the community members have the same restrictions on what they can actually do than the outside people have. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Draft Trademark Policy
On Fri, Aug 04, 2017 at 04:37:23PM +0200, Simon Poole wrote: > > * Section 2.1 forbids anything called something like "OpenThingMap". > > This form of name is very popular, there are numerous existing > > examples (OpenPOIMap, OpenTopoMap, OpenSeaMap, ...) Do all of these > > have to change their names? > Yes and this is one of the big sore points, but we are not asking most > of them to change there name, just to get licensed/permission in some > form. To show why: there used to be an OSM based project called I think it is totally unrealistic to expect hobby projects based on OSM to ask for permission. I see three likely outcomes: * Most people will not know about the policy or they don't care and they might choose a name that doesn't follow the policy. It takes a while for OSMF to find out about this, get organized, and ask for a license application or a name change. By that time the people are already attached to their name. This will generate bad blood, not to mention what you are going to do if the people ignore OSMF. * People who know about the policy choose a name that doesn't violate the trademark policy. But they are outsiders now. They will avoid to even mention OSM, they will not feel as part of the community any more. We have always argued that everybody who does something with OSM is part of the community, you don't have to be an OSMF member, you don't have to have your service running on OSMF servers. This great eco-system is in jeopardy if you alienate all those people. * You scare people away from doing anything OSM-related because they don't know and understand what they are allowed to do and what not. I can tell you that I will certainly not apply for a license/permission for any of my hobby projects. In the worst case license means lawyers and money, in the best case it means I have signed something that promises I behave in certain ways. What if I do something unwittingly that oversteps the permission in that license I got. What if I change a website I got the license for in some way, do I have to get re-licensed? Sure, all those things are less problematic in reality than they are in the real world. But for a hobby project I don't need this. And there is always something down the line that comes back to bite you. Some of my projects have Debian packages for instance, which for many years called their "Firefox" package "Iceweasel" because of Mozillas trademark policy. (They recently switched back to the name "Firefox", I don't know what changed.) And again the question of the practicality of all this: Even if people have to get licenses and actually do, we are looking at at least several hundreds of projects (There are nearly 3000 repositories on Github that have "openstreetmap" in their name or description). Can the OSMF even handle this? Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Draft Trademark Policy
On Thu, Aug 03, 2017 at 11:07:44PM +0200, Simon Poole wrote: > The LWG would like to start a period of public review and consultation > on our draft trademark policy, that we intend to bring forward to the > OSMF board for adoption as a formal policy, please see the text here: > > > https://wiki.openstreetmap.org/wiki/Trademark_Policy#OpenStreetMap_Trademark_Policy This is a very well-written document and the will to create a fair policy is clearly visible. But it immediately opens a whole slew of questions for me, many of them concerning my own projects. * Section 2.1 forbids anything called something like "OpenThingMap". This form of name is very popular, there are numerous existing examples (OpenPOIMap, OpenTopoMap, OpenSeaMap, ...) Do all of these have to change their names? * I have a written an open source software called "OSMCoastline" (among many others), this clearly contains the "OSM" abbreviation. The use of this software is very specific to OSM data. It doesn't make sense for this software not to have OSM in its name really so much is it tied to the OSM data. Can it keep this name? There is no mentioning of software in the policy at all. * I am running the website openstreetmapdata.com where people can download OSM-derived data and only OSM-derived data. Currently all services there are free, we are only asking for donations (and receive almost none). But I want to reserve the right to charge for services there. The character of this site is in between a community site and something commercial. It comes out of my engagement for OSM and the OSM community, but it is not something run by the OSMF or so. It is run by me and Christoph personally and we might want to move it more into the direction of a commercial enterprise in the future. I know I am not alone with this, there are many sites that are half-open, half-community, half-commercial. And that is, in my opinion a good thing, because it is a way for OSM enthusiasts to move to something where they can make some money with what they are doing and sustain their services. But it raises the question of where community ends and trademark licenses are needed. It is quite clear from the policy that I can not keep using that domain name. What is not clear to me is how I have to do the wording on that site to keep within the Trademark Policy? Lets say I changed the site name to megaawesomedownloads.com, what else would I have to do? All the data on there is 100% derived from OSM data. I don't want to invent any bugus "product names", when I offer "OSM coastline data" for download, that describes best what you can download. Is a website a "Publication" in the sense of the section 4.3? If such a policy is introduced, I would hope that the OSMF provides some proactive guidance to the many many people already doing good things based on OSM and help them get into compliance. I fear many people will rather stop offering their services instead of understanding the legal issues involved. This is especially important, because - from my limited understanding of trademark law - it is necessary to actually defend your trademarks if you want to keep them. So unlike the data license violations which the OSMF can ignore as much as it wants to without limiting what they can do in the future, the OSMF has to actually defend its trademark. So if the OSMF says that, say "OpenSeaMap" is not according to our policy, it HAS to fight it (even if nobody really minds them using this name) to make this stick. So just ignoring some violations and fighting others isn't possible. Which opens the whole question of whether the OSMF is organizationally and financially in a position to actually do this fighting? If not, why have this policy? Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
On Fri, Aug 04, 2017 at 12:46:56PM +0200, Kevin Hemker wrote: > > Ja, aber das muss eine Datenbank sein, die komplett alle Daten enthält. > > In den .osc-Dateien sind nur geänderte Objekte drin, nicht ungeänderte > > Objekte, die mit den geänderten zusammenhängen, wie es bei Nodes in Ways > > oder Ways in Relationen der Fall ist. > > > Verstehe ich das also richtig: Wenn an einem Way nur Tags geändert wurden > ist im .osc nur der Way mit den Tags, sowie den ID-Referenzen auf die Knoten > enthalten - die zugehörigen Nodes als solche fehlen aber, weil unverändert. > Wurde aber das Element in seiner Lage verändert, so sind neben den > Referenzen auch diejenigen Nodes komplett enthalten, die verschoben wurden? Jopp, das ist richtig. > > Aber eine allgemeine Empfehlung: Das OSM-Datenmodell ist komplex und das > > mit den Änderungen richtig hinzubekommen ist schwierig. Wenn es irgend > > geht, dann würde ich lieber einmal am Tag oder einmal die Woche einen > > kompletten Neuimport durchlaufen lassen oder so. Das macht es viel > > einfacher. > > > > Jochen > > Nach Erstsicht der augmented diffs teile ich diese Einschätzung; das > auseinanderzufriemeln wäre von der Performance her wahrscheinlich auch nicht > produktiver. > Allerdings ist ein kompletter Neuimport schon ein ziemlicher Overhead, > zurzeit ist die Updateroutine beim Projekt in PHP umgesetzt. > Für einen häufigeren Neuimport müsste ich mich dann wohl in C|Java > einarbeiten. Normalerweise ist der Bottleneck bei einem Datenbankimport der Import selbst, also die Datenbank bzw. der damit einhergehende I/O. Da macht es wenig Unterschied welche Programmiersprache Du verwendest. Um welche Daten geht es denn hier? So wie ich das verstanden habe, sind es ja nur ein paar POIs, die Du importieren willst, das sollte nicht wirklich sehr aufwändig sein. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
On Fri, Aug 04, 2017 at 10:54:49AM +0200, Kevin Hemker wrote: > Allerdings dachte ich, gerade die osmChange-Dateien sind geeignet > Datenbanken aktuell zu halten... Ja, aber das muss eine Datenbank sein, die komplett alle Daten enthält. In den .osc-Dateien sind nur geänderte Objekte drin, nicht ungeänderte Objekte, die mit den geänderten zusammenhängen, wie es bei Nodes in Ways oder Ways in Relationen der Fall ist. > Ziel ist, eine eigene MySQL-Datenbank (die Informationen über Poi vorhält) > zu aktualisieren. Ways (also typischerweise Gebäude) sind darin durch ihren > Mittelpunkt repräsentiert. Bisher habe ich dazu (testweise in kleineren > Gebieten) den csv-export von overpass genutzt (DB-Inhalte vorher gelöscht > und dann neu eingespielt), aber nun möchte ich das Gebiet ausweiten und die > DB entsprechend aktualisieren statt täglich komplett neu zu füllen. > > Um dabei nicht jeden einzelnen Änderungseintrag durch meine DB-Updateroutine > jagen zu müssen und dort zu prüfen, ob er überhaupt in die DB soll möchte > ich vorher schon filtern, was wesentlich performanter ist. Du kannst versuchen, auf die augmented diffs zurückzugreifen, die haben dann alle abhängigen Objekte in der alten und neuen Version drin. Aber eine allgemeine Empfehlung: Das OSM-Datenmodell ist komplex und das mit den Änderungen richtig hinzubekommen ist schwierig. Wenn es irgend geht, dann würde ich lieber einmal am Tag oder einmal die Woche einen kompletten Neuimport durchlaufen lassen oder so. Das macht es viel einfacher. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
On Thu, Aug 03, 2017 at 10:40:05PM +0200, Kevin Hemker wrote: > eigentlich ja keine große Sache, aber nach etlichen Stunden Verzweiflung > wende ich mich an euch und hoffe auf Hilfe: > > Ausgangspunkt: .osc-Datei vom osm-Server. Das Filtern soll folgendes > Ergebnis liefern: > > * keine Relationen mehr > * alle ways zu nodes konvertiert > * nur nodes behalten, die ein paar bestimmte keys haben. Eine .osc-Datei enthält zu einem Way nicht unbedingt alle Nodes, die in diesem Way sind. Daher wirst Du mit diesem Ansatz immer Probleme haben. Was willst Du denn am Ende erreichen? Wenn das Ziel ist, rauszufinden, wo es überall Änderungen bestimmter Art gegeben hast, dann reichen die .osc-Dateien nicht als Datenquelle aus. Du kannst Dir mal http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs anschauen, vielleicht hilft Dir das weiter. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-ca] Multipolygon problems
On Sat, Jul 01, 2017 at 09:52:48AM +0200, Jochen Topf wrote: > > How difficult would it be to add this to OSM inspector? Not everybody has > > Postgres running, and is able to use osm2pgsql. Yes, there is documentation, > > but it requires some technical skills. Also, it would be very convenient to > > have this updated daily. > > It is not that difficult to add to the OSM Inspector and if I have the > time I'll work on that together with the Geofabrik people. There is a new layer with this data now in the OSMI: http://tools.geofabrik.de/osmi/?view=areas=-64.28033=53.72207=8=same_tags_on_outer_ring You have to zoom in to at least zoom level 8 to see something. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Multipolygon problems
On Sat, Jul 01, 2017 at 04:04:25PM -0400, Stewart C. Russell wrote: > On 2017-07-01 04:30 AM, Frank Steggink wrote: > > > > To all, this is the procedure I used yesterday, and probably something > > similar also by Pierre. > > * Not sure if it is a requirement, but it's better to use 64 bit Java. > > … > > Thanks for this, Frank. I think I've found a way to make this a bit > quicker by loading a relation URL, then using your search query: > > > * Eventually JOSM starts looking cluttered, because of all the extra > > data. You can use the search query "type:way natural=wood role:outer" to > > see if there are still rings needing work. > > … then just deleting the ‘natural=wood’ from the selected ways. > > I hope I'm understanding the problem correctly*: outer ways in a forest > polygon relationship shouldn't have the ‘natural=wood’ tag? If that's > the issue, then this should just be an auto-edit, no JOSM and > pointy-clicky required. There is nothing specific about woods here. An outer way in a multipolygon relations should only have tags which apply to *that way* specifically, not tags which apply to the whole relation. The tags on the relation are for the polygon as a whole, the tags on the ways are for those ways. So if you have, say a wall surrounding a forest, you might have tags for that wall on the ways, but the forest tags belong on the multipolygon relation only. In most cases this simply means that there should be no tags on the ways at all. Of course you should still check all cases against sat images. For instance, sometimes the whole relation can be removed and just a simple closed way be used if there are no inner ways. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Multipolygon problems
On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote: > On 30-06-2017 21:21, Jochen Topf wrote: > > On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote: > > > Maybe I'm not understanding it, but in the OSM inspector [1] I just see > > > one > > > case of old style multipolygon, in Manitoba. Last week, when you posted > > > your > > > original message, I just saw one case in New Brunswick. IIRC, it was a > > > park, > > > not even from the Canvec import. > > The types of problems I am talking about don't show up in the OSM > > inspector. This is not old-style multipolygons (where tags are on the > > outer ways and not on the relation), but multipolygons where the tags > > are on the relation AND on the ways. > Ah, ok, now I understand. Since there was a lot of discussion about old > style multipolygon tagging, and since this type of problem hasn't been added > to OSM inspector, this wasn't immediately obvious. > > > In the OSM inspector other errors can be seen, but the most prevalent one > > > is > > > "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing > > > which seems urgent to me. > > > > > > Here is an example of a forest multipolygon, imported by me > > > (canvec_fsteggink). It is still version 1, but it has tags on the > > > relation, > > > not on the rings (except for the quarries): [2] > > > This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I > > > know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any > > > such > > > cases in the OSM inspector. > > > > > > So, I'd like to ask you to give a couple of examples where data imported > > > from Canvec is clearly wrong with regard to old style multipolygon > > > tagging. > > Here are all cases in Canada (not only those from the imports): > > https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf > > > > Here is one example where you can clearly see the problem: > > http://www.openstreetmap.org/relation/541821 > How difficult would it be to add this to OSM inspector? Not everybody has > Postgres running, and is able to use osm2pgsql. Yes, there is documentation, > but it requires some technical skills. Also, it would be very convenient to > have this updated daily. It is not that difficult to add to the OSM Inspector and if I have the time I'll work on that together with the Geofabrik people. > > > When we have clear examples, then it might be easier to come up with a > > > plan > > > how to fix it. But so far, I see absolutely no reason why Canada stands > > > out > > > in a negative way. Yes, we all acknowledge that Canvec data is suboptimal, > > > but as others already have pointed out, mapping everything by hand in > > > especially remote areas is nearly impossible. > > Canada stands out in a negative way, because > > a) there are so many problems. Nearly a third of the cases worldwide are in > > Canada and > > b) most of these problems are probably caused by one little program, the > > program used to convert/import the CanVec data. > As you might have noticed, later imports, like the example I provided, don't > have that issue anymore. I'm mentioning this to express that not _all_ > Canvec data is at fault! Only the first couple of versions. However, for > some reason this was never noticed up until a point that collaborative > action was done to have it fixed. Probably because the rendering pipeline of > the slippy map was accepting this kind of tagging up until recently. Okay, that is a big relief already. At least we are not making this problem worse by new imports that might happen in the future. > > Mapping Canada "by hand" might be difficult because it is such a huge > > country and there aren't that many mappers. But the same arguments goes > > for why you have to be extra careful importing data. If you break > > something, there are not enough people to fix it manually. And, yes, > > errors do happen. And if we find them, we fix them and move on. But > > errors from imports can be so huge there aren't enough people there to > > fix them manually. > The world is so huge that there aren't enough people to create and maintain > a global world map. However, OSM exists. Fixing errors can also be > crowdsourced. Martijn van Exel is really doing a great job with MapRoulette, > for instance. Although fixing errors (cleaning up the mess left behind by > others) is not nearly as rewarding as mapping, it might be easier to do, > especially
Re: [Talk-ca] Multipolygon problems
On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote: > Maybe I'm not understanding it, but in the OSM inspector [1] I just see one > case of old style multipolygon, in Manitoba. Last week, when you posted your > original message, I just saw one case in New Brunswick. IIRC, it was a park, > not even from the Canvec import. The types of problems I am talking about don't show up in the OSM inspector. This is not old-style multipolygons (where tags are on the outer ways and not on the relation), but multipolygons where the tags are on the relation AND on the ways. > In the OSM inspector other errors can be seen, but the most prevalent one is > "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing > which seems urgent to me. > > Here is an example of a forest multipolygon, imported by me > (canvec_fsteggink). It is still version 1, but it has tags on the relation, > not on the rings (except for the quarries): [2] > This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I > know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such > cases in the OSM inspector. > > So, I'd like to ask you to give a couple of examples where data imported > from Canvec is clearly wrong with regard to old style multipolygon tagging. Here are all cases in Canada (not only those from the imports): https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf Here is one example where you can clearly see the problem: http://www.openstreetmap.org/relation/541821 > When we have clear examples, then it might be easier to come up with a plan > how to fix it. But so far, I see absolutely no reason why Canada stands out > in a negative way. Yes, we all acknowledge that Canvec data is suboptimal, > but as others already have pointed out, mapping everything by hand in > especially remote areas is nearly impossible. Canada stands out in a negative way, because a) there are so many problems. Nearly a third of the cases worldwide are in Canada and b) most of these problems are probably caused by one little program, the program used to convert/import the CanVec data. Mapping Canada "by hand" might be difficult because it is such a huge country and there aren't that many mappers. But the same arguments goes for why you have to be extra careful importing data. If you break something, there are not enough people to fix it manually. And, yes, errors do happen. And if we find them, we fix them and move on. But errors from imports can be so huge there aren't enough people there to fix them manually. So I think it is the job of those who did the import in the first place, to fix their work. If you add data to OSM you take on a certain responsibility. If you add more data, you have a larger responsibility. But saying: We don't have the manpower, so we are taking a shortcut and then, when it turns out the shortcut wasn't so short after all, whining that you don't have the manpower to fix it. That can't be the excuse. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Multipolygon problems
Hi! A week ago I wrote this email and nobody answered it yet. Does that mean that nobody feels responsible for the import that created this data and nobody here cares for this data? I see three ways forward: * We do nothing. The broken data stays in OSM. Not a good solution, because every user of the data has to work around this or handle the complaints. * The Canadian community steps up and fixes the data, automatically or manually. * We ask the Data Working Group to remove the broken import. Jochen On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote: > Date: Thu, 22 Jun 2017 11:38:15 +0200 > From: Jochen Topf <joc...@remote.org> > To: talk-ca@openstreetmap.org > Subject: [Talk-ca] Multipolygon problems > > Hi! > > In the last days the OpenStreetMap Carto Style 4.0 is being deployed on > the OSMF tile servers. This new version of the style doesn't take > old-style multipolygons (where the tags are on the outer ways instead of > on the relation) into account any more. In a huge effort in the last > months we have converted all old-style multipolygons to the modern > tagging, so this is a good step! > > Unfortunately, as a side-effect of this change, many multipolygon > relations now appear wrong on the map. This is the case for multipolygon > relations that have the same tags on the relation as well as on (some of > the) outer or inner ways. This is *wrong* tagging, and needs to be > fixed. (Note that this always was wrong tagging, even before we > deprecated old-style multipolygons, but the way the software worked with > old-style multipolygons, this problem was not visible on the map. But > now it is.) > > Here is an example: http://www.openstreetmap.org/relation/1330741 . As > you can see (unless somebody fixes this :-) the clearing in the forest > that should just have grass, also has tree symbols on it. In many other > cases it is not this obvious, there are just islands in a river missing > or so. > > There are about 50,000 cases like this worldwide, forests, waterways, > all sorts of areas. But the worst problem is in Canada. There are about > 15,000 affected relations, most from the CanVec imports. > > First, we have to make sure that there are no further imports of broken > data. I hope the people who have done those imports (and might still > continue) are here on this mailing list. If not please make them aware > of this issue and/or put me in touch with them. Second, somebody needs > to clean up the broken data, either automatically or manually. 99% of > the data has not been changed since the import, so it might be feasible > to do an automatic cleanup, but somebody has to do this. Otherwise we'll > have to do a manual cleanup, through tools such as Maproulette and the > OSM Inspector. I am currently in the process of creating Maproulette > challenges for other areas of the planet, but will not do this for > Canada at this time. Lets discuss this here first. > > I can provide OSM data extracts, statistics, etc. if somebody wants to > look at the data. > > All of this is part of a larger effort to fix areas in OSM. See > http://area.jochentopf.com/ for more information. There is also a thread > on the talk mailinglist at > https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html > and this issue > https://github.com/osmlab/fixing-polygons-in-osm/issues/36 . > News of the effort are posted regularly to > https://github.com/osmlab/fixing-polygons-in-osm/issues/15 . > > Jochen > -- > Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-de] Elbe-Labe-Meeting 2017
Hi! Letztes Jahr hatten wir unser erstes Elbe-Labe-Meeting, dass Mitglieder der deutschen und tschechischen OSM-Community in Dresden zusammengebracht hat. Wir hatten Presentationen über Themen von Wanderkarten bis Auto-Navigation und viele interessante Diskussionen. Dieses Jahr planen wir etwas ein bischen anderes: Wir treffen uns in der Sächsischen Schweiz, einem Naturschutzgebiet, dass berühmt ist für seine Felsformationen und die vielen Wanderrouten, für ein Wochenende mit Wanderungen, Mappingaktionen, mit Gesprächen und generell allem rund um OSM. Der Spaß soll natürlich auch nicht zu kurz kommen. Wir haben ein Ferienhaus gemietet, das circa 20 Personen Platz bietet, Internet, Grill, und was man sonst noch so braucht, gibt es auch. Wikimedia Deutschland sponsort das Treffen, sodass es für die Teilnehmer kostenlos ist. Das Treffen findet vom 1. bis 3. September 2017 statt. Alle Details gibt es unter https://wiki.openstreetmap.org/wiki/Elbe-Labe-Meeting_2017 Wir laden alle OSMer ein, dabei zu sein. Da der Platz begrenzt ist, ist eine Vorregistrierung erforderlich. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-ca] Multipolygon problems
Hi! In the last days the OpenStreetMap Carto Style 4.0 is being deployed on the OSMF tile servers. This new version of the style doesn't take old-style multipolygons (where the tags are on the outer ways instead of on the relation) into account any more. In a huge effort in the last months we have converted all old-style multipolygons to the modern tagging, so this is a good step! Unfortunately, as a side-effect of this change, many multipolygon relations now appear wrong on the map. This is the case for multipolygon relations that have the same tags on the relation as well as on (some of the) outer or inner ways. This is *wrong* tagging, and needs to be fixed. (Note that this always was wrong tagging, even before we deprecated old-style multipolygons, but the way the software worked with old-style multipolygons, this problem was not visible on the map. But now it is.) Here is an example: http://www.openstreetmap.org/relation/1330741 . As you can see (unless somebody fixes this :-) the clearing in the forest that should just have grass, also has tree symbols on it. In many other cases it is not this obvious, there are just islands in a river missing or so. There are about 50,000 cases like this worldwide, forests, waterways, all sorts of areas. But the worst problem is in Canada. There are about 15,000 affected relations, most from the CanVec imports. First, we have to make sure that there are no further imports of broken data. I hope the people who have done those imports (and might still continue) are here on this mailing list. If not please make them aware of this issue and/or put me in touch with them. Second, somebody needs to clean up the broken data, either automatically or manually. 99% of the data has not been changed since the import, so it might be feasible to do an automatic cleanup, but somebody has to do this. Otherwise we'll have to do a manual cleanup, through tools such as Maproulette and the OSM Inspector. I am currently in the process of creating Maproulette challenges for other areas of the planet, but will not do this for Canada at this time. Lets discuss this here first. I can provide OSM data extracts, statistics, etc. if somebody wants to look at the data. All of this is part of a larger effort to fix areas in OSM. See http://area.jochentopf.com/ for more information. There is also a thread on the talk mailinglist at https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html and this issue https://github.com/osmlab/fixing-polygons-in-osm/issues/36 . News of the effort are posted regularly to https://github.com/osmlab/fixing-polygons-in-osm/issues/15 . Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-de] osmconvert und nested relations
On Fri, Jun 16, 2017 at 11:04:27AM +0200, Christoph Hormann wrote: > On Friday 16 June 2017, Jochen Topf wrote: > > > > Es gibt da eine Tendenz immer komplexere Dinge zu mappen, ohne dass > > irgendwer diese Daten auch sinnvoll nutzt. Auf der einen Seite ist es > > ja gut, wenn wir mehr Details und mehr Zusammenhänge erfassen, weil > > nur Daten, die da sind, auch genutzt werden können. Aber auf der > > anderen Seite schreckt die Komplexität doch die Entwickler ab. > > In diesem Fall gibt es ein recht klares (wenn auch nicht immer einfach > bestimmbares) Kriterium: Wenn es für den Entwickler einfacher ist sich > den Zusammenhang aus den übrigen Daten herzuleiten, sollte man > gewöhnlich auf die Erfassung verzichten. In diesem Fall ist role > admin_centre von der Bedeutung äquivalent mit > capital=yes/capital= auf dem entsprechenden Element. Und > da der Entwickler letzteres aufgrund der Unvollständigkeit der > admin_centre eh auswerten wollen wird ist das Ganze am Ende meist > ziemlich überflüssig. > > Ansonsten ist das "denkt denn niemand an die armen Entwickler"-Argument > mit Vorsicht zu genießen, wenn die Bequemlichkeit der Entwickler über > die Bequemlichkeit der Mapper gestellt wird und dem Mapper sinnlose > Arbeiten aufgedrückt werden nur weil der Entwickler sich keine Arbeit > machen möchte oder seine Arbeit teurer ist als die des Mappers (was > insbesondere bei OSM ein sehr verbreitetes Problem ist). Es wäre ja schön, wenn wir die Arbeit der Mapper und der Entwickler irgendwie verrechnen könnten und schauen, was "unterm Strich" am effizientesten ist oder so. Das könnte man machen, wenn OSM eine Firma ist, die ihre Leute passend einteilen kann. Aber so ist das halt nicht. Das Problem ist ein anderes: Der Mapper denkt, sein komplexes Mapping würde auch magisch irgendwie verwendet. Es erscheint auf der Karte oder ist findbar im Nominatim oder wird beim Routing verwendet. Das ist aber häufig nicht der Fall. Wir sind meilenweit hinten dran mit der Entwicklung. Es gibt wahnsinnig viele Sachen, die theoretisch vielleicht möglich wären, die praktisch aber nicht funkionieren. Vielleicht gibts sogar Versuche hier oder dort, aber praktisch ist das, was wir von den OSM-Daten wirklich nutzen, ziemlich klein. Dadurch fehlt hier aber ein ganz wichtiges Korrektiv: Klassisch ist das so, dass der Mapper sich auf das stützen kann, was auf der Karte erscheint. Mapper mappen solche Sachen konsistent und qualitativ einigermaßen gut, wo sie das Ergebnis anschauen können. Ob das nun gut ist oder nicht, Mapper orientieren sich an der Karte (und auch an der Visualisierung der diversen Tools zur Qualitätssicherung). Aber da, wo es diese "guidance" durch solche Karten und Tools nicht gibt, gibt es einen unglaublichen Wildwuchs. Der Wildwuchs ist gut, wenn aktiv in dem Bereich etwas voran geht. So kann man nämlich verschiedene Dinge ausprobieren und dann das, was am besten funktioniert, systematischer umsetzen. Dazu braucht es aber irgendwen, der die Daten auch nutzt und sagt, was funktioniert und was nicht. Und das fehlt halt in vielen Bereichen. Beim public transport z.B. ist diese "Diskussion" noch voll im Gange, da bewegt sich was und neue Dinge werden probiert. Aber in ganze vielen anderen Bereichen, gerade was komplexe Relationen angeht, da passiert das nicht. Damit OSM als System funktioniert, das sich fortentwickelt und praktische Lösungen liefert, braucht es beides. Die Mapper, die Daten sammeln und erfassen und die Nutzer, die aus den Daten etwas machen. Aus dieser Zusammenarbeit entsteht eine nützliche Datensammlung. Fehlt das eine oder das andere, dann geht es nicht voran. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osmconvert und nested relations
On Fri, Jun 16, 2017 at 11:22:12AM +0200, dktue wrote: > vielen Dank für den Hinweis bezüglich der Relationen: In der Tat handelt es > sich beim der Grenze nicht um eine geschachtelte Relation sondern um eine > einfache Relation mit ausschließlich Ways als Mitgliedern. > > Ich habe folgenden Test gemacht: Ich habe die Daten der Regierungsbezirks > Tübingens heruntergeladen [1] und mit osmconvert und folgendem Parameter > geschnitten: > > osmconvert.exe tuebingen-regbez-latest.osm.pbf > -b=9.07966,48.50007,9.08387,48.50192 --complex-ways -o=test.osm > > Ich hätte erwartet, dass in der Ausgabe-Datei die vollständigen Grenzen von > Tübingen und Kusterdingen enthalten sind. Das ist aber leider nicht der > Fall. Ich weiss nicht genau, wie osmconvert das handhabt. Bei osmium kann man einstellen, welche Relationen man vervollständigt haben möchte. Siehe http://docs.osmcode.org/osmium/latest/osmium-extract.html . Normalerweise werden nur multipolygon-Relationen vervollständigt, aber man kann auch sagen, dass das auch für die Grenzen gelten soll. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osmconvert und nested relations
On Fri, Jun 16, 2017 at 10:02:58AM +0200, Martin Koppenhoefer wrote: > > On 14. Jun 2017, at 19:07, Michael Reichert <osm...@michreichert.de> wrote: > > > > Grenzenrelationen referenzieren keine anderen Relationen. Die einzigen > > anerkannten Mitglieder sind > > - Ways mit der Rolle outer > > - Ways mit der Rolle inner > > - Ways ohne Rolle (der Auswerter darf dann raten) > > - 1 Node mit der Rolle admin_centre > > - 1 Node mit der Rolle label > > > > gibt es einen Grund, als admin_centre nur nodes zuzulassen? Wieso keine place > polygone? Die Frage wäre hier erstmal: Wer macht eigentlich was mit diesen Daten? Es gibt da eine Tendenz immer komplexere Dinge zu mappen, ohne dass irgendwer diese Daten auch sinnvoll nutzt. Auf der einen Seite ist es ja gut, wenn wir mehr Details und mehr Zusammenhänge erfassen, weil nur Daten, die da sind, auch genutzt werden können. Aber auf der anderen Seite schreckt die Komplexität doch die Entwickler ab. Nun macht es das Leben eines Entwicklers nicht wirklich schwieriger, ob es 10 verschiedene Typen von Shops gibt oder 100 oder 1000. Aber komplexe Relationen auswerten, das ist schwierig und kann selbst bei kleinen Änderungen erhebliche Auswirkungen haben. Da muss man schon viel genauer hinsehen, was sinnvoll ist und was nicht. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Old-style multipolygon cleanup is done!
Hi! The old-style multipolygon relations are history! In not even two months the OSM community cleaned up all of the nearly a quarter million relations. You can see the it here: http://area.jochentopf.com/stats/#old_style_multipolygons This is much faster than I (and probably everybody else) had anticipated. There are a few old-style multipolygons around, some of them have no members at all, some only relation members (which isn't allowed for multipolygon relations) and some have been created in the last days. I expect that we will get new ones occasionally from editors and/or mappers who don't know yet, that they shouldn't do that, but that's not a big problem. So that part of the great (multi)polygon fixing effort is done. Huge thanks to everybody involved! But there are still geometry errors to fix. Find more information here: http://area.jochentopf.com/ Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Fixing Multipolygons
Hi! On Fri, Apr 21, 2017 at 02:19:25PM -0400, Kevin Kenny wrote: > How current is the information behind your map? I've been tidying some > multipolygons locally, and they seem to be rendering only on the left side. > I don't think I've actually broken anything. If it might be more than a > couple of weeks old, then I can explain that it's simply rendering old, bad > data. The map data is updated continuously from minutely diffs, but the map tiles weren't expired automatically, so you might well have been seeing old data. I have added a daily expiry now. The overlay with the red multipolygon outlines is updated and the tiles expired daily. If you still see discrepancies, check the OSM Inspector http://tools.geofabrik.de/osmi/?view=areas . If it reports any problems, fix those. Then, if there are still problems, email me or open an issue at https://github.com/osmlab/fixing-polygons-in-osm/issues with specific information about the OSM objects that are rendered incorrectly. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Fixing Multipolygons
Hi! as some of you might have seen we have a huge effort going on to fix broken multipolygons and re-tag old-style multipolygons (those where the tags are on the outer way(s) instead of on the relation) into the current style. You can read all about it on http://area.jochentopf.com/ . As you can see on the map at http://area.jochentopf.com/map/index.html most of the old-style multipolygons now left are from some large-scale imports, including some in the US. We need your help in cleaning this up! I you have any questions, don't hesitate to ask. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-ko] Broken (multi)polygons in Korea
On Sun, Mar 19, 2017 at 02:46:30PM +0100, Jochen Topf wrote: > in my newest batch of Maproulette challenges, I have included a special > challenge for Korea, because there were so many problems there. > > I encourage everbody to help: > http://area.jochentopf.com/fixing.html#duplicate-segments-in-closed-ways That challenge has been done for a while. But there is much more to do. The problems include self-intersections, overlapping areas, and other problems, mostly on forest and other landuse polygons. The problems are too dense to fix using Maproulette. See here on how to fix this... http://area.jochentopf.com/fixing.html#fixing-multipolygons-in-south-korea Would be great if some people on this list want to take this on! Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-ko mailing list Talk-ko@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ko
Re: [OSM-talk] multipolygon source tags preferred method
On Mon, Mar 27, 2017 at 10:41:38AM +0200, Jochen Topf wrote: > On Mon, Mar 27, 2017 at 03:56:43PM +1000, nwastra wrote: > > I am unsure what is the preferred way or best practice to tag the source > > for multipolygons. > > I currently put the source on the relation with all the rest of the tags, > > and only adding tags to individual ways or inner polygons if they are also > > part of a seperate entity like a fence or a body of water. I also include > > the source with the uploaded change-set. This would seem to be ok when > > adding a new mp relation. > > > > Should the source also be added to all the individual ways that make up the > > outer and inner boundaries of each polygon? > > Is this also the preferred way when adding a new large mp relation that > > does not currently exist? > > > > When replacing individual ways or splitting and altering part of a way with > > updated data, adding the new source tag to those new ways would seem best > > practice or is it sufficient to added the source to the change-sets alone? > > > > Is the most sensible way to initially add the source tags to the relation > > and change-set upload alone and from then on as individual parts are > > amended, to add the source to just the updated/corrected ways and the > > change-set on upload? > > > > I have not come across guidance for this on the wki yet. > > Putting the sources on the objects has been deprecated for a while. The > source should be put on the changeset only. If you are doing edits that > involve several different sources, it is best to split the changes up > into different changesets. Of course this is not always possible, then > you can also put several sources in the changeset source tag. > > Adding the source to the objects was deprecated, too fined-grained > source tagging simply doesn't make much sense. We can not track every > source for every node, way, or relation or the parts of them for every > tiny change that somebody does. In the end most data will have multiple > sources and figuring out what came from what can only be done going > through the changeset tags, not by looking at the tags on the data > itself. I probably shouldn't have used the word "deprecated", because there is no mechanism in OSM do deprecate anything. This is more "common practice" really. Martin has already described why source tags on objects don't work well. In theory they might or might not be a good idea, but in practice we have seen in OSM that they don't work. The source tag is just not updated in a way that makes it useful. Since we introduced changesets, we can do better: We put the actual data into OSM objects, but the meta-data that describes the why and how of the mapping we put into the changesets. (I didn't know that iD doesn't allow you to set the source on the changesets as somebody mentioned. If that is true, I see this as a shortcoming of iD that should be fixed.) This has the added benefit of putting the meta-data that is seldomly used on the changesets keeping the actual OSM objects lean and mean. Now regarding the splitting up of changesets for different sources. If you are doing different things this absolutely makes sense and, I would argue, is even necessary to be able to add good changeset comments, which you should always do. So if you come back from a mapping survey and add the data you collected outside with source "survey" and then go to a different part of the planet and add a few things from "bing", those should be two changesets. Of course, if you add the geometry of a road from Bing and the name from your survey, it makes total sense to add the source "bing;survey" or something like it. As always, there are few hard-and-fast rules in OSM. That's good because everbody can decide for themselves which arguments they find convincing and which advice to follow. So if you want to keep adding "source" tags, that's fine, too. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon source tags preferred method
On Mon, Mar 27, 2017 at 03:56:43PM +1000, nwastra wrote: > I am unsure what is the preferred way or best practice to tag the source for > multipolygons. > I currently put the source on the relation with all the rest of the tags, and > only adding tags to individual ways or inner polygons if they are also part > of a seperate entity like a fence or a body of water. I also include the > source with the uploaded change-set. This would seem to be ok when adding a > new mp relation. > > Should the source also be added to all the individual ways that make up the > outer and inner boundaries of each polygon? > Is this also the preferred way when adding a new large mp relation that does > not currently exist? > > When replacing individual ways or splitting and altering part of a way with > updated data, adding the new source tag to those new ways would seem best > practice or is it sufficient to added the source to the change-sets alone? > > Is the most sensible way to initially add the source tags to the relation and > change-set upload alone and from then on as individual parts are amended, to > add the source to just the updated/corrected ways and the change-set on > upload? > > I have not come across guidance for this on the wki yet. Putting the sources on the objects has been deprecated for a while. The source should be put on the changeset only. If you are doing edits that involve several different sources, it is best to split the changes up into different changesets. Of course this is not always possible, then you can also put several sources in the changeset source tag. Adding the source to the objects was deprecated, too fined-grained source tagging simply doesn't make much sense. We can not track every source for every node, way, or relation or the parts of them for every tiny change that somebody does. In the end most data will have multiple sources and figuring out what came from what can only be done going through the changeset tags, not by looking at the tags on the data itself. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons, some notes
On Mon, Mar 20, 2017 at 07:15:47AM +0100, Jochen Topf wrote: > On Mon, Mar 20, 2017 at 06:27:05AM +0100, Andreas Vilén wrote: > > It's not up to me to decide if this data is to be deleted or not. If > > you want to do that, raise the question with each respective country's > > mailing list. > > I was under the impression that were in contact with the Swedish ^you > community on this topic and that the Swedish community had decided they > wanted to keep the data. So I thought this issue was settled. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons, some notes
On Mon, Mar 20, 2017 at 06:27:05AM +0100, Andreas Vilén wrote: > It's not up to me to decide if this data is to be deleted or not. If > you want to do that, raise the question with each respective country's > mailing list. I was under the impression that were in contact with the Swedish community on this topic and that the Swedish community had decided they wanted to keep the data. So I thought this issue was settled. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Broken multipolygons in South Korea
Hi! As you might know, I am on a "quest" to rid OSM of broken (multi)polygons. (See http://area.jochentopf.com/ for info about that and https://github.com/osmlab/fixing-polygons-in-osm/issues/15 for the news about that effort). I noticed a huge number of problems in South Korea, probably related to some kind of import. I have taken those out of the challenges I am generating, because I wanted to contact the OSM community there first. Anybody here who has connections to South Korea and/or knows about what's going on there? Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On Sat, Mar 04, 2017 at 11:03:26AM +, molto...@gmail.com wrote: > You should also look out for MPs with tags on the outer ring but > should actually only be on the realtion. Having the same tags on inner > and outer is a nice heuristic that QA tools detect, but is not the > only way that old-style polygons (which AFAIU wont be supported by > osm2pgsql at some stage) can happen. I do. https://github.com/osmlab/fixing-polygons-in-osm/blob/master/doc/problems.md#old-style-tagging http://area.jochentopf.com/stats/#old_style_multipolygons Same tags on inner and outer is just a subset of the old-style polygons. Currently I am concentrating on actually broken polygons, the old-style polygons are next and I will create challenges for them, too. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On Sat, Mar 04, 2017 at 10:50:41AM +0100, Martin Koppenhoefer wrote: > > On 4 Mar 2017, at 08:49, Jochen Topf <joc...@remote.org> wrote: > > > > Looking at the graphs on http://area.jochentopf.com/stats you can see > > that the number of (multi)polygons is growing steadily, while the number > > of errors has been more or less flat over the last half year. > > > nice stats and good results. > I want to point out though that " > Errors: Inner rings with same tags as outer rings" > > are not necessarily errors, and should not be "fixed" unless you know > very well the situation and can tell that there's indeed a > redundancy/data problem. E.g. you can have a building or building:part > inside another building or building:part. These could be tagged still > "incompletely" hence having just the same tags for the moment but be > different objects nonetheless. Similarly woods inside woods, etc. "Inner rings with same tags as outer rings" is a subset of old-style multipolygons. Well, as you correctly point out, some of them might be okay, but most of them are especially "bad" cases of old-style multipolygons. And they are another good reason why we need to get rid of old-style multipolygons. There is just no way to figure out automatically, what's right here and what's not. So humans have to fix those. I'll create Maproulette challenges for these too at some point. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
Hi! You all have been very busy fixing my challenges, so here are some more: http://area.jochentopf.com/fixing.html#self-intersecting-polygon-ways I have started to keep an ongoing "blog" where I'll post news and information about the effort to fix the (multi)polygons: https://github.com/osmlab/fixing-polygons-in-osm/issues/15 Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On Fri, Mar 03, 2017 at 05:27:18PM +0100, Sebastiaan Couwenberg wrote: > On 03/03/2017 05:10 PM, m...@rtijn.org wrote: > > Since the ‘self-intersecting’ challenge is now complete I featured the > > ‘Wrong role’ challenge in MapRoulette. Happy fixing! > > Are there plans to make these challenges permanent or periodically > re-introduce them when a new batch of issues has been prepared? No plans yet. My current focus is to get rid of all the old cases. Once that is (mostly) done, we can see how things develop. > These are very common issues that will be introduced by mappers in the > future. Looking at the graphs on http://area.jochentopf.com/stats you can see that the number of (multi)polygons is growing steadily, while the number of errors has been more or less flat over the last half year. So either there are not a significant amount of new problems or old problems are being fixed as fast as new problems are introduced. Both leads me to believe that existing QA tools and/or better editors than we had historically keep this problem in check. But, as I said, we'll first need to get the number of errors down to low level and see how things look then. And maybe when there are less cases we can better see specific problems creeping up that can be solved by improving editors etc. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On Fri, Mar 03, 2017 at 09:07:37AM -0800, Clifford Snow wrote: > I noticed a number of riverbanks with self-intersecting ways in the PNW > that appear on OSMI. How do I go about creating a challenge to fix them? The challenges I have posted recently are only the beginning. I have more challenges in the works that will cover all multipolygon problems. This is just a matter of me rolling out those challenges a few at a time so the community can concentrate on one problem before tackling the next one. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Spam reporting
On Thu, Feb 23, 2017 at 10:16:13AM +0100, Frederik Ramm wrote: > On 02/23/2017 09:56 AM, joost schouppe wrote: > > feed or inbox, but spam that you actually have to search for is maybe > > not a top priority that admins should dedicate time to removing? > > > > Well the annoyance with spam does pop up often enough. The usual answer > > to things like this in the OSM ecosystem is "why don't you do it > > yourself". I've not seen this answer for spam. Is there no easy way for > > people to become spam-police if they like to do so? > > Becoming "spam-police" would require the privilege to close any account > and hide/delete the account profile. This is not a privilege that I > would like to hand out lightly to someone who likes being police, > especially since over-eager "spam-police" have mis-identified genuine > user profiles in foreign languages as spam in the past. Every larger system that allows user contributions has a "report this as spam" button. If a few people click on that, an admin reviews and handles this. Sounds like an obvious solution that could also work for OSM. Not being able to report problems is frustrating to users. The whole question of who decides what is spam and what isn't is a bit besides the point here, isn't it? Obviously somebody is already handling this as you mention and it works. But what would help is a nice button. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On Tue, Feb 21, 2017 at 07:44:18PM +0100, Sebastiaan Couwenberg wrote: > On 02/21/2017 05:40 PM, Jochen Topf wrote: > > Find all challenges and instructions here: > > http://area.jochentopf.com/fixing.html > > My OCD complains about the typo before the challenge links, please do > > sed -i 's/Got to /Go to/g' fixing.html > > Also the Maproulette paragraph is no longer accurate now that more than > one challenge has been created. Fixed. Thank you! Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On Wed, Feb 15, 2017 at 04:20:53PM +0100, Jochen Topf wrote: > There are a lot of (multi)polygons in OSM that are broken in one way or > another. And we have to fix them. While some of the broken ones appear > on the map just fine, some don't appear and some mess up the map. And > some of those that appear fine on the main OSM map will not show up on > other maps where different software is used. > [...] A week later and most of the errors I posted in those Maproulette challenges have been fixed. Thank you! You can see the error numbers trending down at http://area.jochentopf.com/stats/#intersections But there is much more to do... I posted two new challenges, one with landuse polygons with self-intersections very similar to the challenges posted last week and mostly easy to fix. The other contains "open rings", multipolygon relations where the polygon boundary doesn't form a closed ring. Some of them are a bit trickier to fix. Find all challenges and instructions here: http://area.jochentopf.com/fixing.html Keep up the good work! Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On Sat, Feb 18, 2017 at 01:10:13PM +0200, Tomas Straupis wrote: > >> There are literally hundrets of building which have 4 edges as nodes > >> but them beeing connected over cross so that a construct like a > >> butterfly resembles. > > > > Any chance of a link to an example? > > I guess Florian ment geometries like this: > http://www.openstreetmap.org/way/460032394 > > There are indeed plenty of these in "less populated" areas, > especially areas with round buildings... Probably the result of some HOT mapping thing done by inexperiences mappers... Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maproulette problems?
On Sat, Feb 18, 2017 at 09:48:08AM +0100, Maarten Deen wrote: > Is the back-end of Maproulette offline? I can access the site, I can see the > challenges and the metrics, but when I want to start a challenge I only get > to see the OSM map in my neighborhood and it doesn't assign a task. It does work for me currently. But the effect you describe is what you see when a challenge is finished. Try a different challenge. > Also: there is no contact information? Is this the best way to get in > contact with the makers? You can open an issue on https://github.com/maproulette/maproulette2 . I just opened an issue there to say that there is no contact info. :-) Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On Sat, Feb 18, 2017 at 07:50:07AM +0100, Oleksiy Muzalyev wrote: > On 15.02.17 23:51, Sarah Hoffmann wrote: > > ... we are > > currently discussing about changing the algorithm that assembles the > > polygons[1]. The new algorithms will be a lot faster but that comes > > at the price that it is less tolerant with invalid geometries. A lot > > of bad geometries that are currently still drawn some way or another > > will be simply dropped. I'm convinced that in the long run this > > stricter handling will be good not only for data consumers but also > > for mappers, who will see immediately when they made a mistake. > > ... > > > Hi, > It would be a good idea to generate automatically a message to an author or > authors of this geometry asking them to fix it, explaining shortly what an > error they committed, and informing them that it would be deleted, if they > do not fix it. And if there is no reaction after a tolerance period of say > one week, then drop it automatically. Most multipolygons we are talking about here haven't been touched in years. So this doesn't really apply. Most of this is about cleaning up the backlog. If you look at the stats on http://area.jochentopf.com/stats/ you'll see that the number of (multi)polygons is growing constantly, but the number of errors is not. This tells me that it is mostly a problem with old data. We could inform authors when new problems are coming up, but I suspect that this is very difficult. For one, there can be several people involved and you don't know which fault is was. Then there is the question of what to tell the user. If you send them an email "Your multipolygon id 1234567 is broken", that is not very helpful for them. We need at a minimum some guidance on how to fix things. But this depends at least on the editor used, the language of the user, the type of problem and the skill level of the user. Ugh. > Deleting objects from the map without a warning may cause suspicions and > misunderstanding. For example, there are areas mapped as > boundary=protected_area or landuse=nature_reserve , but local fishermen who > want to continue fishing in the area may not like it, or at least have > doubts about its shape. By deleting a Nature Reserve from the map the script > may inadvertently interfere into a balance situation. This is why we are having this discussion. We do not want to remove anything from the map lightly. We are doing this only after taking any measure we can to fix those cases. In the long run the situation will get better, because at the moment some of those "critical" polygons you are talking about might not show up or show up wrong on the map because of the errors they contain that the renderer is trying to fix and doing so in the wrong way. We are doing all this to improve the accuracy of the map! Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On Fri, Feb 17, 2017 at 11:11:12AM +0100, Christoph Hormann wrote: > On Friday 17 February 2017, Andreas Vilén wrote: > > > > We are aware of the Corine import problems and have discussed them > > locally at least in Sweden. Our community is very loose with not much > > activity in mailing lists or other media, but so far consensus has > > been not to remove Corine if it's not replaced by improved data. > > > > I have done some cleanup myself mostly around Kalmar, but in the huge > > Northern parts of the country it seems unmanagable. Some users have > > made good progress in the Bergslagen area though. > > Well - the question you should probably ask yourselves is if this data > is of any help when you map in these areas. I find it doubtful that it > is and areas like here: > > http://www.openstreetmap.org/#map=13/56.7935/16.0168 > > support this impression. IMO it would be a good idea to concentrate on > what you gain and not too much look at what you loose. > > If there are worries in the local community about how to efficiently map > large wooded areas there are other methods that would be much better > suited. Forests can be positively detected on multispectral imagery > with good reliability - in contrast to land cover classification data > sets like Corine which essentially only specify the least unlikely of a > fixed set of classes. Producing a conservative data set this way (i.e. > one that only includes area which are clearly wooded), splitting this > into reasonably small chunks and providing this to mappers to avoid the > need for a lot of large scale tracing work seems a much more productive > way and much more compatible with normal manual mapping in OSM. Lets not get this thread hijacked by theoretical ideas about how to detect wooded areas. This thread is about broken multipolygons. The issue at hand here is that there are a lot of broken multipolygons out there. Some are probably from Corinne data. Now there are these options: a) Do nothing. Broken MPs will disappear once osm2pgsql switches. b) Remove existing MPs and start from scratch. c) Repair existing MPs. From some of the posts in this thread, c) doesn't seem to be a good option. Both a) and b) will result in those MPs disappearing from the map first, before things get better. In the case of a) they will all disappear one day, but the broken data is still there. In the case of b) we can go through them and replace them by better data piece by piece. I am willing to talk with the Swedish community (or any other) about how best to approach this. I can generate special Maproulette challenges for specific areas, in fact I think this is a better way then having generic challenges for the whole world. If you work on such a challenge, you might be thrown from an error in Borneo to one in Sweden to one in Antarctica. And the problems are different everywhere. I'd rather have more specific challenges addressing exactly one problem, for instance "Broken multipolygons of certain types of landcover data imported from Corinne in Sweden". That is something I can extract from OSM data and that I can explain to people how to fix after consulting with local mappers on how best to do this. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Fixing broken multipolygons
There are a lot of (multi)polygons in OSM that are broken in one way or another. And we have to fix them. While some of the broken ones appear on the map just fine, some don't appear and some mess up the map. And some of those that appear fine on the main OSM map will not show up on other maps where different software is used. A while ago I set up a web page at http://area.jochentopf.com/ and a Github repository at https://github.com/osmlab/fixing-polygons-in-osm devoted to that issue that I never announced properly. Go there and read up in more detail where the problems are and how we are going to fix them. Yesterday I launched several Maproulette challenges that allow you to easily help with the "cleaning up" effort. Read http://area.jochentopf.com/fixing.html for more details on those Maproulette challenges. This is a huge effort that will take a long time and we really need any help we get. The challenges posted today are only the beginning. They only show the about 6,500 ways worldwide tagged as buildings (with less than 100 nodes) where the way intersects itself. I have decided to start with a simple problem like this, to learn how the Maproulette stuff works and how well, you, the community, responds. Especially for beginners fixing those building is much easier than starting with 10,000 node multipolygons with possibly multiple errors in them. (If you want to, you can still do that. All multipolygon errors show up in the OSM Inspector areas view at http://tools.geofabrik.de/osmi/?view=areas ) Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Taginfo detecting wiki problems
Hi! every night when the taginfo update runs, taginfo parses changed key, tag, and relation type pages from the wiki and incorporates the information it finds into the taginfo database. And it finds lots of problems while doing that. Some are the fault of the taginfo parser, which is far from perfect. But many are the result of some error in the wiki. You can see the report here and use it to find and fix problems in the wiki: https://taginfo.openstreetmap.org/taginfo/wiki-problems A description of the messages seen is here: https://wiki.openstreetmap.org/wiki/Taginfo/Parsing_the_Wiki Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Taglists support for rendering examples
On Wed, Nov 09, 2016 at 07:09:05PM +0100, Jochen Topf wrote: > I have opened an issue: > https://github.com/gravitystorm/openstreetmap-carto/issues/2430 Thanks, nebulon42, for fixing this. Everybody encountering problems with the icons can now simple re-import them into the wiki. There is nothing in the way now to create great semi-atomatic taglist. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] addr:interpolation and data consumers
On Sun, Nov 20, 2016 at 05:47:28PM +0100, nebulon42 wrote: > I have written an address QA script for Austrian addresses. Now I'm > asked to support addr:interpolation. While the script is specific to > Austria the more general problem of addr:interpolation is not. > > In my opinion addr:interpolation is of little value for data consumers. > Personally, I prefer addresses on nodes or buildings where the location > of the address is clear. addr:interpolation rather leaves this open. I > know that addr:interpolation is an established tag, but the Wiki also says: > > "As long as we don't have a node or building outline for each > house(number) along a way, it's also possible to use automatic number > interpolation." > (https://wiki.openstreetmap.org/wiki/Addresses#Using_interpolation) > > For me that sounds like: use it until there is something better/more > accurate. I tend to replace addr:interpolation with addresses on nodes > or buildings when I see them and more accurate data is available. You have exactly the right interpretation here. Interpolation was only intended as a way to get going quickly and easily with lots of addresses. And it has another use: Some non-OSM data sources use a format where a "street" has attributes giving the house number range on the left and right side. This can be reasonable easily be transformed into the addr:interpolation format for importing that data into OSM. It is here like with everything in OSM: There is a trend towards more detail. If you have more detailed information, great. If not, it is better than nothing. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] leaky coastline, auckland?
On Fri, Nov 18, 2016 at 01:43:09PM +1300, Robin Paulson wrote: > i've had a coastline problem for a few weeks now, i can't figure out what it > is, perhaps someone here can help. > > when i view osm data in osmand, i get a lot of leaks around the waitemata > harbour in auckland, new zealand: land rendering as sea/sea rendering as > land. the data is up-to-date, i am currently using osmand's new "live" > service. > > apparently contradictory to that, geofabrik's coastline checker says > everything is fine, and the osm mapnik render on osm.org also works fine. > any suggestions what might be going wrong, or other checkers i might use? If the OSM Inspector says, the coastline is okay, it most likely is. The coastline check is very picky. Sounds like a data problem in Osmand to me. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Taglists support for rendering examples
On Sun, Nov 06, 2016 at 03:44:56PM +0100, Jochen Topf wrote: > On Sun, Nov 06, 2016 at 02:22:26PM +0100, nebulon42 wrote: > > Both notations are correct and I have deliberately chosen the latter > > one. The first one may be the right one for the problem you are trying > > to solve. For the problems I wanted to solve the latter one was the > > right one. > > Can you elaborate? What was your problem? Maybe we can find a solution > that works for everybody? I have opened an issue: https://github.com/gravitystorm/openstreetmap-carto/issues/2430 Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Taglists support for rendering examples
On Sun, Nov 06, 2016 at 02:22:26PM +0100, nebulon42 wrote: > Both notations are correct and I have deliberately chosen the latter > one. The first one may be the right one for the problem you are trying > to solve. For the problems I wanted to solve the latter one was the > right one. Can you elaborate? What was your problem? Maybe we can find a solution that works for everybody? Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Taglists support for rendering examples
Hi! I have now added support to taginfo for showing an example rendering in the taglists on the wiki. If the "osmcarto-rendering" field in the KeyDescription or ValueDescription info box template is set to an image link (typically something like "Image:foo.svg" or "File:foo.svg"), this image will show up in taglists if the taglists have the "with_rendering=true" parameter. A detailed explanation is at: https://wiki.openstreetmap.org/wiki/Taginfo/Taglists Note that the "osmcarto-rendering-size" setting in the infobox is not used. That setting is really not neccesary if the icons have been written in the right way. If you look into the SVG of the icons you'll see the difference: The correct SVG looks something like this: The incorrect SVG looks something like this: So you have to explicitly set the right size. This is a common problem with many icons and they should be fixed in the original repository at https://github.com/gravitystorm/openstreetmap-carto and then re-imported into the Wiki. (And yes, it would make sense if we didn't have to copy the images into the wiki, but there are more issues with that. I am trying to do the next step here, not change everything in one go.) With this change the taglists can be made to look exactly like the old, manually created ones (for instance on the MapFeatures page). Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
On Sun, Oct 02, 2016 at 08:54:09AM +0200, Martin Koppenhoefer wrote: > > Il giorno 01 ott 2016, alle ore 16:23, Paul Norman <penor...@mac.com> ha > > scritto: > > > > OpenStreetMap Carto is given special treatment on osm.org by being the > > default layer, so the wiki should reflect that. > > > Just because there's already special treatment does not mean we have to carve > it in stone. The icons which osm carto currently displays, belong into an osm > carto map key, not in the wiki on feature definition pages or map features > compilation pages. Let's not mix up the cartographic representation and > interpretation and choices of a specific style with the definition of the > tags. It was always postulated that osm is about data, and that the osm carto > style is just a demo implementation of one possible interpretation of this > data. But it is the style that people use to check their edits. I just see this as "giving people what they want". The current Map Feature page shows that there are people who thought this was a good idea, otherwise they wouldn't have gone through the considerable effort of adding those images to the wiki. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
Hi! User "Wuzzy" did a huge amount of work related to this discussion here: http://www.openstreetmap.org/user/Wuzzy/diary/39580 https://wiki.openstreetmap.org/wiki/Standard_tile_layer/Key Maybe we can use this somehow? Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
On Sa, Okt 01, 2016 at 02:36:58 +0200, Tobias Knerr wrote: > On 21.09.2016 01:33, Matthijs Melissen wrote: > > I added it to the infobox as osmcarto-rendering. > > > > It is currently only used in the supermarket page: > > https://wiki.openstreetmap.org/wiki/Tag:shop%3Dsupermarket > > Maybe I'm a bit late to the party, but I don't feel it's great to give > special treatment to Mapnik in the infobox, and there is not enough room for > presenting all the renderers there. > > While placing the icon in the infobox is probably the easiest way to make it > available to Taginfo, we shouldn't forget that it also determines how > renderer support is presented on the tag pages. And in that regard, I find > it's a less than ideal solution. > > Quite some time ago, someone suggested a "Rendering" section on tag pages, > with example images for all (or at least a wider selection of) renderers > supporting the feature. This wouldn't be limited to icons, either, but would > also work for area styles, for example. I would clearly prefer a > presentation along those lines, as it would represent the diversity of OSM > rendering in a way that a Mapnik icon does not. > > Of course this leaves the issue how to implement something along these lines > while still allowing Taginfo to access the content. I don't pretend I have a > solution, but could this information be integrated into the Taginfo projects > JSON somehow? If I remember correctly, there is already the possibility to > add icon urls. Our "main map", the one with what we used to call "mapnik style" and now sometimes call "osmcarto style" or so is somewhat special. It is the only "general" style that we have that explicitly tries to show as many features as possible. And there is the precedence of showing this style (and this style only) in the tables on the Map Features page and in other places on the wiki. So I think it is not totally wrong to argue that this style is special and is the only style we present in the Info Box and/or Map Features page. But I also agree with your argument that it would make sense to show more styles. For taginfo it is easiest to get the information out of the Info Box. It is also easy to get the info out of the projects json files it already collects. But if we agreed on some different format, that is also something taginfo could support. So which mechanism we choose should not depend too much on what's convenient for taginfo. Taginfo is software that we can change and the effort involved is likely to be small. The effort of maintaining all those icons is much larger. Ideally it is done somewhere, where lots of people can help. At the hack day at SOTM Matthijs and I threw around some ideas on how to best get those icons into taginfo and back out and had the idea that it doesn't make much sense importing all those icons manually into the wiki when they are already in a git repository somewhere. We thought about including the URL of the icon in the info box. But now with your proposal, maybe it makes more sense to leave the wiki out of it completely and just collect the icons all into some format (basically a map legend) and let taginfo read it from there (and then maybe export it into the wiki through the taglists feature). As you mention, we already have a format that would support most of this (the taginfo projects json files). On the other hand all of this leads down the rathole of automatically generating a map legend. It should be possible to create the list of icons more or less automatically, but nobody has ever tried actually implementing this. We can not delay introducing taglists because we are waiting for somebody to implement legends, because this might never happen. Yes, there are better ways of handling all this than copying icons into the wiki manually and all this. But we are trying to solve one problem here (the overcomplex and huge tag lists we manually create) and we can't solve all the problems at once, otherwise we will never get anywhere. So I think the way forwards has to be the simplest thing we can do so that we can actually finish the current task and then, after we have done one thing, we can think of tackling the next one. All of this brings me back to the first proposal: Just put the icons into the info box (we don't even have to display them in the info box, the template that creates the info box is just a convenient place to put this data). Then taginfo gets the data from there and puts them into the list. This is the short-term solution that would allow us to have the same Map Features page we already have, with a hugely reduced (but not totally removed) maintainance burden. Long-term somebody has to implement map legends which taginfo can then understand. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
Hi! On Mi, Sep 21, 2016 at 09:53:27 +0200, François Lacombe wrote: > The way the list is built isn't clear to me : for man_made example you just > give tags=man_made as template parameter but taginfo doesn't return the > whole set of values. > I see a man_made=mill value on taginfo which is not visible on the wiki > loaded template > Is count the only criteria ? No, count isn't a criteria at all. man_made=mill is simply not included automatically, because there is no wiki page for it. I recommend giving an explicit list of all tags that you want to have in your list. Just using the key only is more of a short-cut to help get you going. In my opinion it makes sense to have a human edit the complete list of everything they want to have in that list. That is the power of the wiki after all, that it is not autogenerated, but somebody actually curates this list. Taginfo should only be the helper here that makes it easier, but it shouldn't decide what ends up on that list and what doesn't. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
Hi Matthijs, On Mi, Sep 21, 2016 at 01:33:28 +0200, Matthijs Melissen wrote: > On 1 September 2016 at 15:04, Jochen Topf <joc...@remote.org> wrote: > > So, if somebody adds the rendering to the infobox (and tells me about it), > > I'll pull that data from taginfo and can put it in the taglist tables. > > I added it to the infobox as osmcarto-rendering. Just looked at this and it isn't the greatest format for parsing by taginfo due to the wiki-specific syntax: osmcarto-rendering=[[File:Supermarket-14.svg|14px]] Could we make it like the "image" attribute instead, just the name of the image file? image=Image:Sainsbury'sGlos.jpg Or a real URL? The size shouldn't be something you have to supply with it, the user should decide on the size, using whatever size fits into whatever the user is doing. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
On Do, Sep 01, 2016 at 10:42:54 +0200, Matthijs Melissen wrote: > On 1 September 2016 at 10:01, Matthijs Melissen > <i...@matthijsmelissen.nl> wrote: > > As a firs step, I included the list here on the Geological map features > > page: > > http://wiki.openstreetmap.org/wiki/Geological > > it seems to work well there. > > As there are some problems with the translations of the pages, this > has now been reverted. What are the problems with translations? Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
Hi! On Do, Sep 01, 2016 at 10:01:16 +0200, Matthijs Melissen wrote: > On a bit longer term, would it be an idea to add a field for > 'rendering' (in the default stylesheet) to the infobox, and include it > on taginfo? I know the 'default' stylesheet is just one of the > stylesheets, and therefore the choice a bit arbitrary, but if the list > has icons, like on http://wiki.openstreetmap.org/wiki/Shop, it does > make it easier to browse through for me. This is a good idea. Historically the "Rendering" images on the Map Features page were often very bad and not well maintained. But looking at it now, it looks quite good, especially for POIs. So, if somebody adds the rendering to the infobox (and tells me about it), I'll pull that data from taginfo and can put it in the taglist tables. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
On Do, Sep 01, 2016 at 10:01:16 +0200, Matthijs Melissen wrote: > As a firs step, I included the list here on the Geological map features page: > http://wiki.openstreetmap.org/wiki/Geological > it seems to work well there. > > The only thing not working are the image links, which are currently broken. This is now fixed. Images work again. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
On Do, Sep 01, 2016 at 08:21:39 +0200, Matthijs Melissen wrote: > On Thursday, 1 September 2016, Jochen Topf <joc...@remote.org> wrote: > > > On Do, Sep 01, 2016 at 12:42:10 +0200, Matthijs Melissen wrote: > > > We have currently a Map Features page on the wiki: > > > http://wiki.openstreetmap.org/wiki/Map_Features > > > > > > The page also contains definitions for all features. We therefore > > > store the definitions now in two places: in the map features tables > > > and in the infoboxes on the pages themselves. > > > > > > > See https://wiki.openstreetmap.org/wiki/Taginfo/Taglists . This "just" > > needs some people going through every tag list in the wiki and replacing > > it by the special syntax. The problem ist, as you say, the differing > > descriptions and such, which need to be consolidated in the process. > > > Great, that's exactly what I needed. Will see what we can do with that. And feel free to tell me if you need anything more or different. What it does at the moment is what I thought might be useful and doable. That doesn't mean this is the best solution. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map features page on wiki
On Do, Sep 01, 2016 at 12:42:10 +0200, Matthijs Melissen wrote: > We have currently a Map Features page on the wiki: > http://wiki.openstreetmap.org/wiki/Map_Features > > The page also contains definitions for all features. We therefore > store the definitions now in two places: in the map features tables > and in the infoboxes on the pages themselves. > > Duplication of definitions seems not ideal to me. Even though a lot of > people try to update this, there are still quite a lot differences > between the definitions on the map feature pages and the definitions > in the infoboxes. > > Do we want to keep the Map Features page? If yes, do we have technical > means to keep the definitions synchronised? Could we perhaps generate > it from Taginfo, or somehow include the definition from the Infobox on > the Map Features page? A solution using Taginfo has been available for about a year now, but nobody took this up. (I guess because not many people know that this exists, and I didn't have time to promote it really.) See https://wiki.openstreetmap.org/wiki/Taginfo/Taglists . This "just" needs some people going through every tag list in the wiki and replacing it by the special syntax. The problem ist, as you say, the differing descriptions and such, which need to be consolidated in the process. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Wie viel Werbung sollte in die Wochennotiz?
On Thu, Jun 30, 2016 at 12:23:10AM +0200, Christoph Hormann wrote: > On Wednesday 29 June 2016, Michael Reichert wrote: > > [...] > > > > Wir möchten von euch als Leser und OSM-Community wissen, welche > > Meinung ihr zu folgender Frage habt: > > > > Sollten wir Meldungen von Firmen, die sich gar nicht oder nur in sehr > > geringem Maße in der OSM- und/oder Open-Source-Community engagieren, > > im Zweifelsfall weglassen? (Auch weiterhin wird es Fälle geben, in > > denen die Meldung auf jeden Fall relevant ist und von uns > > veröffentlicht werden wird) > > Meine Meinung ist, dass das generelle Engagement der Firma für OSM/OS > hier bedeutungslos sein sollte. Entscheidend sollte ausschließlich > sein, ob die Nachricht von Interesse für die Leserschaft ist. Das > bedeutet nicht, dass alles, was auch nur für einen einzigen Leser von > marginalem Interesse ist rein sollte - entscheidend ist das > durchschnittliche Zielpublikum - welches natürlich durchaus einen > Interessenschwerpunkt Richtung OSM/OS hat. Und es spricht auch nichts > dagegen so was wie einen Bildungsauftrag zu sehen. > [...] Dem stimme ich voll zu. Es geht immer darum, was ihr denkt, was Eure Leser lesen wollen. Dann ist das auch keine Werbung, sondern eine Nachricht. Auf keinen Fall sollte der Inhalt der Wochennotiz an irgendetwas anderes gebunden sein, als Eure Meinung, was interessant ist. Darum lesen "wir" die Wochennotiz, weil wir darauf vertrauen, dass ihr das richtige auswählt. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Map Features usefulness, usability and maintainability
On Sa, Mai 28, 2016 at 08:32:27 +, Andrew Hain wrote: > The Map Features page is a long standing page on the wiki linked from its > left sidebar and it has been translated into a large number of languages. > > Unfortunately there are clear signs of difficulties of maintenance. Tags are > regularly added with the wrong wiki variable copied and pasted that makes > the description for a tag wrong in languages other than English until > someone notices. Versions of the page in some languages have message boxes > saying that parts of the page are out of date because page authors didn’t > follow the intended structure. There is no way to link from the main columns > to tag documentation that is newly created in the current language without > updating the link manually; trying to do so from tag descriptions has had > awkward side effects. Currently the page is not fully rendered in three > languages with a fourth that is only complete because one of the templates > has been removed. > > It may be practical to sit down and strip back some of the accumulation of > edits by a large number of different people that have added up to where we > are now or to take on board new wiki technologies such as Lua scripting. But > before we do that I think it’s worthwhile to think about what we actually > need: whether the page should look the way it does, whether it belongs on > the wiki, how we can keep it up to date and indeed whether other sources of > documentation are actually more useful. I totally agree that the manual maintainance is a nightmare. That's why I added the "TagLists" function to taginfo, which can more or less automatically create such feature lists from the descriptions of the tags in the info boxes on the individual key and tag pages. See https://wiki.openstreetmap.org/wiki/Taginfo/Taglists for all the details. Unfortunately I din't have the time to persue this and nobody else worked on integrating this into the wiki on the MapFeatures and other pages. But the feature is finished and working. It is "just" a matter of replacing the old manual lists by the template. The largest effort is consolidating the descriptions and/or images from the individual key and tag pages and the lists on MapFeatures. Where those descriptions/images are not the same it might make sense to update the descriptions on the individual pages to not loose the possibly better descriptions from the MapFeatures list. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] buildings above the ground and below
On Fri, May 27, 2016 at 11:24:53AM +0200, Łukasz Stelmach wrote: > I've got a small housing estate to map. Above the ground there are four > buildings. However, below, they've got common foundation and an > underground garage. The house numbers hasn't been assigned yet so all > the above-the-ground-buildings have the same address. > > Do you have any suggestions how to map it all? I'd tag these as separate buildings ignoring what's underneath. That's how most people will see those buildings. If you don't look closely, you don't know that they are connected. As for the address, just put the same address on all buildings if they actually have the same address. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extract from OSM Planet History dump
On Thu, May 19, 2016 at 02:32:53PM +0100, Peter Mooney wrote: > During the summer time with some free time from teaching I want to do some > analysis of the OSM Planet History dump data. > > Unfortunately I have ran into a few road blocks in trying to get osmium etc > to compile on my Ubuntu 14:04 machine. I spent a while trying to get this > working without success. > > I only want two or three regional-based extracts. OSM History for UK and > Ireland would be my priority. > > Would someone who has these tools currently working be willing to do this > extraction for me? http://data.openstreetmapdata.com/ireland-and-northern-ireland.osh.pbf http://data.openstreetmapdata.com/great-britain.osh.pbf Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Wann geht eine Bahnstrecke in Betrieb?
On Do, Mai 05, 2016 at 11:36:06 +0200, Michael Reichert wrote: > Sollte man die Bahnstrecke in railway=rail umtaggen, wenn sie für die > allgemeine Nutzung offen ist (d.h. jedes Eisenbahnverkehrsunternehmen > dort fahren darf, sofern die Fahrzeuge für die Strecke geeignet sind)? > Oder soll man schon umtaggen, wenn die Testfahrten beginnen? Ich gehe hier mal vom Otto-Normal-Mapper aus, der keine speziellen Fachkenntnisse hat. Der guckt sich an, wie etwas aussieht und mappt das dann. Das ist unser Massstab bei OSM. Der sieht eine Bahnstrecke, die fertig aussieht und auf der gelegentlich Züge hin- und herfahren. Dann macht es keinen Sinn, das als construction zu taggen. Das ist ne Bahnstrecke. Ob die Strecke laut Bundeseisenbahnbaundbetriebsgesetz Paragraph 08/15 offiziell in Betrieb ist oder nicht, das ist eine Frage, die für OSM erstmal keine Rolle spielt. Bei einer noch nicht eröffneten Strasse ist durch einen Laien ohne weiteres ersichtlich, dass sie nicht offen ist, weil sie durch entsprechende Schilder und Absperrungen so gekennzeichnet ist. Bei einer Bahnstrecke ist das nicht unbedingt der Fall. Und auch wenn ich mir anschaue, wie das vom Benutzer der OSM-Daten aussieht, komme ich zu dem gleichen Schluss: Wenn ich mich im Gelände orientiere und sehe eine hübsche neue Bahnstrecke, die in der Karte gestrichelt gemalt wird, dann sieht es für mich aus, als ob die Karte veraltet ist, oder ob ich vielleicht an der falschen Stelle bin. Liegt da überall Baumaterial rum, dann erwarte ich was anderes. Routen kann man auf Bahnstrecken eh nicht in der selben Form, wie man das auf Strassen kann. Nur weil eine Strecke offiziell freigegeben ist, heisst das ja nicht, dass da auch Züge fahren. Also ganz klare Antwort: Umtaggen, wenn es für den Laien so aussieht, als ob die Strecke fertig ist. Das ist einfach nur eine weitere Form der "on the ground rule". Spezialinteressen haben bei OSM gegenüber dem, was allgemein nützlich und erwartet wird, zurückzutreten. Meiner Ansicht nach gehört die Information, welche Strecken offiziell freigegeben sind, überhaupt nicht nach OSM, weil es eine Spezialinformation ist, die sich "on the ground" nicht verifizieren läßt. Aber ich werde mich jetzt auch nicht beschweren, wenn die Eisenbahnmapper dafür einen besonderen Tag erfinden. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Geodaten in Sachsen - Bitte noch abwarten
On Sa, Feb 13, 2016 at 09:21:46 +0100, Joachim Kast wrote: > Diese Antwort erinnert mich sehr an Baden-Württemberg, wo die > veröffentllichten Daten [3] zwar unter inkompatiblem CC-BY stehen, aber > der Minister per Presseerklärung [4] die OSM-Nutzung gestattete. > [4] > https://mlr.baden-wuerttemberg.de/de/unser-service/presse-und-oeffentlichkeitsarbeit/pressemitteilung/pid/amtliche-geodaten-werden-kostenlos-zur-verfuegung-gestellt-1/ Mir ist unklar, wie Du aus dieser Presseerklärung eine Erlaubnis für die OSM-Nutzung rausliest. Da steht nur die Behauptung "Damit sei auch eine langjährige Forderung der OpenStreetMap-Community erfüllt." Das kann ich so nicht nachvollziehen. Was genau war denn diese Forderung? Sicher ist es besser, dass die Daten so rausgegeben werden, als dass es sie nur gegen Geld gibt. Das freut uns natürlich. Aber nutzbar sind sie so für uns immernoch nicht. Und selbst wenn in der Presseerklärung mehr drin stände, eine Presseerklärung ersetzt keine klare juristische Aussage der zuständigen Landesämter. Ich kann die Datenlizenz Deutschland – Namensnennung – Version 2.0 nur so lesen: Wenn man die Daten irgendwie nutzt, dann muss man die Quelle (LGL bzw. halt das Land Sachsen) erwähnen. Diese Forderung "vererbt" sich bis zum Endnutzer der Daten. Wenn die Daten aber mit unseren vermischt werden in OSM, dann fordern wir hinterher nur noch, dass OSM genannt wird. Und damit ist das ganze inkompatibel. Für mich ist also weiterhin klar: Wir dürfen diese Daten nicht in OSM importieren. Da hilft kein rumreden. Entweder die Ämter ändern die Lizenz komplett oder sie geben uns eine klar formulierte Sonderlizenz. Wir haben dieses Thema doch schon tausendmal gehabt mit anderen Datenquellen. Wir brauchen eine juristisch einwandfreie Aussage, dass sie damit zufrieden sind auf http://www.openstreetmap.org/copyright in der Liste der Contributors genannt zu werden und dass sich darin dann ihr Recht auf Namensnennung erschöpft. Wenn Sie das unterschreiben, dann ist das okay, vorher nicht. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Download von .osm Daten
http://download.bbbike.org/osm/ On Mo, Okt 19, 2015 at 09:34:12 +0200, Heinz-Jürgen Oertel wrote: > Date: Mon, 19 Oct 2015 21:34:12 +0200 > From: Heinz-Jürgen Oertel <hj.oer...@t-online.de> > To: talk-de@openstreetmap.org > Subject: [Talk-de] Download von .osm Daten > > Hallo, > > Ich möchte mit mapweaver eine Karte als SVG erzeugen > und benötige dafür Eingangsdaten. Der Bereich umfasst > Teile der Ukraine, > Teile von Moldavien, > Teile von Rumänien, und > Teile von Bulgarien > > Mit welchem Tool kann ich diese Downloaden? > Z.B. unter Angabe einer Bounding Box. > > Aus dem planet.osm mit osmosis zu extrahieren > erscheint mir zu aufwändig, di ich dann zunächst > das riesige planet.osm downloaden müsste. > > Oder kann man die existierenden land.osm > erst zusammenfügen und dann den Bereich mit osmosis extrahieren? > > Für Eure Hilfe herzlichen Dank. > > Heinz > > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taginfo update
Hi! Taginfo hat die Woche ein Update bekommen. Zusammen mit Christopher Baines habe ich an der Mobil-Fähigkeit der Webseite gearbeitet. Einige Bugs wurden gefixt und einige Abfragen, die sehr langsam waren, sind jetzt sehr schnell. Aber die größten Neuigkeiten betreffen das neue Taglist-Feature: Taginfo kann jetzt automatisch die Tag-Tabellen erzeugen, die man überall im Wiki sieht. Unter http://wiki.openstreetmap.org/wiki/Taginfo/Taglists gibts dazu Erklärungen. Dies sollte sehr nützlich sein, die manuelle Arbeit im Wiki zu reduzieren. Ausprobieren wie immer unter: https://taginfo.openstreetmap.org/ Mehr Details in meinem Blog unter http://blog.jochentopf.com/2015-08-15-hacking-on-taginfo.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Taginfo updates
Hi! Taginfo got an update this week. Together with Cristopher Baines I worked on making it a bit more mobile friendly. Some bugs were fixed and some parts that were rather slow are much faster now. But the biggest news is the new taglist feature: Taginfo can now automatically generate the tags tables you see all over the OSM wiki. See http://wiki.openstreetmap.org/wiki/Taginfo/Taglists for how this works. This should be very useful to reduce the manual work needed for updating the wiki. Try it out at: https://taginfo.openstreetmap.org/ Details about all of this at: http://blog.jochentopf.com/2015-08-15-hacking-on-taginfo.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] name:etymology:wikidata
On Fr, Jul 31, 2015 at 04:27:05 +0200, Jo wrote: I like to create bridges between projects, so now I was looking into the name:etymology:wikidata tag. Whatever you do, do not use an abomination like name:etymology:wikidata, because to a computer it looks like it is a name-Tag with the language etymology:wikidata like most of the name:something tags. It is hard enough already to make sense of OSM tags... Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] waterway - routable network and reservoirs/lakes
On Mo, Jul 27, 2015 at 08:08:22 +0100, Lester Caine wrote: On 27/07/15 19:56, Christoph Hormann wrote: In the case where a stream flows into a reservoir , and then a stream (with the same name) also flows out of that reservoir, should a linear way be drawn through the reservoir to connect the two streams (the reservoir is currently represented by its own closed way tagged natural=water, water=reservoir)? Yes. Although a height difference between in and out might indicate a weir or other obstruction may well indicate that a route is non-navigable? The outflow from a dam may have the same name, but have no use as a through route? This is more about the water flow than about being navigable by a ship. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Moeglicher Mapnik- oder Tagging-Bug: Blaues Land
On Sun, Jul 19, 2015 at 01:41:31PM +0200, markus schnalke wrote: [...] Der Fehler tritt nur auf manchen Zoomstufen und nur bei maenchen Tiles der Insel auf. OSMI zeigt bei der Coastline-Pruefung keine Fehler an. Sonst wusste ich nicht, was ich noch haette pruefen sollen. Es kann durchaus mal sein, dass Du die Küstenlinien schon wieder repariert ist und Du daher im OSMI keinen Fehler siehst, aber die Tiles noch nicht alle neu gerendert sind (oder in der Zeit, wo der Fehler in den Daten war, nicht neu gerendert wurden) und daher manche eben den Fehler anzeigen und andere nicht. Genauer gesagt ist das sogar das typische Verhalten. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mangelhafte Namensnennung auf Mapbox-Karten
On Fri, Jul 17, 2015 at 10:07:05AM +0200, Frederik Ramm wrote: [...] Einfluss etc. etc., und dann wird es im Einzelfall gefixt und zwei Tage später taucht der nächste Mapbox-Kunde mit einer unzureichenden Namensnennung auf. [...] Ist das zwei Tage später anekdotisch oder irgendwie belegt? Was mir bei dieser Diskussion immer fehlt ist eine klarere Vorstellung davon, wie groß das Poblem wirklich ist. Wieviele Mapbox-basierte Karte haben eine Attribution und wieviele haben das nicht? Haben wir eine Liste der Fälle, wo die Attribution nicht in Ordnung war, wann wurde das gemeldet, wann wurde es korrigiert? Man kommt bei sowas sehr leicht in einen confirmation bias rein, weil man halt, einmal darauf aufmerksam gemacht, die Probleme sieht und nicht mehr die Fälle, wo es keine Probleme gibt. Und dann macht man ein Problem größer, als es in Wirklichkeit ist. Wenn wir wirklich ein systemisches Problem nachweisen können, dann sollte man das gemeinsam mit Mapbox lösen. Aber etwas mehr als zwei Tage später taucht der nächste [...] auf, sollte es halt schon sein. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Can wikidata links help fight name inflation?
On Wed, May 27, 2015 at 11:13:11PM +0200, Frederik Ramm wrote: we're seeing more and more name:xx tags on OSM objects. [...] Generally I don't think having names in different languages on OSM objects is wrong. We have done it that way for a long time and, lets face it, as long as we allow it for some objects and languages, people will add names to other objects and in other languages, too. Moving responsibility to a different database is nice in theory, but not in practice. The common mapper will not understand why *his* language should not appear, but only some other and he will not understand how to edit a different database (especially not wikidata with its horrible interface) unless we build something for him to make it easy and seamless. Not only well-known tourist magnets carry foreign names; some dedicated language mappers have gone over and beyond the call of duty and added, for example, name:ru tags even to small villages: http://taginfo.openstreetmap.org/keys/name%3Aru#map (This is a matter currently under investigation by Data Working Group and it is relatively certain that not all 582,653 name:ru tags will remain.) Thats a different matter. While there are many names for London in different languages, I don't think there are special Russian names for half a million places on Earth. Chances are they are the result of automatic transliteration. And results of automatic processes should not be mapped for obvious reasons. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
