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
cessing being not fast enough, that gets the causality wrong: Because people have been retagging the coastline, 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&lon=20.93588&lat=59.91265&zoom=13&overlays=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
[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: [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: [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 > To: Simon Poole , 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 > 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: [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 > 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: [OSM-talk] Rendering issues with Carto 4.0
Hi! On Wed, Jun 21, 2017 at 03:58:35PM -0500, Andrew Buck wrote: > Regarding the 15,000 in Canada and 8,000 in New Zealand from imports, is > this a case where a mechanical edit to fix them would be appropriate > (with appropriate planning of course). Something like mechanically > doing all the version 1 objects with the relevant source tags would save > a lot of manual work with very little chance of causing problems. > > I would say, for now, to make the maproulette task skip these two areas > so that the manual editing by people is focused on the other areas while > a mechanical solution for these two cases is discussed. If there is no > consensus on fixing them mechanically before the maproulette people fix > the rest of the world then add these to maproulette, otherwise maybe > they can be fixed without manual intervention. I have contacted both communities through their mailing lists, lets see what they say. I checked and you are right: 99% of all problematic data involved in those two imports was not changed from version 1. So an automated fix might be possible. I don't know who wants to take this on though. 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] Rendering issues with Carto 4.0
On Wed, Jun 21, 2017 at 05:40:41PM +0100, Dave F wrote: > Is there anybody with more skill than I able to put a overpass routine for > this? > I prefer to check problems close to me than the randomness of roulette. The basis for the maproulette challenges I am creating is, obviously, programs that find those problematic ways/relations. Not with overpass though. I am thinking of making this data available in some form. Maybe I can get it into the OSM Inspector like with the other multipolygon problems. Until I figure something out that works for everyone, I can create extracts as OSM files or lists of IDs if somebody wants to have a go at their local area or so. 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] Rendering issues with Carto 4.0
On Wed, Jun 21, 2017 at 05:25:28PM +0200, Maarten Deen wrote: > I don't know if this was an issue with previous renderings too, but what I > also see are multipolygons that do not have a way that is inside it as > member. The inside way still renders but the style of the outer will also > render over the inside way. > Example here: http://www.openstreetmap.org/relation/2456565 where there is a > lake in a woodland area which results in trees in the lake. > > Is it possible to make a maproulette challenge for these cases? This is a much more difficult issue to detect, because you have to understand the different tags and how they interact. For instance, drawing a building on top of a residential area is okay, you should not cut out a space in the residential area for that building. But you have to cut out a lake from a forest. There is no clear documentation what these interactions are. The other problem is that you need to do a lot of geometry operations to find those overlaps. Not really difficult, but it is more effort than just comparing tags on member ways and relations. I want to do this at some point, but want to focus on the easier cases first. Also see https://github.com/osmlab/fixing-polygons-in-osm/issues/22 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] Rendering issues with Carto 4.0
On Tue, Jun 20, 2017 at 12:33:19PM +0200, Sandor Seres wrote: > I am not sure if I understand correctly the following extract from your > letter > >> > ... In a huge effort in the last months we have removed old-style > multipolygons from the OSM database completely, so this is a good step!... > >> The old-style multipolygons were fixed. So they have the "modern" tagging now. No data was lost. 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] Rendering issues with Carto 4.0
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 removed old-style multipolygons from the OSM database completely, so this is a good step! Unfortunately nobody really realized that as a side-effect of the update to Carto 4.0 many multipolygon relations would 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. 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, forests, waterways, all sorts of areas. Worst offenders are about 15,000 relations from imports in Canada and 8,000 relations from imports in New Zealand. Please help fixing these. As part of the "area fixing effort" I have started to create Maproulette challenges for these. Go to http://area.jochentopf.com/fixing.html for more information and read the detailed news about this effort at 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
[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: [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 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 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 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 > 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 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: [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: [OSM-talk] SotM 2016 Accomodation
On Mon, Feb 29, 2016 at 03:00:04PM +, Rob Nickerson wrote: > The SotM accommodation deal is a really good one but we do have a limited > number of rooms so I encourage you to book up early. As noted the ticket > sale will follow shortly and will be a similar price to Birmingham 2013. > > Details at: > http://2016.stateofthemap.org/venue/ There is only a single hotel listed when I click through there, the "Motel One". Price for a single room is 93 EUR. hrs.de offers the same hotel for 79 EUR. Even if you add the extra breakfast (9.50) that's still cheaper. 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
[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: [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
Re: [OSM-talk] a, b and c.tile.openstreetmap.org refer to the same server?
On So, Mai 17, 2015 at 04:46:24 +0200, Maarten Deen wrote: > Is it normal that the a, b and c.tile.openstreetmap.org IP-adresses refer to > the same server? For me, they all refer to amsterdam.tile.openstreetmap.org > and for some reason it is not responding very well (lots of read times out > messages in JOSM). > To me it would seem more logical to have different tileserveraliases refer > to different physical servers. Thats normal. The a/b/c stuff is a workaround for a "feature" in browsers that only allow a limited number of connections to the same host at the same time. (Modern browsers probably don't have this limitation any more, sombody should probably check whether we need the a/b/c stuff any more.) It is not ment to be some kind of load-balancing. And in this case it wouldn't really help to make those aliases to different servers. If one of them is slow your map will still be patchy. 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
[OSM-talk] Broken coastline
Hi! For about 10 days the coastline has been broken and no updates have been going through. This is largely due to some broken mapping in North America where coastlines overlap and some features have been tagged both as coastline and waterways, which doesn't make any sense at all. Please whoever has been working on this read up on how coastlines are supposed to be tagged at https://wiki.openstreetmap.org/wiki/Tag:natural=coastline and fix this. Please, everybody: If you are doing something with the coastlines, take extra care. Coastlines are fragile, have special taggging rules unlike anything else in OSM and if you break them in only one place, chances are coastlines updates for the whole world will stop! 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] Event Calendar on Wiki
On So, Apr 26, 2015 at 12:27:05 -0700, Clifford Snow wrote:
> On Sun, Apr 26, 2015 at 11:22 AM, Mike Thompson wrote:
>
> > I added an event ("OSM Basics @ Colorado State University...") to the wiki
> > (by editing the "calendar" template as the instructions state), yet it
> > doesn't show up on the main wiki page with the other events. Did I do
> > something wrong?
>
>
> I see it listed on the wiki main page. You have it scheduled for April 27th.
The Wiki caches pages, so sometimes it can take a while for things to show up.
This is especially true when a wiki page includes parts from other pages like
in this case. I think usually the caching is disabled when you are logged in,
so you should see the up-to-date version then.
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] Proposal - automate rendering examples on OSM wiki
You misunderstand me. Wikimedia Commons is fine for nice photos that can be used in the OSM project. It has been used for that for a long time. But autogenerated images of rendering examples? That need to be updated every time the rendering changes? Thats doesn't make sense to me. Wikis are good for unstructured data, but your use case is structured data along at least two axis (tag rendered and zoom level), probably more if you want to extend it to different styles. I suggest you keep that data in structured form somewhere and only link to it from the wiki, no need for automated uploads, no need for re-uploading if something changes. As I mentioned it is taginfos job to provide metadata around tags, so that might be a good place. But really anything that can host files on the web is better than trying to upload this to the wiki. Jochen On Mi, Mär 25, 2015 at 11:46:31 +0100, Mateusz Konieczny wrote: > It may fit, OSM wiki qualifies as project "that provide knowledge, > instruction or information". > > http://commons.wikimedia.org/wiki/Commons:Project_scope/Summary#Must_be_realistically_useful_for_an_educational_purpose > > 2015-03-25 10:54 GMT+01:00 Jochen Topf : > > > On Mi, Mär 25, 2015 at 02:06:06 -0700, Minh Nguyen wrote: > > > On 2015-03-24 04:09, Mateusz Konieczny wrote: > > > >Is there any kind of API enabled for OSM wiki allowing automated uploads > > > >of files? > > > > > > The OSM wiki can transclude images from Wikimedia Commons, which has a > > > process for batch uploading images: > > > > > > https://commons.wikimedia.org/wiki/Commons:Guide_to_batch_uploading > > > > I don't think it is a good idea to upload rendering examples to Wikimedia > > Commons... -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal - automate rendering examples on OSM wiki
On Mi, Mär 25, 2015 at 02:06:06 -0700, Minh Nguyen wrote: > On 2015-03-24 04:09, Mateusz Konieczny wrote: > >Is there any kind of API enabled for OSM wiki allowing automated uploads > >of files? > > The OSM wiki can transclude images from Wikimedia Commons, which has a > process for batch uploading images: > > https://commons.wikimedia.org/wiki/Commons:Guide_to_batch_uploading I don't think it is a good idea to upload rendering examples to Wikimedia Commons... Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to report spam/abuse on the wiki?
On Mo, Mär 23, 2015 at 07:51:13 +0100, Frederik Ramm wrote:
> On 03/23/2015 06:20 AM, Bryce Nesbitt wrote:
> > I noted a spam post to the wiki ( User:BrookMcIlvain ).
> > How do I report that?
>
> Well the standard procedure would be replacing the page content with
> {{Delete|Spam}}. That takes care of the spam, and then a Wiki admin
> might or might not look at deletion requests from time to time and
> actually remove the page.
>
> (There's quite a few pending deletion requests
> https://wiki.openstreetmap.org/wiki/Category:Labelled_for_deletion so I
> guess Wiki admins are either understaffed or don't think this is very
> important.)
I recently used the {{Delete}} template on a few pages and the next day they
were gone. So somebody is working on that. I suspect some cases are easy and
are handled quickly, others need some investigation or maybe links to those
pages need to be removed first, and so they need some more time. But spam
should be obvious and quickly dealt with.
Jochen
--
Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal - automate rendering examples on OSM wiki
On Fr, Mär 20, 2015 at 04:26:54 +0100, Mateusz Konieczny wrote: > Some articles about tags have section "rendering". Such entries are > frequently incomplete or > outdated. It simple for me to generate example of rendering for every > single tag used in default map > style. It is probably possible to automate upload for wiki. Is somebody > interested in using such files > on wiki? Probably via some clever template that would be added to rendering > section or by manual > updating all tag pages. > > What I may do: generate example of rendering for every single tag used in > default map style > (around 550 files - see list on > https://github.com/matkoniecz/CartoCSSHelper/blob/master/style_specific/default_osm_style.rb > ) > > What is necessary to make it useful: script that would upload files to > wiki, somebody interested in > using such files > > Note - generation of these images requires some time, it also would be > necessary to decide on > zoom level of rendering and secondary tag (what should be value of > name/ele/ref tag?) I think the important part is doing the rendering, deciding on zoom levels and all this. This is going to be some work and will need some time. Once that works we can decide what to do with the rendering. Bringing it into taginfo would be quite easy I presume. We could even extend the already existing taginfo feature for embedding taginfo results in the wiki to bring those renderings into the wiki if we want to. That would be much easier to do than to try to edit the wiki automatically with all the problems it brings. As a first step I suggest you look at https://wiki.openstreetmap.org/wiki/Taginfo/Projects and see whether your rendering can be brought into taginfo that way. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Taginfo challenge
On Sa, Mär 14, 2015 at 09:24:20 +1100, Warin wrote: > Are not 'keys' always lower case? Thus any upper case there can be changed > into lower case without loss of data? Tags are much more varied than you might think. And then some. See here for some stats: http://taginfo.openstreetmap.org/reports/characters_in_keys Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Taginfo challenge
On Fr, Mär 13, 2015 at 07:17:01 +, Malcolm Herring wrote: > I found several cases of a key being duplicated with various > capitalisations: instead of "this" they are mostly like "This" or "THIS". > > Could somebody make a bot to clean these? Please don't. Read the end of http://blog.jochentopf.com/2015-03-05-new-taginfo-features-and-a-challenge.html to see why it is a bad idea to do spelling fixes automatically. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Taginfo challenge
Hi! One week after my taginfo challenge we have a visible dent in the number of of keys as you can see here: http://taginfo.openstreetmap.org/reports/historic_development But it looks like the work is already stalling. Maybe it is because everybody is at FOSSGIS conference this week? Keep up the work, there is still a lot to do to clean up the OSM database! If you have no idea what I am talking about, read this: http://blog.jochentopf.com/2015-03-05-new-taginfo-features-and-a-challenge.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New taginfo feature and a challenge...
On Tue, Mar 10, 2015 at 12:45:24AM +0100, colliar wrote: > Not sure if it is connected but I have problems with the taginfo website. > > If I want to have a closer look at a tag (key=value) like > highway=cycleway [1], I only get one page with the former tabs as links > but clicking on them does not change anything except the URL [2]. The > page stays the same. Was a bug. Only happened when using https. Fixed now. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping dangerous bicycle locations?
On Sa, Mär 07, 2015 at 03:26:38 +0100, Stefan Keller wrote: > What about crowdsourcing dangerous bicycle locations using key/tag hazard? > See http://wiki.osm.org/wiki/DE:Key:hazard > And see also https://twitter.com/sfkeller/status/574213951644368896 Sounds very subjective to me. Doesn't belong in OSM. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New taginfo feature and a challenge...
Hi! Taginfo just got a new feature, it can now find keys similar to other keys. This is useful to find related keys, but also to find misspelled keys. I hope the community uses this feature to clean up those wayward keys... More at http://blog.jochentopf.com/2015-03-05-new-taginfo-features-and-a-challenge.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Finding a user from a tag/value?
On So, Mär 01, 2015 at 08:42:09 +1100, Warin wrote: > I found that the JOSM button did not work for me... addblocker ? Turned it > off .. still not working .. humm. Overpass worked so I have what I need .. > I'll look at the JOSM thing latter as I use that for editing so am familiar > with at least some of it. JOSM has to run already for this to work and you might have to allow remote access in the JOSM config somewhere. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Finding a user from a tag/value?
On So, Mär 01, 2015 at 06:23:19 +1100, Warin wrote: > I'd like to find out which user has contributed a key to the map ... the key > has no wiki page and I'd like to know what was meant by the key and its' > value. The key has low numbers .. so while there may be more than one user > .. I think I only need to contact one of them. I've used Taginfo to find the > key, its values and location in broad terms. > > Any ideas? Or is there a wiki on this topic I've not found on my searches? From taginfo you can use the "overpass turbo" link to get all objects that use that key, look for the IDs. From there you can get the history of the objects with links like http://www.openstreetmap.org/node/3458982/history. Find the oldest version in the history and look for the user. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Big Lakes
On Wed, Feb 18, 2015 at 02:48:03PM +0100, malenki wrote: > Jochen Topf wrote: > > >Please do not add more (and more difficult cases like lakes on > >islands in lakes on land) to the data, otherwise this process will get > >more brittle than it already is. > > Well, that is a word. > > What do you think of the Great Lakes mapped (partly) both with > coastline and MPs? The Great Lakes should move away from the natural=coastline mapping. I myself have fixed this for some other lakes but didn't want to touch the Great Lakes because they are, well, so great, and in parts mapped in a lot of detail. I home somebody will take on that project. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Big Lakes
On Tue, Feb 17, 2015 at 09:33:14PM +0100, Richard Z. wrote: > coastline. Everything else would seem like a nightmare and I do not think > there is any reasonable ground for the distinction of coastlines according > to lake/ocean type. > > Perhaps we should be a bit more bold and map all bigger lakes with > coastline unless they have been already mapped differently. The problem with mapping as coastline is that for using the data you have to take into account the data for the whole world. There is a special program (https://github.com/joto/osmcoastline) which takes everything mapped natural=coastline and tries to fit everything together. This is a somewhat difficult and error-prone process which sometimes breaks. Typical errors are gaps in a coastline or coastlines going the wrong way around. The process has to detect and fix those errors. Every small error can potentially break the coastline for the whole world. Please do not add more (and more difficult cases like lakes on islands in lakes on land) to the data, otherwise this process will get more brittle than it already is. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for feedback: new building colours in openstreetmap-carto
On Do, Nov 27, 2014 at 01:16:05 +, Matthijs Melissen wrote: > We are considering to change the colour of buildings in > openstreetmap-carto, the default rendering on openstreetmap.org. I like the new rendering of the buildings in general, but they look weird on darker backgrounds now (like the barracks in the Krakow example and Governors Island in New York). Those renderings are too prominent anyway, so maybe those should be changed first to a lighter tone? Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] International Map Year
Just stumbled over this: http://internationalmapyear.org Seems to be some UN thing: The International Map Year 2015/16. Maybe some OSM groups want to get involved in some way. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multilingual Map Demo working again
On Sat, Oct 18, 2014 at 08:31:39PM +0200, Marco Lechner - FOSSGIS e.V. wrote: > how much additional disk space is approximately needed (compared to a > bg-map that includes one language rule)? Of course this value can only > be an approx. ratio. The absolute space depends on aoi, zoomlevels, ... Approximately zero. :-) The overlay tiles with the labels are rendered on the fly and only kept very short term in memcached. There is some overhead due to extra indexes in the database to allow the fast rendering, but thats probably negligable. This map doesn't use the normal tile stack. For details see http://wiki.openstreetmap.org/wiki/Multilingual_maps_wikipedia_project Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Multilingual Map Demo working again
Sven Geggus and I found the problem(s) why the Multilingual Map didn't work and fixed it. See http://mlm.jochentopf.com/ . This is only a demo so no promises on the future of that map. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] wiki tag page template: ways vs areas vs relations
On Di, Okt 07, 2014 at 01:20:14 +0200, Martin Koppenhoefer wrote: > Besides this, in the past I have so often encountered wrong/incomplete > settings (compared to what is actually done, and to what should / can be > done according to my own understanding) that I generally ignore these > icons. Do we really need them? Is there any benefit e.g. for data > consumers, compared to looking at actual usage numbers and cases? > > E.g. the area key: http://wiki.openstreetmap.org/wiki/Key:area > the setting is currently "not on ways", but that's nonesense because you > need this key on some ways (e.g. linear closed barriers) with area=no to > avoid confusion. > > Or the key for a phone booth: > http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtelephone . According to > the wiki it should be mapped only on nodes (and I agree that this is > preferable for the current state of mapping), still some people have used > this on ways and I don't think it is "wrong" (actually an area is better > for everything that is not a true point or a very tiny area in reality, > e.g. a peak). > > Or the key "bench" http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbench > Currently defined for nodes and ways, but areas would make sense in some > cases (when you'd want to express a particular shape for instance). > > Often the relation setting is set to no, but how can this be? Aren't > mappers encouraged to invent new relation types just as they can invent new > tags? Can't any object be part of a site relation for instance? Will we > check for every new relation type that gets proposed and/or introduced (by > the way, what does this mean in OSM, "introduced"?) all objects in the wiki > if their "applicable to" section complies with the new relation type? Which > relation types are actually meant with the "relation" setting in this > template? I think they are better than nothing. Your arguments work for about everything in OSM. Because we have so much freedom in OSM we can always throw our hands in the air and say: This is all so complex and there is no way I can ever describe the complexity so lets give up. And only because in theory we can invent new relation types all the time, in practice there is often no software that uses them, so telling the user that they can do everything they want just doesn't make any sense. For phone booths, everybody uses nodes, everybody understands that, the software understands that. For practical purposes this is what we do and what we document. Of course all these things change over time and maybe somebody it will be common place to do it differently, but thats what we have now and what we should document. Maybe we should have a tool that compares object counts for the different types from taginfo with the wiki documentation and complain if they seem to be out of whack? Main problem there is that taginfo doesn't know about "areas", but only about ways and relations. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] wiki tag page template: ways vs areas vs relations
On Di, Okt 07, 2014 at 11:05:30 +0200, moltonel 3x Combo wrote: > all tag pages on the wiki have a sidebar[1] that tells which element > (node, way, area, relation) the tag applies to. Since an "area" is > either a closed way or a multipolygon relation, my understanding has > always been that if a tag is only meant for an area (for example most > landuse tags), it shouldn't be documented as usable on "ways" and > "relations" in general. In other words, for that template's usecase, > ways/area/relations are separate sets, despite sharing primitives. > > Is that everyone else's understanding too ? In that case, I'll mention > that fact in the template's documentation, and keep an eye out for > misdocumented tags. > > [1]:http://wiki.openstreetmap.org/wiki/Template:ValueDescription +1 Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Taginfo now aggregates even more information about tags
Taginfo got an update today integrating even more information about tags from many different projects using OSM tags such as Nominatim, JOSM, iD, OSRM and, most importantly, the OSM Cheat Mug. More infos at http://blog.jochentopf.com/2014-09-19-taginfo-integrates-more-data-sources.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag with value lists Was: Proposed mechanical edit to convert alt_name tags
On Mon, Sep 08, 2014 at 05:52:57PM -0500, Andrew Buck wrote: > On 09/08/2014 05:44 PM, Eugene Alvin Villar wrote: > > On Tue, Sep 9, 2014 at 3:00 AM, Florian Lohoff wrote: > > > >> Isnt the semicolon the list seperator typically used in OSM? My > >> intuitive answer would have been alt_name=a;b;c;d > >> > > > > +1 > > > > I think using a semicolon-delimited list is better than a > > potentially open-ended set of keys such as "alt_name_x", and > > already has precedent. While it is true that semicolon as a > > multi-value separator is not written as a "law" of OSM tagging, it > > is quite frequent enough to be a de facto tagging guideline. > > > > Both systems are in use and were in use before we started working on > this GNS stuff. The tiger tags are one example, but there were > alt_name_N tags before we started as well. If you want to have a > discussion about changing all of these worldwide, that is fine, but > this thread is about fixing the alt_name:2 ones. > > Please either weigh in on that, or keep silent. I do not have time to > have a general discussion about broader topics of how multi-valued > keys should be handled. There have been dozens of threads that > discussed that and no one has ever come up with a good solution, so I > am not going to have this thread get dragged into the same discussion > that has been had many times before. > > There has been one person who has said it makes sense to change them, > and all of the other posts have been about discussion of other topics. > So unless someone has some concrete reason _not_ to convert the few > mistaken ones, I will go ahead and do that. We can have these other > discussions some other time when people are not waiting on the results. Sorry, but this is not how OSM works. You have to allow discussion and you have to listen what people have to say and engage with them in the discussion. If you can not do that you can not do any automated edits. I understand your frustration with the discussion culture in OSM that often seems to go in endless rounds and leads nowhere, but for better or worse, this is what we have and what has built OSM as we know it. So somehow it can't be all bad. There are a lot of people on this mailing list with long experience in OSM and the software using its data. Chances are there are a few who know something you don't. It might appear tedious, but it actually leads somewhere. And if you want to help the discussion along, you can read all the answers and suggestions and pull them together into one coherent pro/contro-type document with the different proposals. Your argument that others are discussing a different topic is bogus. If you want to change alt_name:2 into alt_name_2 and people don't agree that this is the right tag, how can that be a different discussion? Btw I think you have a good chance that this discussion will lead somewhere, because you seem to be actually using those tags. Most endless discussions revolve around lofty issues where nobody actually uses any of the variants in question. So make your case, but keep an open mind, collect information about the solutions impartially and you will get somewhere. If you think you don't have the time, maybe you should think about the time of all the others involved here, too. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Own wikipage for every single speed limit??
On Fr, Sep 05, 2014 at 12:51:40 -0700, Minh Nguyen wrote:
> On 2014-08-28 04:37, Jochen Topf wrote:
> >Redirect pages can have a bad effect, though. Taginfo will show if a wiki
> >page
> >exists for a key or tag. Taginfo can't know why there is a redirect. Is this
> >a
> >case where the redirect directs from a "typo page" to the "real page" or is
> >this a case where, like in the maxspeed case, several pages for totally
> >good tags have been rolled into one. So taginfo shows them all the same and
> >might lead people into thinking the "typo key" is the real one, if they don't
> >click through to the page.
> >
> >The problem behind this is that there is no way to mark the reason why there
> >is
> >a redirect. It could be "old now discontinued name", or "common misspelling",
> >or "this page would be basically a copy of this other one, so look there", or
> >probably some other reasons. Redirects hide this information, that could be
> >written down on the page instead. So I think redirects should be avoided. In
> >particular, misspellings would be better handled by having a slightly fuzzy
> >search (not sure how good MediaWiki is for that).
>
> At Wikipedia, templates are categorized using a series of templates like {{R
> from misspelling}}. You just place them on the line following the #redirect
> tag. Could taginfo be made to look for these templates or the categories
> they sort into?
>
> [1] https://en.wikipedia.org/wiki/Template:R_from_misspelling
It could. But humans will not see anything in those redirect pages without
jumping through hoops, so I think this makes a bad situation even worse.
Jochen
--
Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
