Re: [OSM-talk] Entances (was Layers and landuse)
On Tue, Jun 30, 2015 at 03:47:14PM +0100, Lester Caine wrote: On 30/06/15 11:36, Richard Z. wrote: On Mon, Jun 29, 2015 at 04:14:07PM +0100, Lester Caine wrote: On 29/06/15 15:08, Martin Koppenhoefer wrote: The step from 2D to 3D would add a lot of complexity on the mappers, narrowing down the mass of contributors potentially willing and able to participate. Everyone would have to deal with this: It's difficult to imagine introducing 3D in parallel (as long as you don't do it completely disconnected, i.e. a fork), because everything is connected and someone not aware of 3D information would damage it inadvertently as soon as he was starting to make 2D edits on 3D data. I'm not so bothered about 3D, but rather making it a little clearer on 2D maps that one HAS to go a particular way when the road other side of the building IS 5 stories below, and the main road is three stories below that. People who have visited Malta will know what I am saying, but following a satnav somewhere you don't know after a long flight ... it would be nice if the map warned you :) In some cases you could use embankment, natural=cliff or building=wall separating the road and the building would that work here? http://www.openstreetmap.org/#map=18/35.95833/14.36246 was where I had the fun at Christmas. Vertically this area is well over 10 stories high which the steps only hint at. We stayed at the Pergola Club Hotel and the osmand took me to the bottom of the Trig Adenau steps while the entrance to the car park was 5 stories above :) Other parts of Malta were just as much fun ... and while around here is not quite so steep, there are a number of places with similar problems when trying to work out just where to drive. The map link does not tell me much, need a house object or something like that to look at. have you tried any of these? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_entrance http://wiki.openstreetmap.org/wiki/Key:entrance http://wiki.openstreetmap.org/wiki/Relation:building imho a good routing program would display a list of existing entrance points and let you choose from those. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mechanical edits
On Mon, Jun 29, 2015 at 05:12:24PM +0200, Michael Reichert wrote: A large bounding box of a changeset is not a proof that the edit is mechanical. There are also users at OSM who first edit an object in Europe and afterwards in America before they upload their changes. (This usually happens if the user uses JOSM oder Potlatch 2) On the other hand, it is possible that a users who performs a mechanical edit uploads his changes in small chunks, each having a small bounding box (few square kilometers). true, nevertheless small bounding boxes should be strongly encouraged by any means to make history viewing somewhat more useful. The current trend that someone makes changes involving a few points and tags with a bounding box covering the larger part of the worlds is very unfortunate. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layers and landuse
On Mon, Jun 29, 2015 at 04:14:07PM +0100, Lester Caine wrote: On 29/06/15 15:08, Martin Koppenhoefer wrote: The step from 2D to 3D would add a lot of complexity on the mappers, narrowing down the mass of contributors potentially willing and able to participate. Everyone would have to deal with this: It's difficult to imagine introducing 3D in parallel (as long as you don't do it completely disconnected, i.e. a fork), because everything is connected and someone not aware of 3D information would damage it inadvertently as soon as he was starting to make 2D edits on 3D data. I'm not so bothered about 3D, but rather making it a little clearer on 2D maps that one HAS to go a particular way when the road other side of the building IS 5 stories below, and the main road is three stories below that. People who have visited Malta will know what I am saying, but following a satnav somewhere you don't know after a long flight ... it would be nice if the map warned you :) In some cases you could use embankment, natural=cliff or building=wall separating the road and the building would that work here? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layers and landuse
On Sat, Jun 27, 2015 at 10:40:52AM +0200, Ture Pålsson wrote: I recently taught my rendering hack about the ’layer’ tag, and immediately encountered a set of new problems. For example, consider this ditch: http://www.openstreetmap.org/way/243331898 http://www.openstreetmap.org/way/243331898 . It has layer=-1, probably to indicate that is passes under the road which it crosses. However, it is entirely covered by a landuse=farmland with no layer tag, which I take to mean an implicit layer=0. This means that my renderer now renders the farmland over the ditch, completely hiding the latter. Meanwhile, Mapnik obviously does what the tagger intended. Is this a tagging error, that I should fix by editing the data, or is it something that my renderer should be able to cope with? it is an error and your renderer should be able to cope with it as it is a pretty common error. Simply ignore any layer tags which are not in combination with bridge,tunnel,covered, steps,indoor or similar - the key:layer wikipage has a longer list of combinations that seem legit. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki: Adblock blocks Wikimedia Commons images
On Mon, Jun 15, 2015 at 02:45:54AM +0200, Andreas Goss wrote: I was pretty annoyed recently, because every now and then a wikimedia image I used in a ValueTemplate would not work. For some reason I decided to check Privacy Badger today and after that disable Adblock. Well, that did the job. Not sure if we can do anything, but for people who frequently edit the wiki, maybe just whilelist the domain so you don't waste yout time trying to figure out why images are not working. Not really sure why it sometimes works and sometimes doesn't so far... that should be easy to figure out, from the ABP button do open blockable items and see what is blocked (shown in red). Hower over it with the mouse and see which filter is repsonsible. Right click the item and add exception or even better go to the relevant addblock/filter forum and report it as false positive. Richard ___ 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 Sun, May 17, 2015 at 05:09:59PM +0200, Jochen Topf wrote: 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. probably doing more harm than good by preventing caching. In Firefox the number of connections is settable and imho high enough: http://kb.mozillazine.org/Network.http.max-connections-per-server Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] contact: tags
On Sun, May 10, 2015 at 01:31:52PM +0200, Andreas Goss wrote: On 5/7/15 16:40 , Richard Z. wrote: indeed my intention was to use contact:twitter exactly when a company explicitly recommends it as a way to contact them whereas twitter=* could be used to mean anything else. 1. That's not how it's been used currently 2. How would we ensure every mapper knows the difference? 3. Even if for some magical reason people understand the difference, how many will bother checking that? #4 how do we know how many of all these phone=* and other entries are valid and verifiable? Was there ever any attempt at quality control? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Looking for maps with rendered toll status
On Sun, May 10, 2015 at 10:27:54AM +0200, Mateusz Konieczny wrote: I am looking for examples how toll status of roads is displayed on existing maps. I am considering rendering toll status in openstreetmap-carto. But I have no good ideas how it may be done and I failed to find maps displaying this data by using a different style for roads. one example that I have seen on paper maps was a red-dotted line on the road. I think OpenAndroMaps does implement this. Some maps have symbols for toll-collection points. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] contact: tags
On Wed, May 06, 2015 at 11:37:41PM +0200, Andreas Goss wrote: the verbosity may be unneeded for very simple things like phone but is that true for everything covered by contact* ? key:fax? key:twitter? key:vhf? So what would you do with those tags? If we don't use contact for phone, it makes no sense at all to use it for something like social media etc. it does make a lot of sense to catch all the less frequently used contact methods which would otherwise require special treatment and own documentation pages. Maybe phone deserves special treatment but I would also prefer contact:phone over phone=* btw. In addition I think if the emphasis on contact was really that you can actually contact someone (contact:phone) then contact:twitter is also flat out wrong, because many companies will not reply and maybe not even read what you tweet them. this is one of the reasons why contact:twitter is much better then twitter=* because the first one explicitly says it can be used for contacting while the other could mean anything else that you can do with twitter. Likewise contact:website is reasonably clear while website=* may or may not offer a contact method. In addition most companies will have different web pages for different purposes and website=* would be typically the main page and not the contact form. Another reason why I prefer contact:* over phone/vhf/drums main keys is that I believe mapping phone numbers and websites is not the mainstay of OSM so it is good to prevent too much polution of the key namespace with things like vhf=*. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Problems with the wiki (was Why OSM and not another collaborative mapping service?)
On Thu, May 07, 2015 at 12:49:40PM +0100, SomeoneElse wrote: This page is an excellent example of what can go wrong with the OSM wiki. Yet another example why the wiki needs some love. If random edits like this are allowed to continue*** it'll devalue the wiki even more as a resource. I'm not a wiki admin, but I'm sure that those who are are well aware of this problem and I would hope they are already considering what to do here. Random edits should be allowed. Maybe edits without summary should be forbidden and deliberately misleading comments punished. More people should watch new pages, http://wiki.openstreetmap.org/wiki/Special:NewPages is not exactly obvious to find. If it does not help it could be mandatory for new pages to have some categories which would help people to watch what they are interested in. Do we really need http://wiki.openstreetmap.org/w/index.php?title=POI:Loblawsredirect=no One issue that I have - http://wiki.openstreetmap.org/wiki/Special:RecentChanges displays only the changes for the last few minutes and I don't see any setting to change that? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] contact: tags
On Thu, May 07, 2015 at 04:20:22PM +0200, Martin Koppenhoefer wrote: Am 07.05.2015 um 13:50 schrieb Richard Z. ricoz@gmail.com: then contact:twitter is also flat out wrong, because many companies will not reply and maybe not even read what you tweet them. this is one of the reasons why contact:twitter is much better then twitter=* because the first one explicitly says it can be used for contacting while the other could mean anything else that you can do with twitter. people will not be more inclined to respond to enquiries via a certain medium if we put a contact prefix in osm, or did I misunderstand you and you propose to use both tags, one for their Twitter account and the other if they react to Twitter messages? indeed my intention was to use contact:twitter exactly when a company explicitly recommends it as a way to contact them whereas twitter=* could be used to mean anything else. In addition most companies will have different web pages for different purposes and website=* would be typically the main page and not the contact form. wouldn't contact:url or contact:webpage then be a better tag for this? That is what I was trying to say:) Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] contact: tags
On Tue, May 05, 2015 at 06:20:42PM +0200, Martin Koppenhoefer wrote: 2015-05-05 17:21 GMT+02:00 Richard Z. ricoz@gmail.com: the verbosity may be unneeded for very simple things like phone but is that true for everything covered by contact* ? key:fax? key:twitter? key:vhf? have you seen taginfo? 906 vhf 182 vhf_channel 73 waterway:vhf_channel 36 lock:VHF_channel 32 VHF 16 contact:vhf imho key:vhf is pretty poor choice of a tag name and the usage count is overall not so large. http://taginfo.osm.org/search?q=vhf twitter and fax are less clear, but the contact:-form is always less in use. still sceptical. If someone wants to write an app displaying contact info he could blindly output contact:.* or put together a list of many dozens of tags like phone,fax,email,facebook,vk,xing and still won't be able to retrieve contact of a site that has more exotic means of communication like smoke signals or drums. Even collecting all the existing tags looks like a huge pain in the b..t if they are not documented or prefixed by contact:. The usage of the four most popular contact: entries reaches almost 200,000 which is not too bad. Also I am not quite sure how many of those entries are actually valid, taginfo is not a great help here: http://taginfo.osm.org/keys/phone#values http://taginfo.osm.org/keys/contact:phone#values Btw anyone knows what phone=3631 is ? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] contact: tags
On Sun, May 03, 2015 at 11:17:35AM -0400, Andrew MacKinnon wrote: The reason is that the contact: tags are unnecessarily verbose (we should use simpler tags whenever possible) and the simpler tags are much more popular (there are 98865 contact:phone tags but 490328 phone tags). Why do we need to have more than one way of tagging common things like phone numbers? the verbosity may be unneeded for very simple things like phone but is that true for everything covered by contact* ? key:fax? key:twitter? key:vhf? So what would you do with those tags? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] HTTPS auf overpass-api.de
On Thu, Mar 26, 2015 at 07:24:18PM +0100, Roland Olbricht wrote: Im Gegensatz dazu verbreitet sich mit Certificate Pinning [6] ein Verfahren, das inhärent große Anbieter bevorzugt: man muss sich wieder mit dem Browser-Hersteller gutstellen, damit er für die eigene Seite nur die Zertifikate eines einzelnen Anbieters akzeptiert. In der Praxis wird das heißen, eine Bürokratie zu durchlaufen, Geld auf den Tisch zu legen oder eine Kombination aus beidem. Wie aussichtsreich das für die Seiten im OSM-Umfeld ist, kann man an dem Umgang mit CACert absehen. Certificate pinning geht wohl auf verschiedene Arten. Die einzige sichere Methode des Cert-pinnings funktioniert glücklicherweise für Jedermann und gratis: man besorgt sich den public key des Servers, verifiziert diesen manuel über einen sicheren Kanal und benutzt Programme die manuelles Certificate pinning unterstützten. Auf Anhieb fällt mir curl --pinnedpubkey key ein. Vorteil - man benutzt von vornherein ein selbstsigniertes Zertifikat welches nichts kostet. Im Firefox geht es im Prinzip auch (NICHT NACHMACHEN): einfach *alle* root-Zertifikate entfernen - jedesmal wenn Firefox ein neues https Zertifikat sieht wird man gefragt ob man dieses akzeptieren möchte, kann den fingerprint vergleichen usw. Funktioniert in der Praxis leider überhaupt so gut - Filterlisten- abonments vom adblocker und AJAX requests gehen meistens schief oder erfordern sehr hohen manuellen Aufwand. Trotzdem würde ich jedem Raten sich die Liste der im Browser installierten Root-zertifikate anzuschauen und radikal zu kürzen - insbesondere vor Aulsandsreisen. Jede dieser root-ca kann einem jederzeit eine falsches Zertifikat für jede beliebige Domain einspielen und in vielen Asiatischen Ländern würde ich fest damit rechnen, daß dies von den nationalen root-cas auch flächendeckend gemacht wird. Auch eine bekannte Fluggeselschaft wurde unlängst auch dabei ertappt wie sie bein in-flight Netzverbindungen gefälschte Zertifikate eingesetzt hat um den HTTPS Verkehr über proxies umzuleiten. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Finding a user from a tag/value?
On Sun, Mar 01, 2015 at 06:23:19PM +1100, Warin wrote: Hi, 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? you may also want to search list archives for need advice for clever query or script, my problem back then was * find all bridge=swing * split results by the first contributor who added bridge=swing to the way * get the results into JOSM for examination and editing and Imre Sau did the hard work for me and created this script: https://gist.github.com/ImreSamu/be49fd1ce511975325d2#file-bridge_swing-sh Richard --- Name and OpenPGP keys available from pgp key servers ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
On Thu, Feb 19, 2015 at 11:31:55AM +0100, Martin Vonwald wrote: Hi! Am 19. Februar 2015 um 10:46 schrieb Eifelhunde eifelhu...@gmx.de: Sehe ich weniger problematisch, oder werden kurvenreiche Strecken auch berücksichtigt? Häufig sind doch diese nicht beschränkt, erlauben aber wegen der vielen Kurven nur geringe Geschwindigkeiten ??? es gilt in jedem Land ein generelles Maxspeed (in D außer Autobahnen) Ich versteh die Anmerkung nicht, es besteht doch nicht die Pflicht so schnell zu fahren - selbst wenn Schilder die Geschwindigkeit weiter beschränken ist die Geschwindigkeit keine Pflicht Kein professioneller Router geht davon aus, dass man die maximal erlaubte Geschwindigkeit auch tatsächlich fahren kann. Je nach Verlauf der Straße werden deutlich niedrigere Geschwindigkeiten angenommen. Auf einer völlig geraden Autobahn im ebenen Gebiet nimmt ein guter Router eine Geschwindigkeit nahe der erlaubten an, idR ca. 5%-10% darunter. Auf einer Passstraße, wo sich eine Serpentine an die nächste reiht, interessiert einen professionellen Router die maximal erlaubte Geschwindigkeit nur noch am Rande und es werden so Geschwindigkeiten z.B. im Bereich von 20-50km/h unterstellt, selbst wenn dort 100km/h erlaubt ist. Diese Geschwindigkeiten werden dann für die Routenfindung verwendet. egal ob das anhand der Geometrie oder tags passiert, solche Heuristiken funktionieren bestenfalls sehr grob. Die Faktoren die man mappen müßte sind einfach zu viel und wären im Endeffekt sowieso subjektiv: Sichbeinträchtigugn in den Kurven, Straßenrandbeschaffenheit, herumschleichende Touristenautos, Fußgänger/Radfahrer auf der Straße, parkende Autos am Straßenrand, rush hour u.v.A. Enwteder irgendeine der Average speed per way Datenbanken wird dauerhaft wiederbelebt oder etwas wie http://wiki.openstreetmap.org/wiki/Proposed_features/Practical_maxspeed Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Big Lakes
On Tue, Feb 17, 2015 at 07:45:31PM +0100, malenki wrote: I am working on Lake Nasser* and can predict that after enhancing it's shore the resulting MP will be quite big. Based on what I have done so far I'd expect an Multipolygon (MP) with about 10.000 Members and an outline of 14.000 km length. A relation of this size is no good idea in hindsight of maintainability and conflicts due simultaneous edits. So I thought about mapping it as coastline (again) and had a look at how other big lakes were mapped. thanks for the interesting analysis. Now my questions: What do you think is the better way to map an updated Lake Nasser? Make another MMP (Monster MultiPolygon) or map it as coastline (which is discouraged in the wiki)? 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. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM contact for complicated licence violation investigation
Hi, came across a pretty major license violation and need technical help and another pair of eyes to figure out what is going on. Semi-confidential at this point. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Android Network Location Providers?
On Tue, Feb 10, 2015 at 02:36:13AM -0600, Paul Johnson wrote: As I've experienced unusually poor performance with Google's NLP in Android, I was wondering if anybody knew of a dropin replacement I can install that cuts Google's NLP while still allowing NLP through some kind of open means, even if self-generated on the device? f-droid.org has something, and more pointers in forums. I have not tested any of these. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Android Network Location Providers?
On Tue, Feb 10, 2015 at 06:00:29AM -0600, Paul Johnson wrote: I'd be curious if you have specific links. one that I was looking at is this: https://f-droid.org/repository/browse/?fdfilter=locationfdid=org.fitchfamily.android.gsmlocationfdpage=2 Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Wehr - Schleuse
On Tue, Jan 06, 2015 at 10:22:59AM +0100, Volker Schmidt wrote: Ich habe in waterway=sluice_gate benutzt. bitte keine falsche Scheu das auch mal im wiki zu Dokumentieren. Im wiki steht nur http://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate wo das tagging ganz anders aussieht? Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] MEP - pipelines
On Sat, Jan 03, 2015 at 05:22:17PM +, Chris Hill wrote: On 03/01/15 16:50, Rainer Fügenstein wrote: in accordance to the mechanical edit policy, I'd like to open the discussion on this list: a recently approved proposal introduced new tags for pipelines and marker [1] and changed an established tag: type=* was changed to substance=* The values may need changing, e.g. type=sewer become substance=sewage the main reason for this change was a (possible) conflict with type=* as used in relations. also, type=* was considered to be too generic to describe the medium flowing within pipelines. this requires a mechanical update of existing data: No, just because a handful of wiki 'votes' does not mandate a mechanical edit. handful of votes? The proposal was really hard to miss so everyone who wanted to vote did so. What about the maps I produce for my client? You're not likely to know about it as it is a private project. If you make a mechanical edit that breaks my render, should I send the bill for the changes to you rather than ask my client to pay? (This is not hypothetical I really do have a render using pipelines. I'm also using pipeline data to calculate approximations of distribution and aggregation). there are friendlier ways to ask someone that you need more time to catchup with your private project after Xmas vacation. The change is reasonable and the use of type was suboptimal in this setting. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MEP - pipelines
On Sun, Jan 04, 2015 at 09:18:57AM -0200, Lists wrote: May I suggest the following work flow: 1) Agree upon 2 dates sufficiently spaced i.e. 2 weeks apart 2) First date, add the new tag, leave the old tag in the system. This will not break anything, and from that date data consumers know they can start migrating their renderers, harvesters, or whatever into the new scheme without loss of data integrity 3) Run sanity checks on the data, maybe manually correct slips such as type=sewer - substance=sewage if needed 4) On Second date remove the unwanted key, objects where the key should remain should have been flagged by now, and data consumers should all be on the new scheme also. 5) Define an interval to re-run the scripts if it is probable that anybody still might use the old scheme. it needs more flexible rules and generally the suggested 2 weeks are extremely short. For example we still have many (not counted) culvert=yes even though it is considered obsolete since a long time. In those cases (like here) when it is possible to have the old and new tagging in parallel the transition could be done in two steps long apart. This should be the general rule for mechanical edits when migrating tagging schemes. Also make sure that editors such as Potlatch2, iD, JOSM and Merkaartor, all have corrected their presets by the second date. If old scheme is stuck in the preset than it is likely that old scheme will continue to be used. also to be considered if keepright or similar need adjustments Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] 663 Bäume mit identischer Internetaddresse..
Hi, sieht fast nach einem spam-Versuch aus? http://taginfo.openstreetmap.org/tags/?key=contact%3Awebsitevalue=http%3A%2F%2Fwww.ruheforst-vogelsberg.de%2Findex.php%3Fseite%3DKonzept%26h%3D2#overview Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] wiki history function problem?
Hi, since some time the wiki history (show diffs between versions) always displays empty changesets for me: http://wiki.openstreetmap.org/w/index.php?title=Date_namespacediff=1119628oldid=1119586 displays an empty box and says (Nessuna differenza) which is clearly wrong. Did anyone else notice the problem? I am logged in and have my settings to only display diffs, not full page. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse vs Vegetation vs Landcover proposed cleanup at wiki
On Sun, Nov 30, 2014 at 11:04:28AM +0400, Никита wrote: We have highly inconsistent content at wiki (feature pages http://wiki.openstreetmap.org/wiki/Category:Features). Inconsistency is not limited to landuse=wood/natural=forest. Another example is landuse=meadow (Landuse http://wiki.openstreetmap.org/wiki/Landuse, Vegetation http://wiki.openstreetmap.org/wiki/Vegetation, Landcover http://wiki.openstreetmap.org/wiki/Landcover). We should think about how to organize content without collisions or at very least place all problematic categories under same Feature (semi-temporary, until we have better idea). definitely a good idea. However - *do not overhasten this* The last thing we can need is another halfbaken temporary compromise. Personally I suggest to use name environment - yes, it broader than anything (Landuse http://wiki.openstreetmap.org/wiki/Landuse, Vegetation http://wiki.openstreetmap.org/wiki/Vegetation, Landcover http://wiki.openstreetmap.org/wiki/Landcover). It is also not limited to Natural environment http://en.wikipedia.org/wiki/Natural_environment (then we cannot use Landuse/amenity) It is not limited to Physical environment http://en.wikipedia.org/wiki/Ecology#Physical_environments (we have semi/virual features like landuse/amenity because The problem is not only that forest can be mapped as either landuse,landcover or natural. We must also go away from the - there is either rock, vegetation or residential area model. Furthermore our vegetation model - there be either forest or gras is woefully inadequate. We need vegetation layers (ground, shrub level, under canopy, canopy, emergents). We need lots of fine tuning in geology as well. Instead we need the possibility to say * 70% landcover is sand (+ material where known) * 10% larger rocks (+ main rock type) - spatial extension of those areas may not be identical * ground level vegetation is gras, covering XX% area * shrub level is Ocotillo, with 100 plants per 100 sqm - again spatial extension of those areas may not be identical Combine that with residential and other areas.. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Objekte mit start_date/end_date
On Mon, Nov 10, 2014 at 10:34:39PM +0100, Friedrich Volkmann wrote: On 10.11.2014 19:13, Stephan Bösch-Plepelits wrote: Nun, ich stimme zu, dass es trivial ist. Das heisst aber noch nicht, dass es auch getan wird. Nur als Beispiel, openstreetmap-carto, der Standardstil der OpenStreetMap, berücksichtigt start_date und end_date nicht. Wir können ein Ticket erstellen. halte start_date/end_date für nicht ideal. Ein node/way kann mehrere tags haben, dann ist nicht klar worauf sich start_date/end_date beziehen sollen. Schon http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts gesehen? Mir gefällt eigentlich das tag:year-year Tagging ganz gut wobei ich year etwas allgemeiner mit Datum ersetzen würde. http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Related_concepts Richard ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] natural=valley (war: Namen von Objekten ohne Schild)
On Tue, Nov 04, 2014 at 02:04:11AM +0100, Friedrich Volkmann wrote: Im Deutschen ist es umgekehrt: Grat kennt jeder, Gratrücken ist Fachsprache. Was ist mit den rest-ridges, also den weniger scharfen bis sanften Bergrücken. Soll man da nur den Namen rendern? Den Bergrücken kann man wohl schwer rendern solange keine weiteren Informationen zur Form vorliegen. Genau. Von ridge nur den Namen rendern, arete hingegen als beidseitige Abbruchsignatur ggf. mit Namen. Und nebenbei erwähnt sollte auch von natural=cliff ggf. der Name angezeigt werden, was die gängigen Renderer derzeit leider nicht machen. Zusätzlich die Höhenlinien aus einem möglichst genauen Geländemodell (Laserscan) ermitteln und das Rendering ist perfekt. Eine leichte(!) Schummerung ist auch ok. ok, da sind wir uns weitgehend einig - ich habe das im wiki hervorgehoben und die tagging liste angeschrieben. Richard ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] natural=valley (war: Namen von Objekten ohne Schild)
On Mon, Nov 03, 2014 at 08:09:23AM +0100, Andreas Labres wrote: On 02.11.14 22:30, Holger Schöner wrote: Leider verwenden tatsächlich auch nach meiner Erfahrung nur sehr wenige die Tags natural=ridge und natural=valley ... natural=ridge ist mir schon mehrmals untergekommen, das liegt wohl nur am fehlenden Rendering, dass das selten verwendet wird. das wäre noch das geringere Problem. Es gibt es Spezialkarten für Outdoor (z.B. OpenAndroMaps) die sehr offen für solche Vorschläge sind und auch bei Mapnik wäre man im Prinzip wohl bereit das zu Rendern. ( https://github.com/gravitystorm/openstreetmap-carto/issues/1097 ) Allerdings sehe ich eine Reihe von Problemen die vorher angegangen werden sollten: * Definition schwamming - - was unterscheidet ridge und arete,, - was sind die Kriterien wann man eine ridge mappen soll (s.U.), wann rendern? - wie rendern wenn Definition so schwammig? * Höhenlinien/Reliefs aus frei verfügbarne DEM Daten sind meistens sehr gut brauchbar um einen guten Überblick übers Gelände zu bekommen - wann braucht man ridge? Bei arete wären die Probleme nicht so groß weil die Definition nicht so gravierend schwammig ist. Entweder man präzisiert die ridge definition nochmal oder mach nur noch arete, wobei man sich auch einigen könnte beide für synonym zu erklären. Aber natural=valley scheint mir nicht wirklich durchüberlegt. Sehr häufig fließt wohl in einem Tal ein Bach/Fluß, und was man eigentlich will, ist dem Bach/Fluß-Stück in diesem Tal einen weiteren Namen, nämlich den des Tals, geben; anstatt einen weiteren Way zu machen. Und das geht wegen der doppelten name-Verwendung dann nicht. das proposal im wiki sieht eigentlich eine Fläche vor, keine Variante ist besonders überzeugend .. wie wird das jetzt eigentlich gemappt? Richard ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Bettelampeln / Anforderungsampeln
On Fri, Oct 31, 2014 at 11:33:26AM +0100, DarkAngel wrote: Hi, gibt es eigentlich Tags für Bettelampeln d.h. Fuß/Radfahrer Ampeln die nur auf Anforderung grün werden? Die Dinger heißen Bedarfsampel und damit finden man sie auch unter http://wiki.openstreetmap.org/wiki/DE:Key:crossing Über den Rest kann man sich streiten, ich finde sie sinnvoller als bei Rot zu warten obwohl weit und breit kein anderer zu sehen ist. Würden mehr Ampeln nach Bedarf geschaltet würde der Verkehr auch flüssiger funktionieren. soso, die Autofahrer könnten auch mal einen Knopf drücken und warten, wie wäre das zur Abwechslung? Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Download source of all wikipages?
Hi, is it possible to download the complete source of all wiki pages from wiki.openstreetmap.org - preferably as highly compressed tarball? I am frequently finding that without a full regexp search it is very easy to miss important bits of information and related/similar tags so a copy at home where I could apply all of my unix tools for search would be very convenient. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Download source of all wikipages?
On Fri, Oct 24, 2014 at 11:54:38AM +0100, Grant Slater wrote: Hi Richard, https://dump.wiki.openstreetmap.org (currently offline) had daily exports of the wiki. I will try bring it back online in the next few days. ok, thanks for trying. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Howto tag a prominent dead tree?
On Wed, Oct 22, 2014 at 12:26:40AM +, Nicholas G Lawrence wrote: Subject: [OSM-talk] Howto tag a prominent dead tree? Hi, this must have come up before... any ideas? What does prominent mean? in this case local landmark visible on google sat (Bing is clouded in that place) and useful for navigation. Cultural or historical siginficance unknown although it is close to a house ruin of some significance. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Howto tag a prominent dead tree?
Hi, this must have come up before... any ideas? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Unbenutzbare Wanderwege - was tun?
On Thu, Sep 25, 2014 at 03:28:39PM +0200, Norbert Wenzel wrote: On 09/25/2014 01:03 PM, thsMD wrote: Noch eine Zusatzfrage: Welche Attribute verwendet man, wenn Radfahren auf dem Weg explizit nicht verboten ist (kein Schild), ich aber der Meinung bin, dass dort keiner mit seinem Rad langfahren möchte? Da ich von entsprechendem Gelände ausgeh würd ich mtb:scale[0] setzen. Praktisch unfahrbar bedeutet hier 6, wobei die Grenze für unfahrbar wirklich sehr hoch liegt. es gibt noch andere Gründe warum man einen Weg nicht Radfahren möchte, mtb:scale ist da eher ungeeignet: https://wiki.openstreetmap.org/wiki/Talk:Mountain_biking#How_to_map_ways_that_are_possible_but_really_no_fun_or_places_where_to_dismount_for_technical_.28not_legal_reasons.29.3F Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] regexp search over wiki pages?
On Sun, Sep 14, 2014 at 02:30:05PM +0200, Andreas Goss wrote: I am trying to search something like \w+:description in wikipages, is there some method or search engine to do that? Have you tried with google and site:http://wiki.openstreetmap.org/ ? yes, maybe I have forgotten something from the Google cheatsheet but it didn't work enough regexp-like for me. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] regexp search over wiki pages?
Hi, I am trying to search something like \w+:description in wikipages, is there some method or search engine to do that? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Own wikipage for every single speed limit??
On Thu, Aug 28, 2014 at 01:37:33PM +0200, 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). in the case of obsolete pages I found a way to workaround the problem, place an obsolete, use XXX instead into the tag description - which is then nicely displayed by taginfo in the listing of values. However that only works for tag descriptions that were valid at some point in time and can't be used for typo or other kinds of redirects. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] need advice for clever query or script
On Sat, Aug 30, 2014 at 02:09:34AM +0200, Imre Samu wrote: I have got one problem, some of the queries with most bridges do not load into JOSM. Josm says contacting the server and thats all. strange ... :( maybe timeout when generate JOSM data? my impression was that the problem was on the overpass website as it also generated a very strange shorturl for sharing. *#2. You can split the big query-s - to smaller ones ..* yes, thats what I was doing. Is actually nicer to edit in smaller batches and the problem is triggered only for the 3 or 4 most frequent contributors. *Other solution -Filter in JOSM* * JOSM File / Open location : http://www.overpass-api.de/api/xapi_meta?way[bridge=swing] * and after open the Filter menu ( Windows→Filter from the menu, or Alt+Shift+F from the keyboard) https://wiki.openstreetmap.org/wiki/JOSM/Search_function https://www.mapbox.com/blog/2012-08-15-using-filters-josm/ * and copy the query ( without the global keyword ( ..maybe... ) ) but I am not perfect in JOSM ... so if you find th correct JOSM filtering please share with me ... :) yes that also works, I actually use the Download from Overpass API with [timeout:600];way[bridge=swing];(._;;);out meta; and in JOSM use the plain search to select the subset that I want. bridge=swing and ( id:50483896 or id:51513287 or id:51831532 or id:52209220 or id:59430361 or id:88300946 or id:88863770 or id:99211716 ) Never looked at filters yet, it might be that they would hide the nodes? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Anforderungen des API verletzt - Fehler
On Sun, Aug 31, 2014 at 10:17:07PM +0200, Andreas Schmidt wrote: hallo Liste, ich bin gerade in Brasilien am mappen. Da komme ich in Gegenden, wo noch kein Mapper war und zeichne u.a. lange Stra0en und noch längere Flüsse. Jetzt habe ich erstmals eine Meldung von JOSM, von der ich nicht weiß, was ich falsch gemacht habe und wie man es richtig macht: [Anforderungen des API verletzt] 2.089 Punkte in Linie 285966444 überschreitet die maximal erlaubte Anzahl von 2.000 Punkten. http://abload.de/img/osm2000c4qgq.png Ich kann die aktuelle JOSM-Sitzung nicht hochladen. :-( den Weg mit P splittten - sofern Du weißt welcher Weg der Verursacher ist. Nochwas.. Deutsche Fehlermeldungen sind zwar schön aber Englische sind sehr viel praktischer weil man sie viel besser googeln kann. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] need advice for clever query or script
On Fri, Aug 29, 2014 at 02:22:10PM +0200, Imre Samu wrote:
Hi Imre,
thousands thanks - everything seems to work perfectly as described.
one question - if I would want to compile osmium myself the README says
that no files need to be build and doesn't say where osmium comes from?
Richard
clever query or script
maybe you can use OSM OPL format this ad-hoc query,
and process the data with sed, awk, grep .
my draft ubuntu script - with comments.
https://gist.github.com/ImreSamu/be49fd1ce511975325d2#file-bridge_swing-sh
result ( Overpass-Wizard Query - but you can export the data to JOSM )
https://gist.github.com/ImreSamu/a2dd0a8c25f0fea5284c#file-bridge_swing_overpass_wizard-md
the example result - Overpass-Wizard Query :
type:way and ( id:28134411 or id:29295367 or id:30178341 or id:30178382 or
id:33132931 or id:33132936 or id:33132949 ) global
( http://wiki.openstreetmap.org/wiki/Overpass_turbo/Wizard - see
Meta-Data Filters )
*How to check the query *
** go http://overpass-turbo.eu/ http://overpass-turbo.eu/ *
** select Wizard*
* * copy /paste the generated query : type:way and ( id:27001207 or
id:72584563 ) global*
* * Build and run query - and check the result.*
* * if you got timeout error, then check the generated script timeout (
osm-script output=json timeout=25 ) and set to 200 - and rerun *
** you can load data into an OSM editor: JOSM, - see Export menu *
From the OSM OPL history - very easy to grep the first contributor
# convert the osm history file to OPL ( *osmium cat w11323607.osh -f opl* )
# sample OSM History OPL file:
# w100646626 v1 dV c7343540 t2011-02-20T15:08:57Z i37137
uDerick%0020Rethans Tbridge=yes,highway=footway
Nn309461645,n1163494643
# w100646626 v2 dV c12447614 t2012-07-23T09:52:38Z i404175 urickogden
Tbridge=swing,highway=footway Nn309461645,n1163494643
# w100646626 v3 dV c18538313 t2013-10-25T16:16:57Z i24119 uMauls
Tbridge=swing,highway=footway Nn309461645,n2508499967
# w100646626 v4 dV c25024407 t2014-08-26T10:51:45Z i66391 ugeozeisig
Tbridge=movable,bridge:movable=swing,highway=footway
Nn309461645,n2508499967
# w100646626 v5 dV c25050883 t2014-08-27T12:42:02Z i66391 ugeozeisig
Tbridge=swing,highway=footway Nn309461645,n2508499967
#
# filter the results by the first contributor who added bridge=swing to the
way
# ( *egrep -m 1 '( T|,)bridge=swing'* )
#result: v2
# w100646626 v2 dV c12447614 t2012-07-23T09:52:38Z i404175 urickogden
Tbridge=swing,highway=footway Nn309461645,n1163494643
#
The OPL format - from the OSMIUM manual:
v - Version
d - Deleted flag ('V' - visible or 'D' - deleted)
c - Changeset ID
t - Timestamp (ISO Format)
i - User ID
u - Username
T - Tags
x - Longitude (nodes only)
y - Latitude (nodes only)
N - Nodes (ways only)
M - Members (relations only)
you can find other interesting examples in the OSMIUM manual
Find all users who have created post boxes:
egrep ' v1 ' data.osm.opl | egrep 'amenity=post_box' | cut -d' ' -f7 |
cut -c2- | sort -u
OSMIUM tool - and more examples :
http://osmcode.org/libosmium/manual/libosmium-manual.html#output-formats
https://www.sotm-eu.org/en/slots/36
https://www.sotm-eu.org/slides/44.pdf
Imre
2014-08-28 12:39 GMT+02:00 Richard Z. ricoz@gmail.com:
Hi,
trying to clean up bridge=swing as far as possible. There was at least
user in the past who used the combination systematically wrong, so I want
to split the result by user who introduced the bridge=swing.
To make things complicated - a few days ago one contributor did a well
meant effort to convert all
bridge=swing - bridge=movable+bridge:movable=swing
and reverted that edit because there were too many errors in it. Hence
doing a naive search for user doesn't work.
So I want to :
* find all bridge=swing
* split results by the first contributor who added bridge=swing
to the way
* get the results into JOSM for examination and editing
Tia for any hints,
Richard
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] JOSM connection problems downloading/uploading data?
Hi, having frequent problems today, sometimes everything works and sometimes when downloading/uploading data JOSM says Failed to upload data to or download data from 'https://api.openstreetmap.org/api/' due to a problem with transferring data. Details (untranslated): java.lang.RuntimeException: Could not generate DH keypair The network connection seems fine, background imagery is laoded fine - is anyone else seeing this?? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM connection problems downloading/uploading data?
On Fri, Aug 29, 2014 at 03:08:31PM +0100, Tom Hughes wrote: On 29/08/14 15:01, Richard Z. wrote: having frequent problems today, sometimes everything works and sometimes when downloading/uploading data JOSM says Failed to upload data to or download data from 'https://api.openstreetmap.org/api/' due to a problem with transferring data. Details (untranslated): java.lang.RuntimeException: Could not generate DH keypair Thank you - that explains a lot. You're the first person to provide the actual error details and it explains why the temporary fix I managed to come up with accidentally has solved the problem. still the same problem here though. Additionally, when launching JOSM it says JOSM tried to access the following resources: https://api.openstreetmap.org/api/capabilities but failed to do so, because of the following network errors: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive) It may be due to a missing proxy configuration. Would you like to change your proxy settings now? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM connection problems downloading/uploading data?
On Fri, Aug 29, 2014 at 03:25:02PM +0100, Tom Hughes wrote: On 29/08/14 15:20, Jean-Marc Liotier wrote: On 29/08/2014 16:14, Tom Hughes wrote: On 29/08/14 15:08, Tom Hughes wrote: On 29/08/14 15:01, Richard Z. wrote: Failed to upload data to or download data from 'https://api.openstreetmap.org/api/' due to a problem with transferring data. Details (untranslated): java.lang.RuntimeException: Could not generate DH keypair It looks like you are hitting this: http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh Which fits with us upgrading the servers today. So is there a client-side workaround or should we just wait for an api.openstreetmap.org fix ? Well the FAQ isn't very helpful, but it seems that there is no client side fix (other than upgrading to Java 7 or later). the FAQ actually says Java 7 and earlier limit their support for DH prime sizes to a maximum of 1024 bits ..not sure if there is any Java version at all that would do it and work together with JOSM. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] need advice for clever query or script
On Fri, Aug 29, 2014 at 04:12:08PM +0200, Imre Samu wrote: if I would want to compile osmium myself the README says that no files need to be build and doesn't say where osmium comes from? I have used the code and instructions from this 2 repo https://github.com/osmcode/libosmium ( osmium library ) https://github.com/osmcode/osmium-tool ( osmium command line tool ) ok, the https://github.com/osmcode/osmium-tool was the missing link. if you have a some problems with the installation, then I can create a Docker Container ( www.docker.com ) for you. hopefully not necessary.. I do not need it quickly and if I will do it will try to create all the RPM specfiles. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM connection problems downloading/uploading data?
On Fri, Aug 29, 2014 at 04:39:27PM +0200, Jean-Marc Liotier wrote: On 29/08/2014 16:32, Richard Z. wrote: On Fri, Aug 29, 2014 at 03:25:02PM +0100, Tom Hughes wrote: On 29/08/14 15:20, Jean-Marc Liotier wrote: On 29/08/2014 16:14, Tom Hughes wrote: On 29/08/14 15:08, Tom Hughes wrote: On 29/08/14 15:01, Richard Z. wrote: Failed to upload data to or download data from 'https://api.openstreetmap.org/api/' due to a problem with transferring data. Details (untranslated): java.lang.RuntimeException: Could not generate DH keypair it seems that there is no client side fix (other than upgrading to Java 7 or later). Ok - upgrading to Java 7 fixed the problem for me, thanks ! Well - it is not like JOSM had not been warning me for ages that staying with Java 6 was going to cause problems... I have neither Java 6 nor 7 but java-1.7.0-openjdk. Latest JOSM is happy with it so I assumed it is pretty much Java 7 but maybe there are differences between various Java 7 versions and only some of them support the longer keys - which would explain the discrepancies between the FAQ and what various people are seeing. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] need advice for clever query or script
On Fri, Aug 29, 2014 at 02:22:10PM +0200, Imre Samu wrote: Hi Imre, I have got one problem, some of the queries with most bridges do not load into JOSM. Josm says contacting the server and thats all. When I share the query the shorturl looks like the one bellow so it seems to be somehow an issue at http://overpass-turbo.eu/ ?
[OSM-talk] Own wikipage for every single speed limit??
Hi, noticed that there is https://wiki.openstreetmap.org/w/index.php?title=Tag:maxspeed%3D20redirect=no and a few more speeds - does it make any sense to have such pages around? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] need advice for clever query or script
Hi, trying to clean up bridge=swing as far as possible. There was at least user in the past who used the combination systematically wrong, so I want to split the result by user who introduced the bridge=swing. To make things complicated - a few days ago one contributor did a well meant effort to convert all bridge=swing - bridge=movable+bridge:movable=swing and reverted that edit because there were too many errors in it. Hence doing a naive search for user doesn't work. So I want to : * find all bridge=swing * split results by the first contributor who added bridge=swing to the way * get the results into JOSM for examination and editing Tia for any hints, Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Brücken
On Wed, Aug 27, 2014 at 03:04:37PM +0200, Robert Kaiser wrote: Friedrich Volkmann schrieb: Kann sein, dass die Liste auch Zeilen enthält, wo es sich um keine richtigen Brücken handelt, aber die komischen Namen müssen nicht unbedingt falsch sein... Ich finde trotzdem nicht, dass sie wirklich als Namen im Sinne des name= Tags zu sehen sind. Aber das ganze bringt sowieso wieder die OSM-Problematik hoch, dass Brücken keine separaten Objekte sind und daher kein separates name-Tag haben. IMHO ist es schlichtweg falsch, den namen der Straße für das Brückenstück auf den Brückennamen zu ändern, da die Straße trotzdem den Straßennamen hat, nur zusätzlich über die Brücke mit dem Brückennamen führt. Dadurch, dass die Brücken aber keine eigenen Objekte sind, haben wir keinen wirklich geeigenten Platz, wo wir den Brückennamen hinschreiben können (und auch keine ordentlichen Bündelung von mehreren Wegen/Objekten, die auf/an einer Brücke sind). es gibt das bridge:name proposal, wird soweit ich sehe häufig verwendet. Auch man_made=bridge ist dafür geeignet. Richard ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] New mapping satellite
On Thu, Aug 14, 2014 at 03:14:32PM -0700, Kevin Bullock wrote: 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. just looking at the Seychelles, anything in the tube here? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] Tagging natural or informal swimming holes?
On Fri, Apr 25, 2014 at 02:07:15PM +0100, Philip Barnes wrote: On Thu, 2014-04-24 at 23:03 -0700, Bryce Nesbitt wrote: How best should I tag informal swimming areas? These typically have no lifeguard or facilities. An example deep-content site for these types of holes is: http://www.iforgotthename.com/ In OSM is it best to create an area and tag sport=swimming/name=/access=/fee=no? http://wiki.openstreetmap.org/wiki/Tag:sport%3Dswimming Forgetting the tagging for a moment, is it not irresponsible to be mapping and thus being seen as encouraging such activities? Every year when there is hot weather there are warnings not to swim in lakes and rivers, and these are inevitably followed by reports in the media of a tragic loss of life. The last thing OSM needs is to be seen as contributing to such tragedies. a good map can prevent some tragedies by mapping hazards and places which are better suited than others. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Baum der Woche: Kastanie
On Tue, Apr 15, 2014 at 09:54:19AM +0200, Falk Zscheile wrote: Am 15. April 2014 09:37 schrieb tumsi tu...@gmx.de: zu taggen. Vielleicht gibt es dann im Herbst eine Kastaniensammelkarte? Sollten wir nicht auch die Bärlauchfelder im Wald mappen, damit man auch in unbekannteren Gegenden schnell mal ein paar Blätter für die Küche sammeln kann? :-) Oh, das ist ein extrem schwieriges Thema. Möglicherweise brauchen wir dann neben dem surface-Tag auch noch ein vegetation-Tag, dass dann auch noch nach Bewuchshöhe differenzieren muss. ich habe da schon einige Ideen und werde mich dran machen wenn ich mal Zeit habe. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Baum der Woche: Kastanie
On Sun, Apr 13, 2014 at 12:49:17PM +0200, Ralf GESELLENSETTER wrote: Der milde März hat dazu geführt, dass bereits jetzt viele Kastanienbäume ihre fünffingrigen Blätterfächer entfalten und sogar ihre ersten Blütenkerzen entfachen... Auf diese Weise sollte es auch botanischen Laien leicht fallen, hie und da einige natural=tree species=Aesculus␣hippocastanum species:de=Rosskastanie zu taggen. Vielleicht gibt es dann im Herbst eine Kastaniensammelkarte? Vielleicht kommt jemand in Carisolo vorbei und kann und die Bäume und Amenities im Castagnetto mappen? Ich bin im Moment weit weg. http://www.openstreetmap.org/relation/3583513 Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Azimuth measurement
On Tue, Apr 08, 2014 at 02:44:46PM +0100, SomeoneElse wrote: Martin Koppenhoefer wrote: on iPhones you can change this in settings (geographic vs magnetic north) not sure for other devices but my guess is there will be settings as well... Unless you're in northern Canada I really wouldn't worry about the difference between geographic and magnetic north. Just for a laugh I've looked at the compass results from a couple of phones (an iPhone and a Blackberry Q10) and an actual compass (piece of metal on a stick in a box - remember them?). Obviously indoors it's really not a fair test, but if I point the phones north (which the actual compass gets correct) the phones read 268 and 210 rather than 0. you can easily calibrate the compass of smartphones in every location. It does help quite a little bit. Some apps also have some kind of correction for geographic vs magnetic north. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Imagery Offset Database turns 1
On Mon, Mar 31, 2014 at 07:23:23PM +0400, Ilya Zverev wrote: Hi! On this day a year ago I announced the Imagery Offset Database. Since then mappers have uploaded around 6 thousand offsets, and the number of editors supporting the database has doubled. I hope we are still teaching beginner mappers to properly align imagery layers, and I've prepared some statistics about the database: http://www.openstreetmap.org/user/Zverik/diary/21491 congrats. It is one of the possibilities which should be more widely known and used. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maximum recommended length of ways tagged with layer
On Fri, Mar 21, 2014 at 05:05:21PM -0500, Paul Johnson wrote: On Mar 21, 2014 4:59 PM, Richard Z. ricoz@gmail.com wrote: Example of a problem this should catch: I have seen cases where someone wanted to tag a simple bridge with layer and added the layer to the wrong segment - tagging a hundred or more miles of road accidentally, possibly affecting crossings far away for an area not downloaded. The validator will not detect it and in most cases the renderer will work around this bug very well so it is only discovered by accident in most cases. This is not limited to layer, I have seen the same problem with culverts and bridges. This seems like something a validator should be able to catch without overly complicating how levels work. I am not trying to complicate how layers work right now but trying to codify how they already work in 99% of cases in easy to follow rules that could be utilised by validators. Yes, the validator should be able to catch such situations. Just how? It doesn't right now. I see some possible approaches: * warn user if tagging excessively long ways with layer. Here the problem is to judge what is excessively long. * warn user if applying layer to a way that exceeds the size of downloaded area because in this situation the validator is unable to do even the basic checks. * warn user if applying layer to a way without tunnel/bridge/covered/indoor or similar tags. There is more than just JOSM and all should follow the same rules so ideally this rules would be nicely documented in the wiki. What kind of underground areas are that in Kansas, do you have a pointer? I'm not exactly sure where exactly it is, but there's apparently a pretty extensive underground industrial and office district entirely underground complete with drivable underground streets in KCK thanks to repurposing an old mine. interesting, I will have a look when I have some time. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maximum recommended length of ways tagged with layer
On Sat, Mar 22, 2014 at 03:33:03PM +0100, colliar wrote: On 22.03.2014 11:01, Richard Z. wrote: On Fri, Mar 21, 2014 at 05:05:21PM -0500, Paul Johnson wrote: On Mar 21, 2014 4:59 PM, Richard Z. ricoz@gmail.com wrote: Example of a problem this should catch: I have seen cases where someone wanted to tag a simple bridge with layer and added the layer to the wrong segment - tagging a hundred or more miles of road accidentally, possibly affecting crossings far away for an area not downloaded. The validator will not detect it and in most cases the renderer will work around this bug very well so it is only discovered by accident in most cases. This is not limited to layer, I have seen the same problem with culverts and bridges. This seems like something a validator should be able to catch without overly complicating how levels work. I am not trying to complicate how layers work right now but trying to codify how they already work in 99% of cases in easy to follow rules that could be utilised by validators. Yes, the validator should be able to catch such situations. Just how? It doesn't right now. I see some possible approaches: * warn user if tagging excessively long ways with layer. Here the problem is to judge what is excessively long. As judgement is difficult and it will still depend on other cases, I do not think this will help that much it is not my preferred approach either, but it might still catch some cases which might otherwise be hard to catch. For example I think it is reasonable to assume that if someone tags 200 miles of a road with layer=1 it is an accident and the rate of false positives would be very low. Could this limit be much lower without generating many false positives? For layers 2,3,4,5 it appears reasonable to assume higher limits because these are more likely to be used for longer bridges etc. * warn user if applying layer to a way that exceeds the size of downloaded area because in this situation the validator is unable to do even the basic checks. even though this will lead to false warnings when working with incomplete data, I would give this solution a try. yes, incomplete data is another problem.. fortunately people downloading partial data through overpass usually know what they are doing pretty well. * warn user if applying layer to a way without tunnel/bridge/covered/indoor or similar tags. Covered is an example where it does not work e.g. you tag the building=roof with layer and not the way underneath. in this case there is nothing to solve. However covered=yes can be used with and without layer depending on situation, so the validator should allow that. For JOSM I have the following search string to find suspicious way/layer combinations: (highway | railway=rail |waterway) -layer=0 layer=* -tunnel=* -bridge=* -culvert=yes -*=steps -*=elevator -covered=yes -indoor=yes Surely the validator could do a better job than a simple search string but I am not sure about false positives. If you look at this area http://www.openstreetmap.org/#map=18/41.88435/-87.62125 there are quite a few matches and I have no idea if all of those could be tagged somehow better? What kind of underground areas are that in Kansas, do you have a pointer? I'm not exactly sure where exactly it is, but there's apparently a pretty extensive underground industrial and office district entirely underground complete with drivable underground streets in KCK thanks to repurposing an old mine. interesting, I will have a look when I have some time. Could you post a link, please. I wonder how mapnik will work with that as there are already problems with a single underground floor/parking. Found it meanwhile.. https://en.wikipedia.org/wiki/SubTropolis https://maps.google.com/maps?ll=39.161213,-94.476242q=loc:39.161213,-94.476242hl=ent=mz=15 https://www.openstreetmap.org/?mlat=39.161213mlon=-94.476242zoom=15#map=14/39.1543/-94.4756 looks like nothing is mapped yet? Mapping it will be tricky with a handheld GPS or Bing - maybe there is some PD data available? I believe that as it is essentially an underground building it should be mapped using level instead of layer. Same for most parking lots and many similar examples. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
On Fri, Mar 21, 2014 at 07:17:26AM +0100, Stefan Keller wrote: Hi Richard, hi Simon At 2014-03-14 16:19 GMT+01:00 Simon Poole wrote At 14.03.2014 16:06, schrieb Richard Z.: is there really no way to avoid those horrible captchas whenever I add a link to a JOSM bug ticket or another friendly website to the wiki?? ... What I saw on Tuesday seem to indicate that ReMAPTCHA (Stefan?) is nearly here. As the name says it is map related. Unluckily it is still a pain to use if you have problems with your eyesight, but at least you are not working for google at the same time. Yes, that's right, we are working hard to release a map related ReCaptcha, I called ReMAPTCHA. I will present it at GI_Forum Symposium in Salzburg in July 1-4 2014. I really hope to have a beta release ready next week! thanks. Even though I have no problems with my eyes I still find it frequently difficult to recognise the distorted letters and have to reload a few times. A working and maintained whitelist would be really good in addition to any captcha improvememnts... Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maximum recommended length of ways tagged with layer
On Fri, Mar 21, 2014 at 03:41:45PM -0500, Paul Johnson wrote: This seems like a solution looking for a problem than anything actually pragmatic and worth doing. It would also needlessly overcomplicate cities that have large areas underground on multiple levels, such as Kansas City. Example of a problem this should catch: I have seen cases where someone wanted to tag a simple bridge with layer and added the layer to the wrong segment - tagging a hundred or more miles of road accidentally, possibly affecting crossings far away for an area not downloaded. The validator will not detect it and in most cases the renderer will work around this bug very well so it is only discovered by accident in most cases. This is not limited to layer, I have seen the same problem with culverts and bridges. What kind of underground areas are that in Kansas, do you have a pointer? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] 3D: Wie Gebäude am Hang taggen?
On Mon, Mar 17, 2014 at 04:19:06PM +0100, Martin Koppenhoefer wrote: Am 17. März 2014 13:44 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Gibt es denn wenigstens einen Renderer, der bereits irgendwelche Geländedaten mit einbezieht? bei den bisher frei verfügbaren Quellen wie SRTM und Aster gibt es jedenfalls sicher keine Hoffnung, dass damit solche Details wie ein halb eingegrabenes Gebäude wiedergegeben werden könnten (Zu geringe Auflösung). Es gibt aber durchaus Renderer, die diese Quellen miteinbeziehen, aber das hilft eher bei der Orientierung im großmaßstäblicheren Einsatz, nicht bei der Ansicht des einzelnen Gebäudes. sollte man da vielleicht mit ele=* nachhelfen? Aber was genau würde man mit ele taggen? Eingänge? Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Maximum recommended length of ways tagged with layer
On Sat, Mar 15, 2014 at 06:12:10PM +, moltonel 3x Combo wrote: On 15/03/2014, Fernando Trebien fernando.treb...@gmail.com wrote: I now agree that the layer tag should be used as locally as possible, so I think Richard had good intentions when proposing this. At the same time, I think you, Frederik, has a good point that arriving at a threshold for that number is quite hard. What exactly do we want to avoid? Really, really long ways with a layer tag. So why not set this threshold higher? Say 10 km? Validator rules are a good thing, but I think that length of a way that has layer=* to detect misuse of the layer tag is beside the point. Whatever threshold you use, there'll false-positives and false-negatives. How about something along the lines of negative layer but no tunnel tag (or positive/bridge) and no/too many crossing ways ? I am now thinking about unless absolutely necessary the size of objects tagged with a layer tag should not exceed a size which would be typically downloaded for editing in this area. but the wiki page already says * Tag shortest possible/practical sections of ways. Long viaducts and tunnels can be tagged with a suitable single value for their entire length for simplicity although it may sometimes be better to adjust the layer along its length to accommodate more complicated crossings. * Use the smallest suitable layer value. Only use layer=2 for a bridge that passes over a feature that is already at level 1; similarly only use layer=-2 for a tunnel that passes below another tunnel. For convenience some higher values are often locally used/reserved for very long bridges or underground networks where it is assumed that they are above/bellow most other crossings/objects in the area. - which should be good enough if people don't interpret the text in some unforseen way. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maximum recommended length of ways tagged with layer
On Sat, Mar 15, 2014 at 05:12:08PM +0100, Frederik Ramm wrote: Hi, On 15.03.2014 14:44, Richard Z. wrote: I think it would be good to agree on something... https://wiki.openstreetmap.org/wiki/Talk:Key:layer#Maximum_recommended_segment_length_of_ways_tagged_with_layer I think that choosing some fixed number would be un-OSM. Your idea that length limits should apply to certain layers but not others strikes me as odd. odd - and reflecting current usage patterns as far as I can judge from analysing current data. Even odd rules can be quite useful. Thinking more about it, perhaps location=* would be a good alternative for tagging very long bridges and tunnels? Thinking of bridges spanning whole valleys with towns bellow them and similar. Working out every crossing that may happen to be bellow the long bridge and how it relates to the underground railway network down there is impractical. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Maximum recommended length of ways tagged with layer
Hi, I think it would be good to agree on something... https://wiki.openstreetmap.org/wiki/Talk:Key:layer#Maximum_recommended_segment_length_of_ways_tagged_with_layer Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Hate captchas!!!!
Hi, is there really no way to avoid those horrible captchas whenever I add a link to a JOSM bug ticket or another friendly website to the wiki?? There are at least 2 tickets open which could help a lot: *https://trac.openstreetmap.org/ticket/5116 *https://trac.openstreetmap.org/ticket/3898 I need on average 4 captcha-reloads before I get a captcha picture which I can recognise with good enough confidence to even try it. How about an OSM quiz instead of captchas? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
On Fri, Mar 14, 2014 at 03:43:38PM +, Tom Hughes wrote: On 14/03/14 15:06, Richard Z. wrote: How about an OSM quiz instead of captchas? You're offering to write one I take it? will think about one. In the short term, there are open tickets which should make it a lot easier Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
On Fri, Mar 14, 2014 at 07:12:13PM +0100, Tobias Knerr wrote: On 14.03.2014 17:15, Tom Hughes wrote: I think most of those are already whitelisted aren't they? Unless I'm mistaken, these are the currently whitelisted URLs: http://wiki.openstreetmap.org/wiki/MediaWiki:Captcha-addurl-whitelist great, hope that will work. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
On Fri, Mar 14, 2014 at 11:23:18AM +0100, Andreas Neumann wrote: Am 14.03.2014 08:56, schrieb Andreas Schmidt: [...] Die Herren Hobbyschlachter [...] Ich verbitte mir eine solche Ausdrucksweise in öffentlichen Diskussionen. Man mag zur Jagd stehen wie man will, aber man sollte auch Menschen, deren Hobby man ablehnt, mit Respekt begegnen. Du willst ja auch, dass uns Mappern Respekt entgegen gebracht wird. wir sind die Hobbymapper und stolz darauf! Wenn andere Probleme mit ihrem Image haben ist das nicht unser Problem. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Key:layer update
On Wed, Mar 12, 2014 at 09:06:41PM -0400, Russ Nelson wrote: Pieren writes: On Wed, Mar 12, 2014 at 3:22 PM, Frank Little frank...@xs4all.nl wrote: Richard Z wrote As mapped, the waterway=stream (Way #138911739) runs underground (layer=-1), probably through a culvert given the way the stream left and right are separately outlined as waterway=riverbank (and without layer=*). The way (stream) should be tagged as a culvert. Perhaps there is in reality a bridge not a culvert, in which case the road needs splitting and the appropriate new road segment tagged as bridge=yes. In either case, a layer tag is not needed for rendering. +1 Nonetheless I add one out of habit. But I would be happy to stop, because as noted, the bridge or culvert carries an implicit layering. With a new type of bridge we could do it. The current state is that if there is no layer tag the bridge has a layer=0 which is not what you want. The old definition can't be changed because it would affect many existing crossings. The implicit layering that you mention is a technical workaround that software does to avoid problems with OSM data. Those are not necessarily bugs in OSM data but very often it is missing information - someone was not sure is there a bridge/culvert or perhaps a ford. Rendering and other software needs to make a guess in such cases. Although it might be more correct to paint a question mark there most renderers assume a culvert and implicit layering in such cases. It isn't good to rely on that for technical reasons, many alternative renderers are much less fault tolerant than Mapnik and you will get strange results. Also the validators need to improve their error checking to catch accidental errors and this is nearly impossible until people agree on how to use layer (and level and other similar tags). Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
On Thu, Mar 13, 2014 at 12:51:22PM +0100, Falk Zscheile wrote: Worauf die betreffende Person aber vermutlich hinaus will: Radikale Tierschützer nutzen die Daten unter Umständen, um die jagdlichen Einrichtungen zu beschädigen. Die Beschädigung ist eine Straftat (§ 303 StGB). Für einem Mapper aber durch Erfassung der Daten eine Beihilfe (§ 27 StGB) zur Sachbeschädigung zu konstruieren, halte ich für sehr weit hergeholt. wäre mir nicht so sicher mit den Tierschützern - mindestens genauso oft kommt es wohl vor, daß da Konkurenz am Werk war. Nun ist so ein Hochsitz in der Regel eine Art lnadmark, wenn man die löscht oder zerstört kann die Orientierung erschwert sein. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
On Thu, Mar 13, 2014 at 01:32:40PM +0100, Falk Zscheile wrote: Am 13. März 2014 13:20 schrieb Richard Z. ricoz@gmail.com: On Thu, Mar 13, 2014 at 12:51:22PM +0100, Falk Zscheile wrote: Worauf die betreffende Person aber vermutlich hinaus will: Radikale Tierschützer nutzen die Daten unter Umständen, um die jagdlichen Einrichtungen zu beschädigen. Die Beschädigung ist eine Straftat (§ 303 StGB). Für einem Mapper aber durch Erfassung der Daten eine Beihilfe (§ 27 StGB) zur Sachbeschädigung zu konstruieren, halte ich für sehr weit hergeholt. wäre mir nicht so sicher mit den Tierschützern - mindestens genauso oft kommt es wohl vor, daß da Konkurenz am Werk war. Die meisten Wilderer haben einen Jagdschein, aber dass sich Jäger die Hochsitze gegenseitig zersägen, davon habe ich noch nichts gehört. ich habe auch nichts spezifisches über Hochsitze gehört dafür aber ganz andere Geschichten, da wäre ein angesägter Hochsitz ein Kavaliersdelikt dagegen. Nun ist so ein Hochsitz in der Regel eine Art lnadmark, wenn man die löscht oder zerstört kann die Orientierung erschwert sein. Sicher, aber wenns dem lieben Frieden dient kann man zumindest einmal darüber nachdenken, ob man dem Jäger einen gefallen tun möchte. Die könnten mal an ihrem Image werkeln. Es scheint solche zu geben die gerne mal Kletterhaken u.Ä. beschädigen.. bin nicht übertrieben geneigt so jemanden einen Gefallen zu tun. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Key:layer update
On Tue, Mar 11, 2014 at 02:51:23PM +, Dave F. wrote: On 09/03/2014 12:21, Richard Z. wrote: In practice this rule is broken more often than you would think: Hamburg is full of waterways connected with roads on bridges through a tag obstacle. France is full of bridges sharing a node with the waterway bellow. Could you link to an example please? http://www.openstreetmap.org/node/1522876252 stupid question - suppose I have this node selected in JOSM - what is the quickest way of getting an URL like the above? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 10:26:59PM +, Matthijs Melissen wrote: On 9 March 2014 10:30, Richard Z. ricoz@gmail.com wrote: for some time now I have been working on the wiki page to state the rules as clearly as possible.. hope that most of the improvements are fairly uncontroversial. Thank you for doing this, it's very useful to have this properly documented. I have been working on layering in the main CartoCSS stylesheet, and found that at the moment, indeed not all aspects of the layering model are defined precise enough. just remembered, there is also a rather special rule for tunnel=building_passage The layer has to be the same as the building, with the above mentioned exception when several tunnels are passing on different levels. https://wiki.openstreetmap.org/wiki/Key:tunnel#tunnel.3Dbuilding_passage It makes sense but is so much different from normal tunnels that I am wondering if it should not have been done with a different tag. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] isolated odbl=clean nodes with no other tags?
Hi, this caught my attention some time ago: http://www.openstreetmap.org/node/307673868 we could not figure out how it happened and what it was originaly. It seems none of the validators complains about the existence of such nodes so this may be an isolated mishap or a widespread problem. Has anyone looked at this before? Are those odbl=clean tags supposed to stay there forever? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Tue, Mar 11, 2014 at 02:52:02PM +, Dave F. wrote: On 09/03/2014 14:45, Martin Koppenhoefer wrote: +1, but adding a layer=1 to a lake in a park isn't clearer or more accurate, they are both on the same layer, the lake is in the park, not above (usually). Which confirms my point perfectly. You're are correct: The lake park /are/ at the same level, which is why the layer tag is needed. It's used purely to let the renderer know which entity to put on top of the pile show it display properly. if a layer tag is needed to display a lake in a park then you have some other problem. Show us an example. natural=water + layer has no meaning unless in combination with tunnel, bridge or similar. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] isolated odbl=clean nodes with no other tags?
On Tue, Mar 11, 2014 at 06:32:01PM -0500, Toby Murray wrote: It was probably a member of a way that got removed. Maybe they forgot to add the odbl tag to the way. that was our idea but the OSM Inspector or some other tool would have warned about that case.. so a little mystery. I am not worried about this one case but how it slipped through all checks and how many other there might be. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] layer and pylons
Hi, I did think a bit more about the situation and think it makes no sense to try to rescure the meaning of layer for ways at different levels connected with pylons or similar constructions. For simple cases such as pylons of aerial tramways it is defined so, that the tramway is above ground and thus a vertical ordering is defined. Similar situation with dams. For more general cases like 2 bridges at different levels connected through a pylon either level could be used or something more sophisticated like a relation. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Key:layer update
Hi, for some time now I have been working on the wiki page to state the rules as clearly as possible.. hope that most of the improvements are fairly uncontroversial. Some of the changes: * the vertical ordering established by the layer values is valid exactly only in the point where the ways cross or objects overlap * define layer as higher value means above, lower value means bellow. Avoid the complicated layer=0 definition as the natural ground level as it would be shown by contour lines on a topographic map. Explicit layer=0 seems to be deprecated now. * layer on ways should be used only in combination with one of tunnel=*, bridge=*, highway=steps, highway=elevator, covered=* or indoor=yes. For areas, it could be used in combination with tags such as man_made=bridge, building=* and similar. The motivation for this is to make it easy for validators to spot errors such as when the wrong segment is accidentaly tagged, bridge/tunnel forgotten, or someone tags excessively long ways for no good reason - common problem with waterways and elevated roads/railroads. I have validated this rule for ways in large parts of the world, there are exceptions which currently I do not know hot to tag better but those are rare. * in some cases level may be more appropriate than layer https://wiki.openstreetmap.org/w/index.php?title=Key%3Alayerdiff=999107oldid=935491 Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Use of Key:* as wiki web page titles
On Sun, Mar 09, 2014 at 11:11:35AM +, Dave F. wrote:
Hi
Prompted by the discussion on the Layer tag I've just noticed
there's two separate pages for it: 'Layer' 'Key:Layer'
What's the reason for the 'Key:' prefix? IMO it can only lead to
confusion. Haven't checked all, but Landuse Natural each have
separate entries in the wiki.
Key:* is the documetation of a specific key, linked to for example
by {{key|layer}}, other names are just names someone invented.
Sometimes it is useful to have a page like waterway with an overview
of related pages.. but may be still confusing at the same time.
Richard
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 11:47:32AM +0100, Martin Koppenhoefer wrote: Am 09/mar/2014 um 11:30 schrieb Richard Z. ricoz@gmail.com: * the vertical ordering established by the layer values is valid exactly only in the point where the ways cross or objects overlap actually at the Point where a layer Way Connects to an layer=0 way both are at the same height (e.g. where a bridge starts) currently the assumption that everything meeting in a node is physically at the same elevation in this point is not valid in OSM. It is broken by definition in at least one case: waterways ar supposed to share a node with the dam they are crossing, which means the highway passing across the dam will also share a node with the river passing thorugh a tunnel or pipeline bellow it. Some objects (such as dam, buildings) have the property to define their own physical level relations. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 01:05:18PM +0100, Martin Koppenhoefer wrote: Am 09/mar/2014 um 12:43 schrieb Richard Z. ricoz@gmail.com: It is broken by definition in at least one case: waterways ar supposed to share a node with the dam they are crossing, which means the highway passing across the dam will also share a node with the river passing thorugh a tunnel or pipeline bellow it. -1, it is a modeling problem/error, the highway should not have a common node with the waterway, if it has, it is wrong or should be tagged ford=yes ;-) the same conceptual problem exists with pylons where they are shared by two bridges or aerial tramways. Actualy every pylon breaks the rule by definition because it connects ground with layer=0 with something else at a different level. How do you want to model such cases better? Lifts in buildings? In practice this rule is broken more often than you would think: Hamburg is full of waterways connected with roads on bridges through a tag obstacle. France is full of bridges sharing a node with the waterway bellow. It may be worth to tag have such a rule restricted for ways of the same type and a short well defined list of exceptions. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 11:35:20AM +, Dave F. wrote: On 09/03/2014 10:30, Richard Z. wrote: Hi, for some time now I have been working on the wiki page to state the rules as clearly as possible.. hope that most of the improvements are fairly uncontroversial. Some of the changes: * the vertical ordering established by the layer values is valid exactly only in the point where the ways cross or objects overlap If you take that literally users will join rivers flowing under a bridge with a node add the layer tag to it, which is incorrect: those ways should not join. it says point, not node the difference probably needs to be emphasized very strongly. There is a difference between mathematicaly precise and intuitive formulations:(( Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 11:35:20AM +, Dave F. wrote: On 09/03/2014 10:30, Richard Z. wrote: Hi, for some time now I have been working on the wiki page to state the rules as clearly as possible.. hope that most of the improvements are fairly uncontroversial. Some of the changes: * the vertical ordering established by the layer values is valid exactly only in the point where the ways cross or objects overlap If you take that literally users will join rivers flowing under a bridge with a node add the layer tag to it, which is incorrect: those ways should not join. changed the intro text to say The layer=* tag is used to mark vertical relationships between crossing or overlapping features. The vertical ordering established by the layer values is valid exactly only in the point (not node!!!) where the ways cross or objects overlap. Joining the ways with a common node at the point where they cross would destroy the vertical order established by layer. The layer=* is not suitable to define vertical relationships of adjoining or nearby elements or areas. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 12:34:31PM +, Dave F. wrote: On 09/03/2014 12:24, Richard Z. wrote: it says point, not node the difference probably needs to be emphasized very strongly. There is a difference between mathematicaly precise and intuitive formulations:(( https://www.google.co.uk/#q=node%20definition a point in a network or diagram at which lines or pathways intersect or branch in OSM this is called node. Better suggestions instead of point? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 12:34:31PM +, Dave F. wrote: On 09/03/2014 12:24, Richard Z. wrote: it says point, not node the difference probably needs to be emphasized very strongly. There is a difference between mathematicaly precise and intuitive formulations:(( https://www.google.co.uk/#q=node%20definition a point in a network or diagram at which lines or pathways intersect or branch changed to precise location instead of point.. is that better? Also listed teh pylon as exception. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 02:00:36PM +0100, Tobias Knerr wrote: On 09.03.2014 13:21, Richard Z. wrote: the same conceptual problem exists with pylons where they are shared by two bridges or aerial tramways. Actualy every pylon breaks the rule by definition because it connects ground with layer=0 with something else at a different level. How do you want to model such cases better? Lifts in buildings? Typical pylons aren't a problem because the ground is not an OSM element that they could share a node with. Pylons shared between more than one bridge are indeed an interesting problem for 3D mapping, but I'm not aware that this is commonly mapped or used by applications yet, so there is still some room for establishing good standard practice. Lifts in buildings don't use layer, they use level. That tag follows different rules than layer. I would be in favor of using level more widely but the rules are not so much different because you can also have all kinds of highways and railways on levels. In practice this rule is broken more often than you would think: Hamburg is full of waterways connected with roads on bridges through a tag obstacle. France is full of bridges sharing a node with the waterway bellow. I would prefer correcting these errors instead of changing the rule they break. are those really errors? Pylons must share a node with the waterway bellow in my opinion. They are a pretty relevant part of it. It may be worth to tag have such a rule restricted for ways of the same type and a short well defined list of exceptions. The rule is also needed for ways of different types, e.g. for ordering a stack of road, railway, and waterway bridges. then there is the alternative of having a list of exceptions. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 04:55:51PM +0100, Tobias Knerr wrote: On 09.03.2014 14:18, Richard Z. wrote: Pylons must share a node with the waterway bellow in my opinion. They are a pretty relevant part of it. Pylons will often be somewhere within the riverbank area - based on their exact positions in reality -, but I would not insert them into the waterway way. somehow they ought to be connected to the river though, just beeing in the area is not enough. As they are relevant for navigation there can be situations where inserting them into the waterway way would be indeed the most logical solution. What do you do if one pylon is left of the center of the waterway and one is right of it? interesting question.. I will look again at the examples and ask the author. then there is the alternative of having a list of exceptions. That's more reasonable, but exceptions should only be made where it is really necessary. I haven't encountered such an example yet. Having seen a few examples of vertical lifts I am sure there will be more exceptions. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:layer update
On Sun, Mar 09, 2014 at 10:26:59PM +, Matthijs Melissen wrote: On 9 March 2014 10:30, Richard Z. ricoz@gmail.com wrote: for some time now I have been working on the wiki page to state the rules as clearly as possible.. hope that most of the improvements are fairly uncontroversial. Thank you for doing this, it's very useful to have this properly documented. I have been working on layering in the main CartoCSS stylesheet, and found that at the moment, indeed not all aspects of the layering model are defined precise enough. A question: a single road can contain sections on multiple layers, so there will be a point where the sections that are on different layers meet. At that point, there might even be a side street. However, no vertical ordering should be assumed at such a point. It is written that The vertical ordering established by the layer values is valid exactly only in the point where the ways cross or objects overlap. Perhaps 'crossing' should be interpreted here as crossing without node, but that causes problems with bridge/waterway. it should be indeed crossing without a shared node, have already updated the text to clarify that. In other words, I am wondering for each of the following situations if the roads should be interpreted as meeting on the same or different levels: - A node where two waterways on layer 1 and two roads on layer 2 meet; the roads should join at the same physical level in this node. Except the node is a pylon connecting two bridges on two levels and a waterway or a similarly weird exception which is not described in the wiki but happens in real life and probably somewhere in OSM data as well. Generally, if the node does not have a special type (lift, pylon, part of buildings with level) the roads should join as expected. Nothing is certain about the waterway unless the node is of type ford or pylon, or the layering is otherwise obvious such as when the road is on a dam or weir. Exceptions and errors in data are currently very common where waterways and roads have shared nodes. Once I have mapped a weir with a highway ford on top it and part of the water going through a pipe through the weir. Conceptually I am thinking of it so that certain constructions such as a dam establish a connection in the sense that both the road and the river are passing over/through it and hence are connected to the dam without really meeting in this point - the dam establishes its own layering rules. - A node where two roads on layer 1 and two roads on layer 2 meet; - A node where two roads on layer 1 and one road on layer 2 meet; - A node where one road on layer 1 and one road on layer 2 meet. they should all join without steps and exceptions should be extremely rare.(maybe lifts and such) More precisely layer does not say anything in this situation so the default rule applies - roads are expected to join without steps. It is important to understand that the meaning of layer is very limited: - it applies exactly only in the point (without shared node) of the crossing and has absolutely no meaning anywhere else - it has absolutely no defined meaning if not in combination with one of bridge, tunnel and the other tags listed in the wiki (I may have forgotten some but you get an idea) - a number of other tags (covered, location, level, dam and probably some other) define own layering concepts or modify layer in strange ways Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] No Changeset Comments from iD
On Wed, Mar 05, 2014 at 10:53:09PM -0800, Clifford Snow wrote: Why do I see so many new mappers make edits without a commit comment? Is it because iD doesn't prompt for a commit message? iD issue 1488 is open but not acted upon. I wonder why. Is it because the developers don't think commit comments are needed? another problem that makes the history (from the map page) almost useless is that about 2/3 of all changesets indicate a very large change area box. Seems like most wheelmap.org edits change the whole planet at once. Somehow the locality of changesets should be encouraged as well. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] new mailing list request - OSM outdoor/natural phenomena mapping
Hi, after all the discussion, the list has been created and I need a break from discussions about new tags:) ### Outdoor sports, wilderness and natural features mapping. Everything from scuba diving to paragliding, from undersea volcanoes to Mount Everest, related software and talk. Main language is English, all languages are welcome. ### Richard ___ 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 Thu, Mar 06, 2014 at 10:54:35AM +0100, Martin Koppenhoefer wrote: In the case of climatic zones and vegetation zones you could overlay / mash the osm data with an external dataset. Nobody will draw a map of climatic zones in a 1:500 scale, it doesn't make sense, but it is a scale where OSM does operate. It can make sense to draw them at high zoom levels. If I am hiking in dense fog, rain in a swamp around Mt. Waialeale I have a serious interest to know that a radically different climatic zone is 400 meters away. The borders of the zones may be as sharp as sharp ridge. Does it make sense to have this data in OSM database? I do not know the answer, depends on several aspects: * is the data stable? - *YES* * how good is the data that we could get? - remains to be seen * are there technical difficulties representing it in OSM? - no idea * is it useful to have? - *YES* Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] new mailing list request - OSM outdoor/natural phenomena mapping
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. Also a mailing list for outdoor enthusiasts and outdoor sports does not seem to exist. So for the beginning I would propose just one ml to cover those topics and maybe split it up later when there is demand to do so. I have emailed mich...@osmfoundation.org (https://wiki.openstreetmap.org/wiki/Mailing_list#Requests_for_New_Lists) but so far not got any response. Richard ___ 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 Wed, Mar 05, 2014 at 12:44:39PM +, SomeoneElse wrote: 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. Also a mailing list for outdoor enthusiasts and outdoor sports does not seem to exist. The tagging mailing list was created because the volume of esoteric tag discussion got too much for the main talk list. Maybe you need to create lots of geology or outdoor sports discussion first :) the issue is that modeling geology, vegetation and similar aspects needs considerable special knowledge. We might be lucky but we can not expect that too many people with such special knowledge will listen on tagging or talk. Among outdoor oriented people it should be easier to find such specialised knowledge. As an example, we are having repeated discussions how to tag forrest but did not even start thinking about a generic concept how to map vegetation such as: climatic zones vegetation zones soil biology vegetation layers http://www.tpwd.state.tx.us/publications/pwdpubs/media/pwd_lf_k0700_0167e.pdf http://www.srl.caltech.edu/personnel/krubal/rainforest/Edit560s6/www/whlayers.html Without a similar framework our vegetation mapping will remain a patchwork. Another example.. we are currently discussing hot springs but I do not have enough knowledge in balneology or hydrogeology to be confident about defining water characteristics. Richard ___ 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 Wed, Mar 05, 2014 at 01:59:33PM +, Jonathan Bennett wrote: On 05/03/2014 13:42, Richard Z. wrote: climatic zones vegetation zones soil biology vegetation layers Are any of these things verifiable? of course. Tons of literature about it. Are they relatively static or do they change with the weather/season/year-to-year? Most of them are stable over centuries untill someone comes with a chainsaw. Do not ask me too many details, I know enough that I would consider somesuch framework as one of the better ways to map vegetation but not enough to make the proposal. Richard ___ 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 Wed, Mar 05, 2014 at 01:52:50PM +, Dave F. wrote: IMO that should be amalgamated back into the general lists. Occasionally tagging procedures get changed after brief discussions between very small select groups metaphorically huddled together in the corner of a room, that turn out to be non beneficial to OSM. It's a similar reason why I believe IRC isn't helpful. More often people change the wiki any way they like because they don't find a suitable forum to ask. Even more often people just invent tags without any documentation or discussion. I have read plenty of the other lists talking about how complicated it is to map pedestrian ways, memorial stones and Austrian street addresses. Meanwhile we don't have a way to tag lava fields, lava flows, hot springs, waterway=dam is a mess, I have just barely fixed waterfalls. The world is just too complicated for one list and for someone mapping the antarctic geology bus route mapping is not so interesting. Richard ___ 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 Wed, Mar 05, 2014 at 04:59:17PM +0100, Christoph Hormann wrote: 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 oh yes. You can say the same about a forrest and almost anything in the real world. When does a forrest have dense enough trees to be called a forrest and how tall should a tree be to be called a tree instead of bush? Is an Iowa tall grass prairie a kind of grasland? Despite your opinion some areas are known as deserts while others are known as lakes, rivers, grasland and forrest. And of course there are well known and widely accepted climatic zones characterisations such as http://en.wikipedia.org/wiki/K%C3%B6ppen_climate_classification Richard ___ 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 Wed, Mar 05, 2014 at 04:04:10PM +0100, Martin Koppenhoefer wrote: 2014-03-05 14:42 GMT+01:00 Richard Z. ricoz@gmail.com: As an example, we are having repeated discussions how to tag forrest but did not even start thinking about a generic concept how to map vegetation such as: climatic zones vegetation zones soil biology vegetation layers most of these do not seem remotely suitable for the osm data model and the way we collect and store data. Climatic zones and vegetation zones are very big areas with fuzzy boundaries. We do not even manage to map huge areas with clear boundaries (e.g. look for the atlantic ocean in osm), how could we start to map those with fuzzy boundaries? the zones may not be as huge as you would imagine. In some cases the zones are just square miles or much smaller with very sharp boundaries as seen on Mauna Kea, Haleakala, or some places on Kauai. http://upload.wikimedia.org/wikipedia/commons/b/bb/Koppen_World_Map_%28retouched_version%29.png And if we have problems with the Atlantic Ocean we should fix them:) These also might be subject to generalization and interpretation to a degree that 2 scientists in the same field would draw the borders differently. this could happen, the bigger problem I see is that in every country they would apply the same rules slightly differently. But we have similar problems in most other domains and still try to map them. Just recall the discussion of highway=track classification. IMHO these could maybe produced out of osm data (together with other data like precipitation, temperature etc.) interesting idea. You would also need a very good elevation model and prevailing winds, soil properties and maybe some other details of course. However I believe that a climatic zone is an empirical data set and trying to derive it from other information is like trying a 4 weeks weather forecast. It may work in some areas but the result will be worse than using observed data. Another point is, the climatic zones may be useful to predict vegetation characterstics for large areas of the world where detailed vegetation mapping is not available yet. if you'd analyzed the occurence of certain species (the tags for mapping single plants are there, you only have to use them, currently these are the numbers: 319 553 *species* http://taginfo.openstreetmap.org/keys/species 125 867 *species*:de http://taginfo.openstreetmap.org/keys/species%3Ade 81 881 *species*:it http://taginfo.openstreetmap.org/keys/species%3Ait 131 887* taxon* http://taginfo.openstreetmap.org/keys/taxon I think that really underscores the need for a mailing list for such subjects because I had never the idea that this tags exist. Tags regarding soil biology are also very hard to verify on the ground by the general mapper. They require specialized knowledge and maybe also a laboratory to do analysis and similar. frequently people searching mushrooms will have very good knowledge of this subject. I don't hope to get a perfect map of soil biology anytime soon but having a framework for it prepared should not hurt. Even if collecting the data wasn't an issue (say it would be possibile to import perfect data), still it won't integrate or fit well with the datamodel (this is more statistical data than actual hard facts, and drawing the border is almost impossible). I find it always hard to decide where to draw borders of forrests because they are fuzzy and unfortunately many lakes and rivers have shores which are changing very quickly over time which is an even bigger problem. Your last point, vegetation layers, might be a little bit different. IMHO this could be done, and partly it already is (see the landcover-key) yes, landcover is a step in the right direction but IMHO nowhere close to a satisfactory mapping of vegetation and ground properties. Mapping for example the Sonoran desert would require yet another approach, it is essential to specify the properties of the partially exposed ground as well as the vegetation. Richard ___ 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 Wed, Mar 05, 2014 at 07:16:36AM -0500, Serge Wroclawski wrote: How is this different from other tagging discussions? tagging discussion is only the last step. Before it can happen we need to have a pretty good model of what we want to map and then decide how it could be mapped. Most of us have a pretty good working model of a road and a house in our head which make it easy to skip the modeling phase and go to tagging discussion. Apparently this is not so easy with vegetation, geology and other natural phenomena which require considerable special knowledge to select a suitable data model. Even in the relatively familiar case of vegetation our model to map it is highly unsatisfactory becuase it went to tagging discussion before researching a suitable model. Our model of geology is limitted to mapping single_stones, bare_rocks and cliffs. Would it be possible to do this better? I have no idea, it is something that should be discussed but is not a tagging discussion. Simple things like mapping corral reefs are still not available. Would it be possible to map the Gulf stream or other currents? Richard ___ 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 Wed, Mar 05, 2014 at 08:44:54PM +0100, Christoph Hormann wrote: 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. despite beeing sometimes tricky I still consider it pretty important to know that a certain area is eg part of the tundra climate, permafrost or monsoon. And when hiking on Kauai I would pretty sure want to have this information handy: http://www.fs.fed.us/psw/topics/ecosystem_processes/tropical/restoration/lifezone/hawaii/Kauai.jpg http://3.bp.blogspot.com/-D7UQYrsMu24/UVuvQS7In1I/Pp4/TNzHyYeWlZw/s1600/kauai-smaller-map.gif - everything from rain forrest to desert within few miles. Richard ___ 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 Wed, Mar 05, 2014 at 08:41:06PM +, Jonathan Bennett wrote: On 05/03/2014 20:30, Richard Z. wrote: despite beeing sometimes tricky I still consider it pretty important to know that a certain area is eg part of the tundra climate, permafrost or monsoon. ...and as I said, five messages ago: The main OSM database only stores relatively permanent features. That's not to say that this information isn't useful and valuable, just that the main OSM database isn't the right place to store it. what exactly is not relatively permanent about a permafrost region? The permafrost has been there since the last ice age and maybe longer, the very name says it. Is the OSM database the right place to store bus routes that change twice a year or whenever there is an accident blocking the particular road? Opening hours of the shop next door which may change every day? All of that is in progress. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
