Re: [OSM-talk] tag with value lists Was: Proposed mechanical edit to convert alt_name tags
On Monday 08 September 2014, Andrew Buck wrote: > > My understanding was that since almost nothing actually understands > the ; separator that doing it as multiple tags is the preferred > system. That does not seem quite comprehensible to me. Note there have been placename imports using the semicolon variant extensively, like from NGA GNS, see: http://taginfo.openstreetmap.org/tags/?key=source&value=NGA%20GNS#combinations many of the alt_name/alt_name:en there are semicolon separated lists. Nominatim does not seem to have a problem with those. From the viewpoint of a data interpreter the semicolon lists are usually much easier to process than an unlimited number of separate name tags. Likewise for editing. Given that neither alt_name_x nor alt_name:x are documented in the wiki, both variants are hardly used anywhere except western Africa and the semicolon list variant is actually used frequently elsewhere i would strongly suggest if you want to do a mechanical edit you change those to a semicolon list. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Introducing "Fix waterway direction"
On Thursday 28 August 2014, Peter Barth wrote: > ]...] But as I'd > like to get a mostly complete waternetwork for another project, I'm > planning on extending the challenge at some point. If you are hoping for a complete network right from the OSM database without post processing you have a long way ahead of you... > > In terms of usability it would of course be good if you could see > > the direction in MapRoulette so you can verify the data without > > actually loading it in the editor. > > Serge suggested this, too. But I did never understand what the > direction would tell the user? Does it denote the current way's > direction or the supposed correct direction? How would the user know? > And my biggest concern is, that in many cases you need aerial anyway > to be really sure. Well - cases like http://maproulette.org/#t=waterways-direction/8300823723664637270 are pretty clear cut - no need for other data. If you'd be able to switch to a background map with relief rendering like the cyclemap even less clear cases can often be properly determined. It is also a matter of motivation i think - if you can clearly see the error you are much more motivated to fix it. Of course showing the direction of the other waterways around would be very useful - but probably difficult to implement. I would always show the currently mapped direction - so the potential answer 'this is not an error' matches that rendering. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Introducing "Fix waterway direction"
On Thursday 28 August 2014, Peter Barth wrote: > Hi all, > > I created a new challenge for MapRoulette: "Fix waterway direction". > > As the waterway's direction in OSM denotes the direction of the > water's flow, I started to compare them to SRTM. This leads to more > than 1 million wrong directions for Europe only. Many times SRTM is > right, however, due to data errors, not every time. That's why I > created this challenge. > > [...] Great to see the waterways are getting some attention. Does this only analyze SRTM elevations at start and end point or are the surrounding waterways considered? If a waterway meets another waterway at one side but is unconnected at the other for example this is usually a strong indicator for the direction independent of the elevations data (which is only helpful usually in mountain areas). In terms of usability it would of course be good if you could see the direction in MapRoulette so you can verify the data without actually loading it in the editor. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Early History of OSM
On Monday 25 August 2014, Martin Koppenhoefer wrote: > > - the coastline is more recent than 2006 Since August 2006 seems to have been around the time when coastline mapping started there probably was hardly any data. In case this is of interest, the oldest coastline node currently used seems to be http://www.openstreetmap.org/node/12183965 mapped as part of a man_made=pier originally. The earliest PGS imported node still in use apparently is http://www.openstreetmap.org/node/13491356 -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
On Saturday 23 August 2014, john whelan wrote: > Looking at what they are doing I'd say the information being dug out > will be of value to the OSM community and help us understand a little > more about the people who add value to the maps. It might even help > us on the retention rate and bring the experience of the average > mapper up a little. It's also being done fairly professionally and > running something like this properly costs money, at least its not > OSM money. So the aims justify the means? Sorry - but no, if you cannot do something in a decent manner you can't do it at all. > How would you suggest he obtained a large enough random sample? With voluntary participation you can't, no matter what you do. That's why a census generally is not voluntary. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New mapping satellite
On Friday 15 August 2014, Kevin Bullock wrote: > You are assuming that all of DG's imagery gets published in > Mapbox/Google/Bing, which is incorrect. Please see my SOTM-US > presentation; 4m00s in. > http://stateofthemap.us/session/mapping-the-world-in-raster/ Interesting talk, thanks for pointing out. This is however kind of my original point - the new satellite will likely not have much influence on what practically is available to the OSM mapper since what images can be and are taken and which are made available to the OSM mapper are two entirely different things. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New mapping satellite
On Friday 15 August 2014, Kevin Bullock wrote: > [...] DigitalGlobe uses > the entire constellation of 6 satellites to map the world. True there > are many "task orders" we fulfill but the larger mission is to map > the world. We can generally do this on an annual basis. That is a bold claim considering an estimated 1/4 of the world land surface is currently without any high resolution coverage in Bing, Google or Mapbox. > With our partnership with Mapbox, the OSM community will start seeing > this imagery through the Mapbox satellite layer; this will be of huge > value for mapping new areas and updating OSM. That would be great. I think i mentioned this before but it would be really nice if the Mapbox satellite layer provided information on the date of image acquisition. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New mapping satellite
On Wednesday 13 August 2014, John Sturdy wrote: > Announced in typical Register style: > http://www.theregister.co.uk/2014/08/13/creepy_satellites_will_be_abl >e_to_zoom_in_on_your_face/ Mapbox has some more detailed explanations: https://www.mapbox.com/blog/worldview-3-launch/ including an positional accuracy number (3.5 meter) which is of course just a claim at the moment and is likely for points exactly in nadir position. Note the resolution number is a bit like the Megapixels in digital cameras, it does not say much about the actual ability to resolve details although in case of earth observation satellites pushing the nominal resolution much beyond the optical resolution abilities makes much less sense since it is very costly. In contrast to what the register article seems to imply these high resolution satellites are not systematically mapping the whole planet, they generally take images on demand for customers. Practically it will probably mean that in the long term more up-to-date imagery will become available but mostly in areas where there generally are already less up-to-date high resolution aerial images. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Upcoming openstreetmap-carto changes
On Friday 25 July 2014, Christian Quest wrote: > > On the first zoom levels, I think we can put the priority on map > users a little bit more... but as map contributors are more checking > their work at the highest zoom levels we should stick with strict > rendering showing errors. Doing more than that seems difficult or > impossible to me. My observation is often the actual design is more or less the other way round, the highest zoom levels are mostly designed to be useful, at least in the urban environment. On intermediate scales the map style is fairly selective showing only certain things sometimes based on a somewhat arbitrary selection leading people to frequently apply tags specifically to make elements show up. At the same time it gives fairly little orientation for the map user. And the lowest zoom levels are not given much consideration at all, making them neither useful for the map user nor for the mapper. This is of course a subjective impression - it might appear quite differently for others. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Availability (Coverage) 2014
On Wednesday 16 July 2014, Stefan Keller wrote: > Update from Stefano (many thanks!): > https://twitter.com/maps4thought/status/489388472063774720 > Now it looks better! Yes that looks much more plausible. Still the population data is quite strange - northern Quebec uninhabited and northern Greenland inhabited is a bit of a stretch... -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Availability (Coverage) 2014
On Tuesday 15 July 2014, Stefan Keller wrote: > > Which node density map by Martin Raifer do you mean? http://tyrasd.github.io/osm-node-density/ -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Availability (Coverage) 2014
On Tuesday 15 July 2014, Stefan Keller wrote: > Note: IMHO Diagram/color scheme has some potential to be enhanced. That seems kind of an understatement - the white areas are quite puzzeling for example - they are definitely not areas below a certain node density, easy to see if you compare to the recent node density map by Martin Raifer. They also do not appear to be areas with low population density (for example large essentially unpopulated areas of the southern Arabian Peninsula are included). This makes it a very misleading graphic IMO since deliberately leaving out significant parts of the data will influence many conclusions people might draw from such a map. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The biggest violation of OpenStreetMap, ever.
On Sunday 13 July 2014, Paul Norman wrote: > > > In general rarely any OSM based map out there tells exactly where > > OSM data is used and where not, even OSMs own 'standard style' map > > fails to mention the use of non-OSM data. > > The style documentation does cover other sources. Also, the other > sources are all under ODbL compatible licenses anyways, so the > situation is a bit different as the entire set of sources can be > released under the ODbL. Of course, i was just trying to point out that the standard OSM map does not really give a good example here for others to imitate. Since the style is open you can of course see where external data is used but this only works as long as it is open. Anyone who uses a proprietary style but otherwise follows OSMs own example in terms of attribution will not have this information available including those styles on osm.org which are not open. And the ODbL as far as i can see does not make any difference if a derivative/collective database contains data originally published under an ODbL compatible license or not. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The biggest violation of OpenStreetMap, ever.
On Wednesday 09 July 2014, Michael Reichert wrote: > > The website now has an attriution in the lower right corner: > > © Geopoi, Map Data: © Here, OpenStreetMap contributors > > "Here" is a link to http://here.com/ > "OpenStreetMap" is a link to http://www.openstreetmap.org/copyright > > I think that this is not enough. Because they mix data they should > declare which data is from where. There should be a link to website > (or a pop-up) with a text like this: It would be great if they did but nothing in the license requires them to, the attribution requirements are fully satisfied by this. In general rarely any OSM based map out there tells exactly where OSM data is used and where not, even OSMs own 'standard style' map fails to mention the use of non-OSM data. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On Monday 07 July 2014, Frederik Ramm wrote: > > > The tagging might of course be considered wrong - it could be more > > like highway=track and surface=snow but for the standards of the > > region highway=secondary might even be an understatement. > > What would you recommend? Well - there is not really a frame of reference here - going strictly by the wiki it would be highway=trunk - there are certainly no more than a handful of such long distance roads on the whole continent so this certainly qualifies as 'one of the most important'. On the other hand it is not used frequently so highway=secondary might not be such a bad choice. The question is of course if this qualifies as road at all since for the most part it is not really a built, permanent structure, on the plateau essentially these are just the tracks of the transports that went this route. The other end of the road is tagged highway=road by the way: http://www.openstreetmap.org/way/187792384 -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On Monday 07 July 2014, Frederik Ramm wrote: > > A new year, a new update. I like it how this map reveals some things > that otherwise remain unseen, like for example a several 100km long > secondary road in Antarctica (near New Zealand) that seems to have > been there for a year (I've deleted it now)... That was actually an existing feature - a transport route from the coast to the French Concordia station - you can even marginally see it on the LIMA mosaic if you look closely: http://mc.bbbike.org/mc/?lon=123.43508&lat=-75.07765&zoom=12&num=2&mt0=bing-satellite&mt1=mapnik See also: http://en.wikipedia.org/wiki/Concordia_Station The tagging might of course be considered wrong - it could be more like highway=track and surface=snow but for the standards of the region highway=secondary might even be an understatement. The map could use an update of the coastline file. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The biggest violation of OpenStreetMap, ever.
On Monday 07 July 2014, Cristian Consonni wrote: > > This server is online since 4 years and it was praised in the press: > «The base of GeoPoi [the name of the service] is vector graphics that > nobody, not even Google Maps [...] can pride of»[*] (sic et > simpliciter) (we found this article just now) It seems this 'Geopoi' is being created by a company called SOGEI - see http://www.sogei.it/flex/cm/pages/ServeBLOB.php/L/EN/IDPagina/424 Your approach of making this public is not a bad idea but you probably need to expect they don't care, especially if they have already ignored you for months. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Just facts?
On Thursday 19 June 2014, Frederik Ramm wrote: > > "Ultimately, map data is pretty much fact and whether it exists or > not is a binary statement. [...] This is IMO what mapping should aim at, as outlined by the verifiability rule - practical mapping and actual data is however often quite far away from this goal. More importantly though i think the most significant way to take influence for a mapper is through selection of what to map and what not. Since there is neither a policy nor a mechanism to enforce completeness of mapping and it is unrealistic to create such what is mapped and what is not represents a huge element of subjectivity and possibly bias in the data even if all the data itself is strictly factual and verifiable. Imagine for example someone mapping all the buildings in a town but deliberately leaving one building unmapped. It is much more likely then this building stays missing from the database than if the buildings had not been mapped systematically but over time by community efforts. And there is nothing factually wrong with such mappping, it is just incomplete. But even without deliberate attempts to influence the mapping like this it seems clear to me that paid mapping will focus on different things than normal community mapping. Kind of 'where the money is' vs. 'where the people and their interests are'. If suddenly half of the mapping in OSM would be paid mapping you can be certain that the thematic and regional focus of OSM would change - and again without any non-factual or non-verifiable elements in the data itself. Getting back to the comparison with Wikipedia i think there are a number of important differences to keep in mind when comparing these two. - In contrast to the data in Wikipedia the OSM data is normally not viewed directly, it is used in maps and other services which provide an additional layer of abstraction and interpretation and due to the diversity of map styles and services available the possibilities for someone editing OSM data to take influence in some form are much more indirect than in case of Wikipedia. - One of the major mechanisms leading to bias in Wikipedia is the removal of data. You can only effectively push a certain POV if you can actually remove information unfavourable to it. For OSM this would mean simple additions of new data by paid mappers would probably be less critical than deletions and modifications like changing tags. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Worldwide non-surveyed tag edits
On Wednesday 11 June 2014, Jochen Topf wrote: > > I think the "mechanical edits policy" has stepped over the line here. > A mechanical edit is one where somebody uses a special program that, > based on some simple criteria, does *automatic* changes. Using > existing tools like JOSM and XAPI to find problems, looking at them > manually and doing edits, is not a mechanical edit and should not > fall under that policy. And i think it does not. The policy is probably not worded in the clearest possible way but it has always been my interpretation that the key question is if the modifications made to the database are individually verified by the mapper, not if you use some fancy filtering to find those objects you want to modify. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Taginfo Updates
On Sunday 18 May 2014, Jochen Topf wrote: > > Oh, and while we are nitpicking, you always only see the position of > nodes. If a way has very long segments between two nodes, you will > not see a line, but just the end nodes. This will sometimes look odd. > Thats why there are those strange dots in Antarctica for the > coastline: > http://taginfo.openstreetmap.org/tags/natural=coastline#map > Yes, this i figured out myself, based on the very same coastline segments ;-). It would of course be great to have the relations in there, simply in form of the first member node/first node of the first member way. But that would be somewhat expensive to do i suppose. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Taginfo Updates
On Sunday 18 May 2014, Jochen Topf wrote: > > Those features are multipolygon relations and taginfo doesn't know > anything about multipolygon relations. I see - so at a closer look the maps are not really "Geographical distribution of this tag" but "Geographical distribution of nodes and ways with this tag". -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Taginfo Updates
On Sunday 18 May 2014, Jochen Topf wrote: > Taginfo got an update with lots of new features: Maps for tags, easy > comparison of keys/tags, better integration with overpass turbo and > Level0 editor, and more... > > For details see here: > http://blog.jochentopf.com/2014-05-18-taginfo-updates.html Nice, esp. the tag maps. There is however something strange about them - i assume you intend to mark one pixel for every feature with the tag but it seems there are features missing. In the natural=glacier case for example: http://taginfo.openstreetmap.org/tags/natural=glacier#map there are definitely more features tagged than show up in the map, see for example: http://www.openstreetmap.org/#map=6/-71.329/-69.807 -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Organizational mapping policy
On Wednesday 14 May 2014, Frederik Ramm wrote: > > Personally, I think that a policy like that should cover any kind of > (for lack of better word) "directed" mapping, where a mapper doesn't > act on their own accord (because they want to) but on someone else's > (because they're told to). > > The boundary is of course blurry - if you report for duty at your > local CSO, on your own accord, because you want to make the work a > better place, and then are told that this week's project is fixing > TIGER roads in rural Pennsylvania - are you "directed"? Exactly. It seems to me the distinction between those activities you specifically do not want to regulate and those you do want to cover is problematic. The core question seems to me what exactly the aim of such a policy is. If it is aimed at companies who have people edit in OSM the policy should define its scope in terms of these companies, not in terms of the editing activities they endorse. One possible point is that organizations developing certain rules for mapping on their own (like regarding tagging or use of geometries to represent certain things) and instruct others to use these rules they are required to discuss/document these with the community first. Such policy would be independent of how exactly people are instructed by the organization - if they are paid or just volunteers. If on the other hand the editing activities themselves are considered the primary issue the question is what aspect of them is considered to be the problem and this should make the core of the definition. Based on the issues in Wikipedia Paul refers to for example the possible conflicts of interest might be the main issue and if that is the case it might be best to require any mapper to disclose possible conflicts of interest on their user page. The use of proprietary third-party sources is for example an issue not limited to organizational mapping at all, it is a frequent occurence that people use proprietary data they have access to (for example as part of their work but without their employer being involved) as a mapping source - such sources should probably be required to be disclosed even if the mapping itself is a totally private activity. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Azimuth measurement
On Tuesday 08 April 2014, François Lacombe wrote: > [...] > Is there a solution to that issue ? > > Measuring geographic north directly isn't so simple I think. > Probably the simplest and most accurate way is to use position measurements to determine the direction. Look in what direction the feature you want to orient points, identify a point in that direction at suitable distance, go to that point and record the position (or use the already mapped data of it) and use both positions to determine the direction. With very simple tools (like piece of cardboard with an angular scale drawn on it) you can also record relative orientations and this way avoid the need to find a reference point in exactly the direction your object points to. This is how you used to measure everything before the age of GPS. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Level0 OpenStreetMap Editor
On Friday 04 April 2014, Ilya Zverev wrote: > > It is a web-based, text-only editor, a bit like RawEdit, but with > more features and without scary XML. Basically, you are editing easy > to understand lines like "way 123123" with tags written like > "highway=primary". There is a map for positioning of nodes, which > allows for creating new POIs, and it can edit multiple objects at > once. Nice. Seems there have been several approaches recently to design text based formats for OSM data that are less clumsy than XML like your Level0L and Osmiums OPL: http://osmcode.org/libosmium/manual/libosmium-manual.html#opl-object-per-line-format These surely have different purposes - one is for easy human editing and one is for automatic processing but it might none the less make sense to see if these goals can be achieved in the same format together. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SOTM-EU - Submit your talk
A quick reminder - today is the last day you can submit a talk for SOTM-EU 2014. We have already received a lot of very interesting submissions that are going to make for an attractive program. If you are contemplating to submit something today is your last chance. Once again the links: Call for presentations: https://sotm-eu.org/en/pages/cfp Talk submission: https://www.sotm-eu.org/en/presentations/new Visitor registration: https://www.sotm-eu.org/en/pages/attendees -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On Friday 14 March 2014, Florian Lohoff wrote: > [...] > > Today maintaining the Linux Kernel or OSM without a HUGE community is > a lost fight so there is nothing to gain by taking this data _from_ > the community. Those who do this are the ones to loose, not the ones > giving away their code/data. Actually the Linux kernel is a good example how big companies abuse free open products. Most famous example is of course Google with Android which circumvents the weak GPLv2 share-alike provisions and contradicts the spirit of the GPL, namely to ensure the right to freely study, modify and redistribute software by locked hardware and closed source modules. But there are many other examples of closed linux systems (like routers, nas, entertainment) that maybe release an alibi source package but without practical means to acutually make modifications. > IMHO Share Alike is proposed by those full of fear. It seems to me it is fairly damaging for the aim of abolishing share-alike to assume its proponents are driven by fear. Unless you try to convince people through arguments you have little chance in changing their opinion. Even if you manage to create a non share-alike, 'more free' OSM this will inevitably fail unless you convince the vast majority of the mappers and you cannot do that by telling them to drop their fear and relax. Keep in mind what you are essentially asking mappers here is to waive their right to freely use improvements others make to their mapping work (which is - as Simon pointed out - where share-alike kicks in). You would need good arguments for that i think and i have not heard them to this point. Note i do not have a clear position on the whole matter - as a data user i see clear disadvantages of share-alike and have to deal with them but i see no perspective to convince me, the mapper, to settle without it just because it would be more convenient/more profitable for me, the data user... ;-) -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On Thursday 13 March 2014, Tobias Knerr wrote: > > > > No, thanks, the licence is good as it is. > > Far from it, there's a lot that's wrong with the ODbL: > > First of all, it's too hard to understand. Even on legal-talk, you > often don't get useful statements about what is and what isn't > allowed. That's a no-go for an open license - those are supposed to > make things easy to use for everyone. Yes, things are complicated in some aspects and it is difficult to get reliable answers but this is not caused by share-alike per se. You can of course argue removing share-alike would make it much easier to create a simple and easy to understand license - this is not the main argument of Alex i think, namely that uses of the data should be allowed which are clearly forbidden now. I think the lack of clarity in the license terms could be well addressed by some official statements from the OSMF how they interpret various terms. Such statements would of course not be legally binding, individual mappers could still have a different opinion, but it would be a clear baseline. And also lets not forget the laws the license is based on are not clear cut either, there are many aspects of database law which are open to interpretation and which have not yet been decided in courts yet. A license can only be as clear as the law it is based on. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] new mailing list request - OSM outdoor/natural phenomena mapping
On Wednesday 05 March 2014, Richard Z. wrote: > > oh yes. You can say the same about a forrest and almost anything in > the real world. No, continuously changing properties exist for many features including for example the transit from wood to grassland but climate zones in addition have the problem of only being defined in the long term average. You will be able to determine the density of trees growing in some area at any single point of time without much effort and can use this as a basis to verifiably decide if this is a wood or not. But you will need to measure the temperature for many years to approximately determine the long term average. Precipitation is even trickier. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] new mailing list request - OSM outdoor/natural phenomena mapping
On Wednesday 05 March 2014, Richard Z. wrote: > > >climatic zones > > >vegetation zones > > >soil biology > > >vegetation layers > > > > Are any of these things verifiable? > > of course. Tons of literature about it. That is not what verifiability is about. Climate and Vegetation characteristics are generally continuously changing properties and the specific zone limits defined by some convention are not usually verifiable in the field. In case of climate zones you would for example need long term measurements at a certain place to determine if it belongs to a certain climate zone and even if you have that you cannot say anything about the climate of other locations - hence you cannot draw a boundary in a verifiable way. I explained this in case of deserts (probably the most prominent attempt to map something like this in OSM) some time ago in http://wiki.openstreetmap.org/wiki/Talk:Tag:natural%3Ddesert -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] new mailing list request - OSM outdoor/natural phenomena mapping
On Wednesday 05 March 2014, Richard Z. wrote: > Hi, > > I want to propose a new mailing list. Currently we have serious gaps > in modeling vegetation zones, climatic zones, geology, oceanography > and most other natural phenomena. Without wanting to discourage this in general - these are important subjects - there are currently no thematic mapping related lists at all so it seems somewhat odd to separate specifically these subjects. In general most discussion on such subjects is currently in tagging - which is of course somewhat questionable because not all mapping related matters are about tags. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile refresh on openstreetmap.org
On Sunday 02 March 2014, Tom Hughes wrote: > > > > http://a.tile.openstreetmap.org/11/1577/243.png/status > > yevaud: Dirty. Last rendered at Sat Feb 22 03:13:25 2014 > orm: Clean. Last rendered at Sun Mar 02 11:43:19 2014. > > > http://b.tile.openstreetmap.org/12/3154/483.png/status > > yevaud: Dirty. Last rendered at Sun Feb 23 02:00:44 2014. > orm: Clean. Last rendered at Sun Mar 02 11:43:20 2014. Based on the status i got from the tile server these two were last rendered on Jan 11 and Jan 30 before the 11:43 render today. The third one mentioned in the other mail is still on Jan 11 (don't know how long it will stay of course) If they have been rendered in between the update did not make it to the tile distribution apparently. > The four recent updates - v2.9.0, v2.9.1, v2.10.0 and v2.10.1 have > come so quickly that the z11+12 renders probably haven't been > finishing before the next one rolls out. That is highly abnormal > though. > > Andy has gone away for a few days now though, so this one should get > a chance to finish ;-) Ok - no sweat. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile refresh on openstreetmap.org
On Sunday 02 March 2014, Tom Hughes wrote: > > > > That pretty much explains my observations. By having one or > > several stylesheet updates within the monthly update cycle the > > actual update of some tiles is stretched from a month to the ~7 > > weeks i observed. > > I have no idea how you reach that conclusion - literally everything > up to z12 has been rerendered at least four times in the last month. Seems updates are progressing fast now - the previously mentioned tiles are now refreshed. Still got: http://c.tile.openstreetmap.org/11/1592/246.png/status from Sat Jan 11 04:17:46 2014 -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile refresh on openstreetmap.org
On Sunday 02 March 2014, Tom Hughes wrote: > > > > That pretty much explains my observations. By having one or > > several stylesheet updates within the monthly update cycle the > > actual update of some tiles is stretched from a month to the ~7 > > weeks i observed. > > I have no idea how you reach that conclusion - literally everything > up to z12 has been rerendered at least four times in the last month. http://a.tile.openstreetmap.org/11/1577/243.png/status http://b.tile.openstreetmap.org/12/3154/483.png/status -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile refresh on openstreetmap.org
On Sunday 02 March 2014, Tom Hughes wrote: > > > > Well - in principle i think re-rendering of very old tiles (like >2 > > weeks age) at the low zooms should take precedence over style > > induced updates at the high zooms. Not sure how feasible it is to > > implement this. > > They do. The algorithm goes something like this: > > * Update stylesheet, remembering time > * Render z0 to z10 in the background > * Mark planet as dirty, using saved time > * Start rendering z11 to z12 in the background > > [...] > > Note that nothing in z0 to z12 is marked dirty as a result of changes > to the data, so they only re-render when the style changes, or once a > month as a background job. That pretty much explains my observations. By having one or several stylesheet updates within the monthly update cycle the actual update of some tiles is stretched from a month to the ~7 weeks i observed. The solution i could envision would be to have a single render queue for the pre-rendered tiles that is prioritized based on age of the existing tile, possibly modulated with the zoom level (i.e. the age of the lowest zooms could be considered more severe than z11 and z12). This means the queue always renders the tile which has the highest need for update at the moment and you do not have the problem that several style sheet updates induce rapid re-renders of some tiles but at the same time delay updates of other tiles. In fact such a system would be fully agnostic to style sheet changes but still make sure they show up in the map as fast as possible. Not sure if this is possible with the current render stack of course. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile refresh on openstreetmap.org
On Sunday 02 March 2014, Tom Hughes wrote: > > > > The load from the re-rendering job is adjustable. Of course, if you > > go for a low load, then the re-rendering job will take a lot > > longer. > > Not really - the load we are talking about is not the pre-rendering > of low zoom, rather it is the load from normal tile requests > triggering re-rendering of high zoom tiles. Well - in principle i think re-rendering of very old tiles (like >2 weeks age) at the low zooms should take precedence over style induced updates at the high zooms. Not sure how feasible it is to implement this. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile refresh on openstreetmap.org
On Friday 28 February 2014, Tom Hughes wrote: > > There have been several stylesheet updates in the last week so the > servers are very busy and are likely to serve old tiles if they are > too busy to rerender them. I see, thanks. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tile refresh on openstreetmap.org
I have the impression the rerendering of tiles on openstreetmap.org is very slow at the moment - according to /status various z=11 tiles are from January 11. Also /dirty no more seems to work (at least not on the lower zoom levels). Has there been a change in configuration recently that caused this? -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] SOTM-EU talk submission extended
Hello everyone, the Call for Presentations for the SOTM EU conference taking place in Karlsruhe in June is extended until March 17. We have already received a lot of interesting talks and would like to give everyone who is preparing a submission a bit more time. Also if you have not yet planned to submit something or maybe have missed the previous announcements now is your chance. We specifically want to invite OSM contributors from all over Europe (and beyond) to participate and submit their topics. Talks can be submitted on the conference website: http://sotm-eu.org/en/presentations/new where you can also find further information on the event. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping flood
On Sunday 16 February 2014, Pieren wrote: > Someone is mapping the UK floods in OSM (reported on twitter): > > http://www.openstreetmap.org/way/258412163 > > Very bad idea. Yes, but note the wiki currently does not give any guidelines what degree of permanency is required for a body of water to be mapped as natural=water. There are many other examples of areas which are - if at all - merely sporadically covered with water to the extent they are mapped like: http://www.openstreetmap.org/way/23938237 http://www.openstreetmap.org/way/26645398 http://www.openstreetmap.org/relation/253952 http://www.openstreetmap.org/way/183083855 http://www.openstreetmap.org/way/71290542 -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Details about wooded belt in Saratov Oblast?
On Thursday 23 January 2014, osm@0sg.net wrote: > > today, using the OSM slippy map, I came across a regular structure in > the Saratov Oblast, Russia. Map data and aerial images suggest it be > wood or stripes of wood. It looks like a barrier. Against what or > whom? Or when was it grown? As you said these strips seem to be quite common in the area. I would assume they are trees planted for protection against wind erosion. For this purpose having a singular structure across several hundred kilometers is kind of pointless of course. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] CJK fallback fonts - testing needed
On Sunday 12 January 2014, Paul Norman wrote: > Right now the main OpenStreetMap.org stylesheet uses Unifont as a > fallback font to render Chinese, Japanese and Korean (CJK) > characters, as well as any other characters not present in the DejaVu > font. Unifont is mainly designed to support all characters, and is > not designed to look good. The problems with the fonts are not at all limited to CJK - Arabic and other languages using Arabic script are not well readable either. As Hans Schmidt said much of this is related to size - in a unified font the non-latin scripts are usually arbitrarily scaled to fit into a latin line geometry. In your demo the alternative fallbacks do not seem to contain Arabic characters - the missing glyphs are however often the ones worst to read in the normal rendering (although the other ones are not great either). -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] NYPL / map-vectorizer - An open-source map vectorizer
On Tuesday 07 January 2014, andrzej zaborowski wrote: > > The problem with potrace is that it needs exact colours without the > imperfections of paper drawings and scanner noise. I imagine the > NYPL tool is better adapted to scanned material. Well - i have not tested it so i can't really tell. In general i think filtering an image to create a plain b&w mask from a noisy color drawing is a task completely different and well separable from vectorization. I am usually a fan of the Unix philosophy of having separate tools for different tasks. One real shortcoming of potrace is that it can only deal with two different area types (i.e. two colors) - if anyone knows an open source tools with a similar feature set that does not have this limitation i would be eager to hear. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] NYPL / map-vectorizer - An open-source map vectorizer
On Monday 06 January 2014, Maurizio Napolitano wrote: > The lab of the New York Public Library created this software > to automate and extract gis data from scanned maps > http://www.gislounge.com/automating-extracting-gis-data-scanned-maps/ Note for vectorizing buildings there have also been several demonstrations based on potrace - which meanwhile features a GeoJSON backend that simplifies the process: http://wiki.openstreetmap.org/wiki/User:TomChance/VectorisingStreetView http://wiki.openstreetmap.org/wiki/User:Sorbus_x_kewensis/Vectorising_with_QGIS http://wiki.openstreetmap.org/wiki/AT/basemap -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Assembling imagery: to mosaic or not
On Friday 03 January 2014, Paul Norman wrote: > [...] The > two options are to add a number of discrete sources, or to add a > layer mosaicking them together, and displaying what the best source > is at any one point. I think this is the primary issue you need to consider. If you are sure you know what the 'best source' is at any point (which in the most general case requires in depth knowledge of the area and of the image data in question) mosaicking might be the best solution (but can be a real lot of work). If on the other hand you plan to just layer the image sources by formal quality measures (like resolution and age) to create the mosaic you will most likely end up with less than optimal quality in some areas. In addition there is of course a significant value of having multiple images available in itself since it allows the mapper to get an idea on how variable images can be. A frequent mistake in common practice armchair mapping is that people regard the image as the truth rather than a most likely inaccurate depiction of the truth. Having several images available can help here. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] SotM-EU 2014 - Call for Presentations
Hello everyone, i am pleased to announce the Call for Presentations for the SOTM-EU 2014 in June next year. Please communicate this to anyone who might might be interested in presenting something at the conference. The full text and links can also be found at the conference website (http://sotm-eu.org/en/pages/cfp) Call for Presentations Now as the cold time of the year is approaching many of you are spending the long and dark evenings working on some OpenStreetMap related projects like some tool, some mapping project or some creative use of the OpenStreetMap data. Maybe you think it would be nice to share your work with a larger European community next summer? Then we invite you to submit a presentation to the State of the Map Europe (SOTM-EU) conference in Karlsruhe, Germany in June next year. Where and when The SOTM-EU 2014 will take place in Karlsruhe from June 13-15, 2014. The conference will be hosted at Hochschule Karlsruhe. On Friday and Saturday there will be talks, and Sunday will be a hack day for practical work and discussion. Your presentation We would like SOTM-EU to be a platform for OpenStreetMap communities from across Europe, as well as for geodata professionals, cartographers and researchers, for sharing experiences, stories and knowledge around the OpenStreetMap project. In case * you are developing a tool related to OpenStreetMap for mapping, data processing, visualization or other applications * you have some mapping project, ideas on tagging or an innovative mapping technique * you are using OpenStreetMap data in a business project * you are doing research based on OpenStreetMap data * you are working on something else related to OpenStreetMap or that will be of interest for the community we invite you to submit a presentation proposal to the SOTM-EU programme committee. Are you involved with a local project anywhere in Europe? SOTM-EU is a great opportunity to present it to a Europe-wide audience. Regular talks will be 20 minutes long with five minutes for discussion. In addition we will offer the opportunity for shorter five minute lightning talks. You can submit both types of presentation in advance on the website. However, for the lightning talks there will also be the possibility of spontaneous registration at the conference. The conference language is English. Your submissions will be reviewed by a programme committee consisting of OpenStreetMap community members from various parts of Europe as well from the Hochschule Karlsruhe. Talk submission Talks can be submitted on the SOTM-EU web site (http://sotm-eu.org/en/presentations/new) where you will also find more information and updates on the conference. You should submit by February 28. We're looking forward to seeing you in Karlsruhe in June! On behalf of the SOTM-EU 2014 program committee, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The new OpenStreetMap.org design
On Wednesday 04 December 2013, John Firebaugh wrote: > > Concretely, here are the improvements we implemented: > > [...] Are there any plans to evaluate if these design goals are actually met? I know this is difficult to assess but you could do quite a bit by analyzing server logs before and after the change. Also having a poll among registered OSM users might be possible. I ask this because there are a lot of claims in your list of improvements that are plausible but not self evident and a critical evaluation of those would be prudent. In particular from my perspective (and others have made statements in a similar direction) the claim of an overall better usability is somewhat doubtful at this point. The most serious usability issues are however not inherent to the design I think so these could be solved by gradual improvements - some of them already have been addressed. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] proprietary and unrelated images on the about page
On Monday 02 December 2013, Kathleen Danielson wrote: > > Can you provide some compelling examples of images that you'd like to > see us using instead? TopOSM: http://toposm.ahlzen.com/ (various examples on http://wiki.openstreetmap.org/wiki/TopOSM) OpenSeaMap: http://map.openseamap.org/?zoom=14&lat=56.04136&lon=12.63945&layers=BFTFFFTFFFT0 OSM2World: http://maps.osm2world.org/?h=128&view=W&zoom=16&lat=48.57188&lon=13.46038&layers=B0 The Heat maps from: http://wiki.openstreetmap.org/wiki/SotM_2011_session:_Insert_Coin_To_Play The normal map in regions with non-latin script (demonstrating the international and multilingual character of the project): http://www.openstreetmap.org/#map=15/36.8092/10.1738 http://www.openstreetmap.org/#map=15/32.0951/34.7996 http://www.openstreetmap.org/#map=15/35.7375/51.5014 http://www.openstreetmap.org/#map=14/39.9178/116.3833 or the Multilingual map (http://mlm.jochentopf.com/) I know combining such to an image with harmonic colors is not easy but for this purpose it would be perfectly acceptable to tweak the colors of the various maps for an appealing collage. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline updates
On Friday 22 November 2013, Paul Norman wrote: > > A particular square (400x400 mercator km, I think) containing > coastline can be evaluated without considering the rest of the > continent thanks to the directionality of coastline ways mattering. > You'd periodically get squares that would end up incorrect, but it > wouldn't generally cause incorrect results > outside that square. I suggested something similar some time ago - processing in tiles would allow partial updates of the valid areas and the invalid tiles would simply be left in the previous state. Given the dynamics of the errors in the OSM inspector this would probably not cause any of the tiles to get overly old due to persistent errors. This is however not trivial to implement, it would not produce full unsplit polygons (which are sometimes needed - not for normal rendering though) and it would occasionally lead to small artefacts at the tile boundaries when one tile is changed and the other tile is not. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] very long multiple int_name tags in Near East
On Wednesday 20 November 2013, Peter Wendorff wrote: > > (I skipped a few because Thunderbird is nearly unusable navigating > through a mixed text of left-to-right and right-to-left languages > and/or because there isn't a corresponding localized wikipedia page > where I could have matched the languages). There is: > > (صيد) Arabic > > (صَيْدَ) Arabic with harakat (short vowel marks) The latter is not in the other name tags and since it can help to resolve possible pronounciation ambiguities it might be useful to keep it. Not sure if there is a separate language code for that. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline updates
On Monday 18 November 2013, Jochen Topf wrote: > Hi! > > For the last about two weeks we haven't gotten any coastline updates > through. The problem is that every day there is something broken > somewhere with the coastline. Often problems get fixed the same day, > but new problems show up the next. > > I have now changed the coastline update process from "once a day" to > "once every 4 hours". This means updates show up quicker in the OSM > Inspector at http://tools.geofabrik.de/osmi/?view=coastline . Sounds good. This should also increase the chance that if you see an error in the OSMI it is not already fixed (which is very common at the moment and somewhat annoying of course). How sensitive is your system by the way in discarding a coastline as broken? Obviously any unfixable error in one of the four large continental coastlines will trigger it. Same for large islands like Greenland and New Guinea i suppose. But there probably is a limit. There have for example been many coastline errors in the Philippines recently due to recent mapping activity there but many on fairly small islands. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Antimeridian
On Thursday 07 November 2013, Frederik Ramm wrote: > > http://www.openstreetmap.org/browse/way/239992362 > > and similar ways? I am leaning towards at least stripping them of the > natural=coastline (because they aren't) and of the name tag. If not > delete them altogether. As far as I know osmcoastline is currently only able to close the Antarctica coastline on its own and not other open ends further north. So these are currently needed for correct processing. The Antarctica closure segments exist as well (being split into several ways recently and thereby complicating things a bit) but they are tagged coastline=bogus to allow closing at different limits depending on the coordinate system used. Ideally none of these would be in the database (because as you said there is no coastline there). On the other hand you could of course also argue the same way that multipolygons extending across the 180°-Meridian should also be possible... -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
On Tuesday 05 November 2013, Toby Murray wrote: > [...] The > part of the river that is not in the lake changed course during a > massive flood in the 1950s but the border still follows the original > course of the river. Maybe the different handling of borders > following a natural feature is another regional difference? That could well be. Many river borders are defined in laws/treaties as the actual river meaning they move when the river changes its course. There are still different variants of definition like center line of the river on either side as well as special contructs like a Condominium for the river itself as in parts of the Luxembourg/Germany border. It is also important to keep in mind that in case of borders authoritively defined through discrete points an officially released data set does not necessarily represent exactly this definition. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
On Tuesday 05 November 2013, Jochen Topf wrote: > [...] And it is > totally unclear how things that are supposed to be changed together > (think borders following a river or road) are to be handled. And in principle the OSM data strctures are quite good for this, you can have a way with waterway=* that is part of a boundary relation. In reality borders are nearly always defined either through some real feature that is map-worthy in OSM on its own (most frequently rivers or watershed divides) or by straight lines/arcs between points with specified coordinates. The practical problem is that borders are mostly imported from external sources which do not contain the actual definition of the border but an approximation of varying accuracy. The only place where i have seen truely definition based borders in OSM are maritime boundaries like: http://www.openstreetmap.org/browse/way/48854191 -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Area mapping density gap - Was: Wikipedia article
On Saturday 26 October 2013, Florian Lohoff wrote: > > But isnt the widening gap a very natural thing to happen for a geo > database? In the end your mappers are distributed unevenly so your > pace is distributed unevenly. Not everything can be done with > armchair mapping so we as the one living in the very good mapped > areas can't help to create a complete map of very sparse mapped > areas. Different levels of completeness are natural and as i said at the beginning they will continue to exist. Having a widening range in completeness and quality however is not i think. Note i am not primarily talking about differences between areas far away from each other, like between Madagaskar and Germany. This is fully to be expected and i also don't think these differences are generally increasing. Also it would be counterproductive to try reducing this mainly through remote mapping from the distance by European mappers. I am more talking about differences at close range, take for example http://www.openstreetmap.org/#map=11/61.5554/8.4735 where one feature (the lakes) has been mapped to a high level of detail while another (the glaciers) is very crude. Again this is fully normal, whoever mapped the lakes might have been focussed on those and is not interested in the glaciers or might lack the necessary information or skills. But it seems to me there is very little communication on such matters. Partly this is a matter of having the right tools (both map notes and fixme tags are not optimal here) but it is also a matter of mapping culture i think. It bothers me when i see such things because they are strongly visible quality issues which could be solved with relatively little work. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wikipedia article
On Saturday 26 October 2013, Simon Poole wrote:
>
> But then on the other hand it is a
> fairly mature project and the easy stuff simply has been done, we
> probably can show similar trends in extremely well mapped areas.
I think this is an important point - OSM does and will for the
forseeable future contain both extremely well and extremely sparsely
mapped areas ('areas' being meant here both spatially and
thematically). One of the major tasks will be to keep both the well
mapped parts up-to-date and improve the sparsely mapped parts.
Although this is difficult to back up with numbers i have the impression
the gap between well mapped and badly mapped areas in Openstreetmap is
widening even though you would think it is much easier to improve a
badly mapped area than a well mapped one. When during use of
Openstreetmap i look at some area (because i read about it in a news
report or whatever reason) i am frequently amazed by the detailed
information i find there but i am equally often appalled by the lack of
data. One of the motivations in Wikipedia for having notability rules
certainly is to address exactly this kind of problem and to focus
efforts on those parts considered important. Openstreetmap obviously
should not follow a similar path, especially considering how it proved
damaging in Wikipedia but just attracting additional contributors is
not enough. In my opinion there is need for a more active discourse on
gaps and uniform quality of the data.
Another important difference between Wikipedia and Openstreetmap is that
OSM does not have a no-original-research-rule. In fact original
research both in-the-field and from the armchair are preferred in
comparison to second hand information (a.k.a. imports). This makes OSM
potentially much more suited for professional contributors who in
Wikipedia always risk being accused of lacking neutrality. There are
however other barriers that discourage such people to become active
contributors.
--
Christoph Hormann
http://www.imagico.de/
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Deleting data
On Saturday 19 October 2013, Frederik Ramm wrote: > > I think that is the core of the problem. For many, the visual power > of the aerial imagery is so strong that any data not matching the > imagery is deemed wrong. It seems to me instructions for beginners concerning mapping based on imagery could much better cover this matter. While the problem of position offset is frequently mentioned and illustrated in tutorials there is usually at most a simple 'be aware that things might have changed since the time the image was taken' concerning actual interpretation of the images. In my experience people for example usually only start to realize the problem of outdated images after actually seeing how things change in imagery over time (which they do not by looking at Bing etc. except if they consciously witness an image update). Interpreting aerial/satellite images is a difficult task and people who do this professionally usually spend a lot of time learning how to do it. It is not reasonable to assume that for the average OSM mapper this is so self evident that no explanation is necessary. None the less editors mostly show the images in the background and the mapper is essentially left alone with what to do with it. I think it is to be expected that there are quite a few mappers who then simply try to adjust the data to match what they see in the images by either changing, deleting or adding elements. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Combining OSM waterbody and elevation data for better map rendering and QA
Hello, I have completed a first version of a tool to modify elevation data by use of waterbody data from OSM (more precisely currently only the lakes, not the rivers). Description of the process is on [1], the tool on [2]. Primary purpose is better display of lakes in 3d renderings but this can also be useful for relief rendering in 2d maps, i.e. avoiding contours intersecting lakes and for more accurate elevation profiles of routes. The problem is of course that the processing takes some time (Europe at 1 arc second resolution about a night) and changes in the waterbody data would require updates. As a byproduct the process also puts out lists of possible errors in the waterbody data - places where the modification of the elevation model required is so large it cannot be correct. From my first look these have a fairly good signal to noise ratio, i.e. the majority of them are actually errors in the OSM data (a large fraction are shadows in imagery that have been incorrectly interpreted as water like at [3] and [4]). I put up a simple map to look at these for Europe on [5] but you can also find the point list on github. In the long term this is not overly useful as a QA tool without frequent updates of course. Greetings, Christoph [1] http://www.imagico.de/map/dem_water_en.php [2] https://github.com/imagico/dem_water [3] http://tools.geofabrik.de/mc/?lon=23.91222&lat=39.24613&zoom=13&num=2&mt0=mapnik&mt1=bing-satellite [4] http://tools.geofabrik.de/mc/?lon=6.02164&lat=60.45423&zoom=13&num=2&mt0=mapnik&mt1=bing-satellite [5] http://www.imagico.de/map/errormap_en.php -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New tile rendering (Live Worldwide)
On Monday 05 August 2013, Grant Slater wrote: > [...] > > In addition to new hardware, the rendering server also uses the new > “openstreetmap-carto” stylesheet. This is a complete re-write of the > old XML stylesheet to use CartoCSS, making it easier for our > cartographers to work with. The style is designed to look as similar > as possible to the old XML stylesheet. I am especially impressed that this also finally gives us a coastline update on openstreetmap.org - after more than half a year. :-) As for the rendering - at the southern edge there is a cutoff slightly north of the tile edge: http://www.openstreetmap.org/?lat=-84.8&lon=-167.75&zoom=6 Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] High Cartographic Quality Label Placement on OSM-based Map
On Sunday 14 July 2013, Andreas Reimer wrote: > > The whole point of algorithms research is to move beyond > implementation and do research, well on algorithms, instead of > software libraries. That Max has a very stable and functional > framework is uncommon for the scientific community. > And he built that framework mostly in his free time over the years to > better test his hypotheses & results. I never said anything about the whole framework. I am well aware there is much more to producing a map like the one you showed than just the label placement code. But the point is that for your work to contribute to scientific progress you need to make available everything others need to reproduce your research results. If you can do this just using pseudocode and verbal description that is fine. Since in your blog you cite Eduard Imhof who is well known for his ability to describe in minute detail his cartographic techniques i should probably give you the benefit of the doubt but knowing the complexity of label placement i do not expect this to be practical. Of course there is a lot of stuff published in science journals, especially wrt. algorithms that does not include the information necessary to reproduce the results. This does not make it right though and such publications usually make little contribution to the overall scientific progress. > There are strong interests at stake that make wholesale software > development at Universities a risky endeavour or plainly forbidden. > You might disagree with that, but I hope you can at least acknowledge > there are competing interests here which neither of us can change at > the moment. Of course there are competing interests but since the financiers of public research in Europe these days do not usually require or even explicitly support making available the results to the public this competition is a little one-sided. You, the researchers working at those institutions, are the only ones who can actually make a difference here. > And we > hope we pushed the boundaries in what is feasible without any > proprietary software a little bit. Just to clarify this - if the code is not available for others to use, modify and redistribute it is proprietary software, even if all code except your own is free. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] High Cartographic Quality Label Placement on OSM-based Map
On Friday 12 July 2013, Maxim Rylov wrote: > > As far as I know Mapnik and other open-source software take into > account only the rules R1, R2 and R5 (partially, returns labels that > are evenly spread out, example - http://maps.skobbler.com/on z11). > And the "greedy" algorithm that is utilized to solve the label > placement problem returns rather poor approximation to the optimum as > there is no backtracking. I see - Mapnik labeling is well known to be quite bad so it is not really a good competition. But you have not said which of these rules are followed by your method. There seems to be an (only partially successful) attempt in R3 and R4 but R8 does not seem to play a role. R1 in several cases seems to work better in Mapnik. > > Is the algorithm available as open source? > > Unfortunately, the algorithm currently is not open-source, but the > model that we elaborated and used will be published as a journal > paper within the next few months. Well - Peter has already commented on this and i mostly agree with him. But i would actually emphasize a more practical point: Since this is meant to be scientific research one can assume you publish it to allow others to independently verify your work, compare it to their own and possibly improve it - this is in the very definition of scientific work. When dealing with fairly complex algorithms like here this is next to impossible to do without publishing the code. Now i understand you might be reluctant to make available the code before a journal publication and you would not necessarily need to make it open source/free software license wise although this would be advisable as a matter of fairness when extensively using Openstreetmap data. And i won't even get started on the fact that work of a publicly funded research institution should benefit the public... Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] High Cartographic Quality Label Placement on OSM-based Map
On Thursday 11 July 2013, Maxim Rylov wrote: > Hi all, > > We are pleased to announce that a new web map based on OSM data has > just been published. You can see it on > http://openmapsurfer.uni-hd.de/ (OSM Roads (New) layer). > One thing that greatly distinguishes it from other online maps is the > quality of map lettering. Could you explain in what ways this is the case. Since different types of labels are shown in various maps direct comparison is difficult. You seem to very well avoid overlaps between labels and none the less you are able to put quite a lot of them on the map but non-label feature do not appear to play a role in label placement and there are some strange priorities. Is the algorithm available as open source? Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On Saturday 06 July 2013, Christian Quest wrote: > I slightly modified the boundary rendering > I also added islands and archipelago rendering, which makes seas a > bit less empty... > > Example: > http://tile.openstreetmap.fr/?zoom=7&lat=58.13383&lon=-2.9452&layers= >B0FFF I very much like the island labels - this would be great to have in the standard map (at the moment i think islands are not labeled there until z=12 which is kind of pointless for any but the smallest islands - especially in polar regions). And of course it well points out missing names (and in this case missing french names). I guess the lack of labels in the north of http://tile.openstreetmap.fr/?zoom=6&lat=-56.31392&lon=-34.0843&layers=B0FFF is due to incomplete rendering. The style also produces some funny stuff like: http://tile.openstreetmap.fr/?zoom=11&lat=-53.14353&lon=73.053&layers=B0FFF Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On Thursday 04 July 2013, Tom Hughes wrote: > > Low zooms (0 to 12) are not actually updated in real time anyway - > they are only updated periodically by a batch job. But you can still trigger a rerender using /dirty. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On Thursday 04 July 2013, Tirkon wrote: > [...] > The first priority for rendering could be the admin level. Within the > admin level at first the towns with a capital tag are rendered wirh a > star next to the name. If this is space-kompetitiv at a given zoom > level, the winner will be decided on the population. Then all other > towns of the given admin level are rendered. Space-competition is > decided first on the place tag (which could indicate independent > cities) and then on population. The problem about this is not how to do it in principle but that label placement optimization is a highly non-local problem so doing it well requires doing it for the whole globe at once and you would have to redo it every time something changes anywhere. Even the current very simple approach suffers from this problem resulting in occasional cut off labels at tile edges. The thing is the standard osm.org map is meant to allow near real time updates and compromises rendering quality for that. But there is very little actual real time data in the rendering at the lowest zoom levels anyway - none in 0 and 1, only labels in 2 and 3. Frederik's approach would bring the real time osm data to the lower zoom levels but in the end only few of the individual changes in the database have a visible effect on the map at this scale. So it would make sense to take a split approach to the lower zoom levels - create a real time version that allows reviewing edits made to the database and a second high quality version that is pre-rendered periodically using techniques that can be more expensive. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Use of OSM data by UNEP without proper attribution
On Thursday 04 July 2013, Mikel Maron wrote: > I just now have contact directly with those involved (relatively fast > for a big organization), and am explaining the issue to them. Great, thanks for that. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Use of OSM data by UNEP without proper attribution
On Sunday 23 June 2013, Mikel Maron wrote: > I'm checking into it with contacts at UNEP. > Hello Mikel, any news on that? The website is still the same. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On Sunday 30 June 2013, Frederik Ramm wrote: > > * To produce the "raw" tiles for z-1 (which are never visible but > only used as an input for z-2 tiles later), I not only downscale the > tiles on z, but after that, use ImageMagick's "Compose" function with > a mode of "Darken" to repeat the placement of downscaled tiles three > times, with an offset of (0,1), (1,0) and (1,1). This step is crucial > because otherwise the roads would thin out to a "hint of road" after > 2 scale-down steps, but at the same time this is also resposible for > the darkening of tiles as you get to lower zooms. (The "Darken" > method chooses the darker of the two inputs.) I see - when you do this just one zoom level above you will likely get significant aliasing (the offset operations introduce 2x2 pixel structures which are then resized to half the size). In my experience such morphological tricks work best with at least two zoom levels difference between processing and target grid: convert z9.png \( +clone -morphology Erode Disk:2.5 \) \ -compose Darken -composite -scale 12.5% z6.png > I would be happy to hear ideas about how to do this differently, and > try them out. If you want to emphasize the roads it would probably be best to render them separately at z=9 to be able to process them in a different way. This would double the ressources required of course. You can also try something like: convert -sigmoidal-contrast 15,50% -scale 12.5% \ +sigmoidal-contrast 15,50% z9.png z6.png this will however somewhat distort the colors when you do it in RGB. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On Sunday 30 June 2013, Frederik Ramm wrote: > > I have updated these tiles with current data. (I had somehow lost the > code that produced the tiles and had to reverse engineer my way back > from the old tiles... the year-old tiles are still available from the > layer switcher.) Hello Fred, what method did you use for resizing the tiles? It seems to be different in the new and the old tiles emphasizing the line features now. Since the tiles darken as you zoom out you are probably resizing in gamma corrected color space which is not such a good idea (for example Labrador is dissolving into the ocean as you zoom out). A good starting point for resizing techniques in general is: http://www.imagemagick.org/Usage/resize/ And when rendering the various area features at z=9 it would probably be best to turn off the area patterns like on the glaciers which just result in artefacts when scaling down. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Use of OSM data by UNEP without proper attribution
Hello, I just saw that the Global Islands Database by the United Nations Environment Programme and Partners: http://gidtool.unep-wcmc.org/ is using OSM coastline data. They also say so in the 'about' info box: "The Global Islands Database is originally based on Open Street Map (using a 1:75,000 Landsat product from the US National Geospatial - Intelligence Agency) and has been substantially refined through the work of a number of organisations (e.g. UNEP-WCMC, Island Conservation, BirdLife International, RSPB, IUCN/SSC ISSG, PIER, Global Island Network). The Global Islands Database is an intermediate product that is continuously being refined by the user community." but this is certainly no sufficient as attribution no matter if ODBL or CC and their data license: http://www.unep-wcmc.org/general-data-licence-excluding-wdpa_559.html is obviously incompatible. Comparisons at a few locations indeed show OSM data is widely used there (including non-PGS data) while there are also areas with significantly better data than OSM as well as various larger errors (i.e. fake islands). And of course some of the more recent changes in OSM are not in there. I am unsure what should be done about this. There are probably no bad intentions there and if the mentioned organisations have indeed contributed better data it might be nice to have this available to OSM as well. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Good practices violated?
On Thursday 30 May 2013, Jakub wrote: > > PS: I beleive that this problem is much more general, it is also true > with all sorts of regions, cities and villages. Names are rendered > two or three times and is not good at all. This is also common for islands and in some form also for seas/oceans (where there is no geometry at all except for the labeling node). The underlying reason is in part that normal rendering has to be done directly from the database in real time and this does not allow for any more expensive computations for label placement. Toby described this in more detail. Somewhat related is the problem of label placement by the renderer with overlapping labels of different type and suboptimal priorities in selection of labels. The only solution to this seems to be to introduce a preprocessing step generating the labeling information from the map data that is not done in real time and therefore can be more expensive. There is one other place where this is already done in OSM, that is the coastlines and as many are painfully aware this is not working particularly well (current coastline on osm.org is nearly four months old). Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] List: Densely Mapped Areas
On Friday 24 May 2013, Frederik Ramm wrote: > > I re-did the list with "nodes per square kilometre", although this > also renders the basic idea of looking at z16 meta tiles kind of > arbitrary. Yes, it even gives a slight disadvantage of the equatorial areas now: They need to achieve a high mapping density across a larger area to get a good score... > Someone said that taking the area into account should improve the > results for Indonesia; either I did something wrong ior the opposite > is the case - Indonesia featured at #23 before and has now dropped > completely off the list. I think you did correctly, it's the other way round but the difference between Cameroon and Indonesia is marginal. Arkhangelsk seems to be the only high latitude place that newly made it into the new list. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] List: Densely Mapped Areas
By the way you do realize that Cameroon and other equatorial areas have a significant advantage to higher latitudes in this measurement. So it might be prudent to not only say 'FSVO mapped' but also 'FSVO densely'. In a quick estimate the area scale ratio between Cameroon and France is about 2 so it could be that Bordeaux beats Yaounde in real world node density. :-) -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] List: Densely Mapped Areas
On Friday 24 May 2013, Frederik Ramm wrote: > Hi, > > I've made an updatd list of densely mapped areas in OSM. > > http://fred.dev.openstreetmap.org/density/ > > You might be surprised to hear that the top four most densely mapped > areas in OSM are in Cameroon! I incidently saw that in Cameroon recently - the contrast to the more average density around is particularly striking. It might be an interesting test case to see if imports do sustainably improve quality - if in a year the contrast is significantly reduced by manual mapping of the areas around this would be a strong indication. Currently it has a kind of Berlin airport flair... Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] source=Google
On Saturday 18 May 2013, Martin Koppenhoefer wrote: > [...] Usually with aerial > imagery from webmaps you also don't see from when they are, at least > almost nobody stores this information in the source tag, but it is > much more relevant (IMHO) to know "traced from aerial imagery from > 2007" than "traced from bing aerials" Much agreed, date of the images is much more relevant than the provider. The lack of this information in Bing etc. combined with the fact that first hand survey information is usually entered shortly after the survey has lead to a lack of practical need for entering this information. > Your mention of geometry metadata reminds me of another point: a > simple "source" is not enough, you'd need a distinct source tag for > all properties not one source for the whole object. I already had that in mind - i just explained it for the geometry only. Each tag could have its own metadata and this would be reset everytime the tag value is changed. And of course in addition to 'source' one could think of various other metadata types. The date is obvious but accuracy as well as reliability information could also be useful metadata. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] source=Google
On Saturday 18 May 2013, Yohan Boniface wrote: > On 05/18/2013 03:55 PM, malenki wrote: > > Dave F. wrote: > >> IMO Source should be on the object, not on the changeset. > > > > +1 (except if there is one changeset for one object (; ) > > This is not my opinion. Let's take a simple example: a school. > > [...] The problem is currently neither changeset nor object tags are really a good solution for true metadata (that is information characterizing the data and not the real world object). Changeset tags have mainly two problems: - they always apply to the whole changeset so everything you map together needs to have the same metadata. This might seem to be a problem primarily for imports but it can also be troublesome in manual mapping - imagine mapping something based on satellite images and you need to use different images for various parts due to clouds or even the common case of supplementing survey data with Bing images. - many large objects are included in a lot of changesets without actually being substantially modified (like moving a single node in a 500 node way etc.) This means finding the actual changeset a certain geometry originates from to get the metadata information is not so easy. The solution in my opinion would be to have separate metadata tags which are reset everytime a substantial change is made to the data they refer to unless the user explicitly sets them (either individually or for the whole changeset). Geometry metadata tags for example would be reset if: - in case of a node the node is moved - in case of a way more than X percent of the nodes are changed (X being something like 30) - in case of a multipolygon more than X percent of the ways are added/removed or substantially modified This would not be fool proof of course (small changes could accumulate to a substantial change without being noticed). Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] ADD import (Antarctica natural features and POIs)
There does not seem to be any serious objection so i am going to proceed converting the data. Two minor changes: - use capacity:persons instead of capacity for the research station capacity value. - only maintain the ADD:* tags derived from the original data attributes for the coastlines and POIs, not for the streams. It is doubtful how useful this data will be in the future. In case of the coastline it could help deciding on future updates though (since age and resolution of the ADD data varies quite a lot). The whole matter of source metadata to me seems to be an open issue in Openstreetmap. One can introduce such data through tags but there is no mechanism ensuring this information stays valid - geometries and tags can be and are changed independently so there is no way to verify if source attributes are actually valid without looking in detail at the whole editing history. I know that because of this the recommendation is to apply source tags to the changeset rather than the geometries. This is not feasible in case of fine grained attributes like the ADD coastline though where every way has different attributes. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] ADD import (Antarctica natural features and POIs)
Hello, during preparation of the Antarctica coastline import [1] i had also contacted the SCAR for possible use of the ADD [2] and got a positive reply while we were doing the MOA import. I here want to introduce this data source and discuss plans for import into OSM. About the data: The Antarctic Digital Database contains geographic data from various sources assembled and maintained by the SCAR - the organization that coordinates scientific activities in Antarctica under the Antarctic Treaty. Of interest for OSM are: - coastlines and shelf ice extent, more detailed (especially many more small islands) and more up-to-date (especially ice shelf changes) than the previously imported MOA data - data for the ice free areas (currently mostly unmapped in OSM) - moraines, lakes and streams - research stations and airfields (most of these are probably already in OSM) - historic sites Some more information on the data can be found in my blog post [3]. The import: the amount of data is quite large so it needs to be split into smaller chunks for import - the tiling planned can be found on [4]. I set up a conversion for the data and produced a few sample files that can be downloaded and reviewed [5]. Once the conversion rules are finalized i will convert all tiles and make them available for distributed import. To discuss: The rules for tagging i used can be found on [5] - this is what seems appropriate to me - feel free to suggest changes. One thing i was not sure about is how to best apply a natural=* tag to a small island (a closed way already tagged natural=coastline). I see three options: 1) duplicate the way 2) tag natural=coastline;whatever 3) create a multipolygon relation containing a single way with natural=* I used option 3 but i could not find any definitive answer to this question so i will leave it open for discussion. Greetings, Christoph [1] http://wiki.openstreetmap.org/wiki/Antarctica/Import_2013 [2] http://www.add.scar.org/ [3] http://blog.imagico.de/more-antarctica-mapping/ [4] http://wiki.openstreetmap.org/wiki/Antarctic_Digital_Database [5] http://wiki.openstreetmap.org/wiki/Antarctic_Digital_Database/Data -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
