[OSM-talk-be] Mapcenter 2
Hello everyone. I use a GPS 60CSX. In seeking a map to my gps, I found the website http://mapcenter2.cgpsmapper.com/ It provides a cartographic database for free use and conversion. Could we use this data to enrich Osm? Thank you for your advice and light. J-L ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Mapcenter 2
The licence is more restrictive than the OSM use: Any Map covered by the License may be used for any personal or educational purposes without limitations, including decompilation, modification, conversion and recompilation. Any professional use (including but not limited to commercial, governmental or military use) may require separate agreement with Authors if not stated otherwise. So in most cases you will have to 'ask the author' and then you can ask at once if their map is not 'build' on OSM data Quite some of the maps on that site - at first sight - seem to be OSM data processed for GPS-use. Luc aka Speedy On Fri, Mar 5, 2010 at 3:28 PM, JL Stanus ramms...@msn.com wrote: Hello everyone. I use a GPS 60CSX. In seeking a map to my gps, I found the website http://mapcenter2.cgpsmapper.com/ It provides a cartographic database for free use and conversion. Could we use this data to enrich Osm? Thank you for your advice and light. J-L ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] [OSM-talk] OSM 3 GeoNames = GeoNames 3 OSM =)
On Sat, 6 Mar 2010, elf Pavlik wrote: Hello Everyone! I just asked on GeoNames mailing list why they don't use OSM for their map functionality. http://groups.google.com/group/geonames/t/ec02877f850cf6c7 A person named Marc responded that OSM share-alike license is too restrictive. Please check link above for his explanation. Could someone explain me how relation between GeoNames and OSM looks at this moment? According to the OSM wiki you use GeoNames for your search functionality. I think it would be nice if GeoNames and other services could use OSM for their mapping functionality. I think GeoNames and OSM have complementary service to each other and I would really like to see them in good relation =) Peace! elf Pavlik ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk forwarding to legal-talk i read the forum page, and some of their concepts are quite wrong about OSM ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [OSM-talk] OSM 3 GeoNames = GeoNames 3 OSM =)
On 05/03/10 20:16, Liz wrote: On Sat, 6 Mar 2010, elf Pavlik wrote: Hello Everyone! I just asked on GeoNames mailing list why they don't use OSM for their map functionality. http://groups.google.com/group/geonames/t/ec02877f850cf6c7 A person named Marc responded that OSM share-alike license is too restrictive. Please check link above for his explanation. I think that past discussion indicates that the OSM community in general regard interface-layer-over-OSM-date-style-mash-ups as a reasonable use of OSM data. I don't think this is right (from the point of view of copyright or from the point of view of user freedom) but you'll find plenty of support for this position on the mailing lists. Point extraction *shouldn't* create a derivative in a sane universe. So IMO OSM shouldn't claim points generated using OSM data as a derivative. But I forget the current state of play in that debate. 8-/ - Rob. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] coastline within a park
On 5 March 2010 20:35, simon msr...@gmail.com wrote: In this case your park have to follow the coastline with the tham node (I have correct it to show you) unfortunately the water is part of the park If it was a park with water in the midle you have to use multipolygone relation http://wiki.openstreetmap.org/wiki/Multipolygon right, will do ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
On 5 March 2010 20:40, Apollinaris Schoell ascho...@gmail.com wrote: Don't use coastline but tag the basin with natural water or any other water type tags like riverbank … hmm, well if we can ignore for a moment the abomination of inconsistency that is water tagging in general and natural=water specifically, then no: the basin is tidal, so it's coastline coastline is also sensitive to direction while water has to be a closed polygon only, direction doesn't matter yes ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
On 5 March 2010 20:39, John Smith deltafoxtrot...@gmail.com wrote: On 5 March 2010 17:17, Robin Paulson robin.paul...@gmail.com wrote: i've recently mapped a park which contains a basin. when the tiles render, the whole area, including the water, renders green. how would i tag this so the renderer understands the water bit should be treated as water, and rendered blue? The tiles just needed to be marked dirty so they regenerated, try viewing it now. they'd already rendered, but now someone else has drawn it incorrectly. i'll revert, use a polygon relation, and re-render ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Offline Dump of the Wiki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thanks a lot. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuQ5JIACgkQalWTFLzqsCsHdQCgszezvwZTZKtgp31KIg2tes7n 2tQAoIwL9ykYTPgB3+/aAcjwKq+Y3Gu5 =vAcn -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] wikipedia: towns/cities pages include a osm-direct-link
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please tell me if I am wrong !? As we are working together with wikipedia, it would be nice to include direct-links to osm or even a small part of the map to the city/town pages. I think this would be a good promotion towards osm. I am not much into editing wikipedia but I just wanted to get the ball rolling. cheers colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuQ5r0ACgkQalWTFLzqsCsXtACbB5LjJTUT9P5MM27p4OCKrLlk rKAAn0UZ71WbXdt2nAXN9DGt13oDqW4m =RmF5 -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] wikipedia: towns/cities pages include a osm-direct-link
On Fri, Mar 5, 2010 at 11:10 AM, colliar colliar4e...@aol.com wrote: Please tell me if I am wrong !? As we are working together with wikipedia, it would be nice to include direct-links to osm or even a small part of the map to the city/town pages. I think this would be a good promotion towards osm. I am not much into editing wikipedia but I just wanted to get the ball rolling. There's an existing project within the Wikimedia foundation to integrate OpenStreetMap maps into wikipedia (and presumably other Wikimedia projects). They have hardware already, and are in the process of setting up development machines (toolservers in Wikimedia term) and looking at getting map servers into the Wikimedia production clusters. They have a mailing list for discussions, and if it's something you're interested in then I'd suggest joining them there. https://lists.wikimedia.org/mailman/listinfo/maps-l Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Re : wikipedia: towns/cities pages include a osm-direct-link
Hi Colliar, A link is already there. If the co-ordinates of a place are given in the top right this leads to direct links to every map under the sun, and a few others too by the look of it. OpenStreetMap is already in the list, with its copyright, and a further list of osm developer projects. Adrian. BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please tell me if I am wrong !? As we are working together with wikipedia, it would be nice to include direct-links to osm or even a small part of the map to the city/town pages. I think this would be a good promotion towards osm. I am not much into editing wikipedia but I just wanted to get the ball rolling. cheers colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuQ5r0ACgkQalWTFLzqsCsXtACbB5LjJTUT9P5MM27p4OCKrLlk rKAAn0UZ71WbXdt2nAXN9DGt13oDqW4m =RmF5 -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
2010/3/5 Robin Paulson robin.paul...@gmail.com: they'd already rendered, but now someone else has drawn it incorrectly. i'll revert, use a polygon relation, and re-render haven't you stated above that the water is part of the park? The multipolygon-relation will exclude the inner from the outer, so IMHO this is not your desired solution... cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Still interest in an Android POI collector?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Liz wrote: On Wed, 24 Feb 2010, Patrick Weber wrote: I tried Navit on Android yesterday, at least on my phone (HTC Magic) it was unusable, the map didnt update properly or follow my movements, and crashed a few times. I also could not find out how to actually set a route I've just been playing with Navit the last couple of days, and it's the only Android OSM app I've seen so far that I would recommend to other people. The user interface needs some work, but once I got it to work on my G1, it is worth it. On the Freerunner I run Navit, but I changed the xml file to use the menu style gtk. Using the internal display every time you touch the screen because the backlight has gone off something happens on the program so strange things happen when you least want them to. I wake the screen using the menu key, but you're right, it needs to disable the screen sleeping. It can choose and navigate a route of about 200km but past that distance I have troubles even with a netbook processor. It probably needs to use A-star rather than a simple Dijkstra's algorithm. I think that Navit is the right approach to mapping - it doesn't use map tiles, it renders vectors on demand. It does routing etc. and doesn't need an internet connection. There's a few quick improvements that could be made: * Menu layout needs work - I need a button that says Navigate to or Go to on the first page, that leads to a search. I can't find an option to delete bookmarks, etc. Also, the menus need to be more android native in feel, rather than strange custom menus. * Direction instructions need a bit of tweaking e.g. it says: Turn left into a four thousand one hundred and forty four where it should say: Turn left into the A four one four four * Searching needs work (it relies on a strict hierarchy defined by is_in tags doesn't do postcodes) - it could have an option to fall back to the internet nominatim for searching as this is only a tiny amount of bandwidth would be a quick win. * Speed sensitive auto-zoom would be nice * The 3d view has a wierd perspective that doesn't really work - it probably needs to be landscape-only, and tilted much further. POI, track, and photo collection would be useful additional features, along with something to highlight in the directions where there is a FIXME or OSMbug entry nearby on the map. I think that integrating these features into Navit (perhaps as plugins), rather than having a separate app would be of much greater benefit. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRATMACgkQz+aYVHdncI3fbwCdGw445froUSzneYQFK/nxm2RZ lOgAoOSkSYPk0zXRBV0DkT5gaPihCMq7 =yFr+ -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] coastline within a park
I have a related question, which I've let sit for several months hoping to find an answer for. There is a park here http://www.openstreetmap.org/?lat=27.8394lon=-82.5924zoom=14layers=B000FTF that includes wetland islands, wetland mainland, and dry mainland. Initially I could not get any of it to render as park. Somehow I eventually dumbed into something that renders the wetland islands as park, but it required deleting the islands and retracing them--not sure why. Anyway, I don't want to have to retrace the mainland wetland coastline to do this, and I also need to connect that with the dry mainland section. The entire wetland mainland area in the view is part of the park, and I know from visits to the area where the northern boundaries for the dry areas are. Can someone advise how to do this? I've stayed away from doing any further work on the local coastline until I figure this out. Ed Hillsman Date: Fri, 5 Mar 2010 13:41:57 +0100 From: Martin Koppenhoefer dieterdre...@gmail.com Subject: Re: [OSM-talk] coastline within a park To: Robin Paulson robin.paul...@gmail.com Cc: OSM Talk talk@openstreetmap.org Message-ID: 7acdb3651003050441y1a38e833nffead252ca2a4...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 2010/3/5 Robin Paulson robin.paul...@gmail.com: they'd already rendered, but now someone else has drawn it incorrectly. i'll revert, use a polygon relation, and re-render haven't you stated above that the water is part of the park? The multipolygon-relation will exclude the inner from the outer, so IMHO this is not your desired solution... cheers, Martin -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk End of talk Digest, Vol 67, Issue 16 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Announce: Gosmore Earth
I'm pleased to announce Gosmore Earth after more than a year of silence. Gosmore is a viewer of OSM-XML with routing and searching capabilities. Ports include Linux, Windows, Windows-Mobile and Maemo. It uses it's own binary file format that is optimized for small devices. New features include: * 3D view * Better presentation of search results * Better rendering * Better lowzoom * Multipolygon support * Automatic switching of map files and in-program downloads of maps. Extracts covering the complete planet are now provided on a weekly basis. * Better display of turn-by-turn instructions * Native Windows port (much faster) with an easy to use installer. * Quickly launch osm.org, gmaps or Potlatch from within the application. Under Linux you can also open another application (e.g. firefox or thunderbird), highlight text containing gps coordinates and then switch to Gosmore to plot those locations on the map. * Some routing tweaks, like tracktype and turning across traffic at busy junctions. Still not perfect. So services like yournavigation should not yet upgrade their engines, but rather consider this as experimental. A complete description and installation instructions can be found here: http://wiki.openstreetmap.org/index.php/Gosmore Outstanding issue are listed here: http://wiki.openstreetmap.org/index.php/Talk:Gosmore Development has stalled, but when these issues are resolved (hopefully during 2010), the next version (1.0) will be announced. Special thanks goes to David Dean for a lot of testing and a few bug fixes. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-cl] Nuevo capa / new layer
Danilo, Yo estoy usando Thuban en Ubuntu para ver los archivos Shapefile. Hay otros archivos, en este momento no recuerdo en que formato, para los cuales aun no he buscado una alternativa. Si encuentras algo para esos otros archivos, por favor avisame. Saludos, Julio Costa On Fri, Mar 5, 2010 at 10:16 AM, Danilo Lacoste dan...@lacosox.org wrote: hola denuevo, alguien conoce alguna herramienta opensource que me permita leer estos archivos ? On Fri, Mar 5, 2010 at 4:38 AM, Jean-Guilhem Cailton j...@arkemie.com wrote: Danilo, Están acá : http://maps.geography.uc.edu/~cgn/maps/Chile/vectors/http://maps.geography.uc.edu/%7Ecgn/maps/Chile/vectors/ (mas detalles en el wiki http://wiki.openstreetmap.org/wiki/2010_Chile_earthquake/Imagery_and_data_sources#Willett-Nicholas_data_sets que necesitaría mostrar nuevos conjuntos de datos). Saludos, Jean-Guilhem Danilo Lacoste a écrit : ¿como puedo acceder / descargar esta información? On Mon, Mar 1, 2010 at 5:15 PM, Bruce Willett bdwil...@ravel.n2.net wrote: Hello, I just uploaded 2 more datasets Region 9 and the comuna of Nueva Imperial in zipped geodatabase. caio, bruce .:*~*:._.:*~*:._.:*~*:._.:*~*:..:*~*:._.:*~*:._.: Bruce D. Willett GIS Specialist Punta Arenas, Chile bdwil...@n2.net www.n2.net/bdwillet Photo log: http://www.flickr.com/photos/bdwillet/ The greatness of a nation and its moral progress can be judged by the way its animals are treated. La Civilización de un pueblo se mide por la forma que tratan a los animales. Gandhi Disclaimer: Opinions stated herein are mine, mine, mine, all mine and not those of anybody else .:*~*:._.:*~*:._.:*~*:._.:*~*:..:*~*:._.:*~*:._.: ___ Talk-cl mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cl -- www.lacosox.org ___ Talk-cl mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - (amenity=ice_cream)
Main page here: [1] Already discussed one year ago, we didn't come to a standardization of the tag used to describe shops selling ice creams = proliferation of different tags today [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Ice_cream signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
Hillsman, Edward hills...@cutr.usf.edu writes: I have a related question, which I've let sit for several months hoping to find an answer for. There is a park here http://www.openstreetmap.org/?lat=27.8394lon=-82.5924zoom=14layers=B000FTF that includes wetland islands, wetland mainland, and dry mainland. Initially I could not get any of it to render as park. Somehow I eventually dumbed into something that renders the wetland islands as park, but it required deleting the islands and retracing them--not sure why. Anyway, I don't want to have to retrace the mainland wetland coastline to do this, and I also need to connect that with the dry mainland section. The entire wetland mainland area in the view is part of the park, and I know from visits to the area where the northern boundaries for the dry areas are. Can someone advise how to do this? I've stayed away from doing any further work on the local coastline until I figure this out. coastline and park should be entirely separate conceptually. Tag it how it is, and if it doesn't render how you think it should look into the rendering rules. Contorting the tagging to make the current rendering incarnation work right seems like not a good plan. I suspect the rendering folks would be interested in a fix; I can easily see this being a case not envisioned and not handled. pgpl39gQi0EFD.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
On a related issue, since a way that forms a closed loop is interpreted as the boundary of an area rather than as a way, how does one map a road or trail that forms a closed loop? --Original Message-- From: Robin Paulson Sender: talk-boun...@openstreetmap.org To: OpenStreetMap talk mailing list Subject: [OSM-talk] coastline within a park Sent: Mar 5, 2010 1:17 AM i'm after some advice. i know this is potentially tagging for the renderer, but still i've recently mapped a park which contains a basin. when the tiles render, the whole area, including the water, renders green. how would i tag this so the renderer understands the water bit should be treated as water, and rendered blue? cheers http://www.openstreetmap.org/?lat=-36.90445lon=174.85045zoom=16layers=B000FTF ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Announce: Gosmore Earth
I'm pleased to announce Gosmore Earth after more than a year of silence. Gosmore is a viewer of OSM-XML with routing and searching capabilities. Ports include Linux, Windows, Windows-Mobile and Maemo. It uses it's own binary file format that is optimized for small devices. Looks sweet on my PC... must download the 'old xRoad' to finally get accurate maps of my home town. You are a star!! Simon. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM 3 GeoNames = GeoNames 3 OSM =)
On 5 March 2010 16:28, elf Pavlik perpetual-trip...@wwelves.org wrote: Hello Everyone! I just asked on GeoNames mailing list why they don't use OSM for their map functionality. http://groups.google.com/group/geonames/t/ec02877f850cf6c7 A person named Marc responded that OSM share-alike license is too restrictive. Please check link above for his explanation. Could someone explain me how relation between GeoNames and OSM looks at this moment? According to the OSM wiki you use GeoNames for your search functionality. I think it would be nice if GeoNames and other services could use OSM for their mapping functionality. I think GeoNames and OSM have complementary service to each other and I would really like to see them in good relation =) I don't think so. Geonames and OSM are very different. Geonames is storing only points most of which are actually coming from the Geonames database: http://geonames.nga.mil/ggmaviewer/MainFrameSet.asp It means that potentially most of Geonames data is also available to us. Having points is not terribly useful in many cases. In addition, Geonames has been considered unsafe for imports: http://wiki.openstreetmap.org/wiki/Geonames since it is not clear where the source data was freely available or not in the first place, making less than useful in OSM where you make sure that we can use data. Emilie Laffray ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
John F. Eldredge wrote: On a related issue, since a way that forms a closed loop is interpreted as the boundary of an area rather than as a way, how does one map a road or trail that forms a closed loop? It depends on the context. A closed loop tagged with a highway tag is just a closed highway. Roundabouts are often simple closed loops, but render as a ring not an area. There are exceptions of course (it wouldn't be OSM without them :-)) If you want to draw a piazza draw the closed outline with highway=pedestrian which would normally render as a closed loop, but if you add area=yes the whole space is rendered as a filled piazza. Cheers, Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile caching (osm startpage)
Hi Bernhard, all, Very interesting proposal. I think people in a position to do so should give attentive consideration to your situation, facing Internet infrastructure limitations in a developing country. (Beside your personal situation and dedication which would certainly deserve a veteran's medal for OSM cause if such a thing existed - or does it exist yet ?). I imagine that the largest number of potential users of OSM in the world must be facing similar technical conditions (based on population numbers). So your forced rest time in Phnom Penh could be an opportunity for OSM to tune its offer for this majority of mankind. Crisis situations could also benefit from progress in this area. For example, I was in contact via irc last night with someone in Concepción, Chile, who only had a very weak intermittent wifi connection to a remote hot spot (and could not move because of curfew). This could be an opportunity for osm start page and basic services (MapOSMatic, Walking Papers, OpenStreetBugs, etc...) to improve themselves if possible, for people who, on average, might not have an understanding of technical problems as insightful as yours. Kind regards, Jean-Guilhem Bernhard zwischenbrugger a écrit : Hi all I'm sitting in Phom Penh and have very slow internet. The tiles come in very very slow. I'm working on a new javascript map... full story: http://www.mail-archive.com/d...@openstreetmap.org/msg10669.html The internet is too slow here for developing, so I had to install a local image proxy. Now it's fast as hell. It's faster than at home. If a tile is changed I will see the old version for a long time. But it's fast and usable. HTTP HEAD Google Cache Time: Cache-Control: public, max-age= //feels like one month (I didn't calculate) OSM Cache Time: eTag (no cache) - Story In many countrys (like cambodia) the ping is very long. It can be easily some seconds. osm.org is slow slow slow. It takes long time until all the tile for the osm startpage are loaded. But then the problem starts. Every move I make on the map is s slow. Even if I was looking at the same spot on the map a couple of days ago. For visitors of osm.org a good caching is important. For editors of osm.org it's important to have the newest version of the tiles. For visitors (not logged in) there could be a diffent caching than for editors (logged in). Caching is important if you sit somewhere in a developig country with slow internet connection. Implementation Tileserver visiter cache.openstreetmap.org Tileserver editor tiles.openstreetmap.org The Servers should deliver headers for long and short caching time. The map for logged in users should load images from tiles.openstreetmap.org. (extensible rules...) Never mind, I was just thinking about that and want to distribute it. Wish you a nice day Bernhard --OSM: HEAD http://a.andy.sandbox.cloudmade.com/tiles/cycle/17/37480/50153.png 200 OK Cache-Control: max-age=440434 Connection: close Date: Fri, 05 Mar 2010 14:37:11 GMT ETag: d096ddafba32c0da609007e224530ccd Server: Apache/2.2.8 (Ubuntu) Content-Length: 45409 Content-Type: image/png Expires: Wed, 10 Mar 2010 16:57:46 GMT Client-Date: Fri, 05 Mar 2010 14:37:11 GMT Client-Peer: 75.101.147.222:80 Client-Response-Num: 1 -GOOGLE: HEAD http://mt1.google.com/vt/lyr...@118hl=dex=3y=6z=4s=Galileo; 200 OK Cache-Control: public, max-age= Connection: close Date: Fri, 05 Mar 2010 14:45:02 GMT Server: maptiles-versatile Content-Length: 19810 Content-Type: image/png Client-Date: Fri, 05 Mar 2010 14:45:02 GMT Client-Peer: 64.233.189.136:80 Client-Response-Num: 1 X-Content-Type-Options: nosniff X-XSS-Protection: 0 Sorry, I posted something similar bevor: http://www.mail-archive.com/talk@openstreetmap.org/msg23461.html Bernhard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
On 5 Mar 2010, at 24:29 , Robin Paulson wrote: On 5 March 2010 20:40, Apollinaris Schoell ascho...@gmail.com wrote: Don't use coastline but tag the basin with natural water or any other water type tags like riverbank … hmm, well if we can ignore for a moment the abomination of inconsistency that is water tagging in general and natural=water specifically, then no: the basin is tidal, so it's coastline Didn't see when zoomed in to your view. clear now from low zoom. you can hack it but that is dirty tagging for the renderer. Osmarender: add layer=-1 to the park Mapnik: add a water polygon and this will render on top of all other area features. If you consider micro mapping in future it's probably better not to use the landuse at all instead add a boundary national_park to render the boundary itself and have landuse polygons for wood,meadow,… for the details coastline is also sensitive to direction while water has to be a closed polygon only, direction doesn't matter yes ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile caching (osm startpage)
On 6 March 2010 01:24, Bernhard zwischenbrugger b...@datenkueche.com wrote: Google Cache Time: Cache-Control: public, max-age= //feels like one month (I didn't calculate) I'd say it's a bad idea to specify a cache time, instead there is other caching mechanisms to tell if a tile has changed: ETag: d096ddafba32c0da609007e224530ccd This way if a tile never changes you never need to refresh. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM 3 GeoNames = GeoNames 3 OSM =)
On Sat, 6 Mar 2010, elf Pavlik wrote: Hello Everyone! I just asked on GeoNames mailing list why they don't use OSM for their map functionality. http://groups.google.com/group/geonames/t/ec02877f850cf6c7 A person named Marc responded that OSM share-alike license is too restrictive. Please check link above for his explanation. Could someone explain me how relation between GeoNames and OSM looks at this moment? According to the OSM wiki you use GeoNames for your search functionality. I think it would be nice if GeoNames and other services could use OSM for their mapping functionality. I think GeoNames and OSM have complementary service to each other and I would really like to see them in good relation =) Peace! elf Pavlik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk forwarding to legal-talk i read the forum page, and some of their concepts are quite wrong about OSM ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
On 6 March 2010 01:41, Martin Koppenhoefer dieterdre...@gmail.com wrote: haven't you stated above that the water is part of the park? The multipolygon-relation will exclude the inner from the outer, so IMHO this is not your desired solution... ah, yes. good point. i hadn't understood it fully, thanks for pointing that out ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
On 6 March 2010 06:23, Apollinaris Schoell ascho...@gmail.com wrote: Didn't see when zoomed in to your view. clear now from low zoom. you can hack it but that is dirty tagging for the renderer. it is indeed. i'll leave it as is, and come up with some bullshit for when a casual map user asks why panmure basin is coloured green Osmarender: add layer=-1 to the park Mapnik: add a water polygon and this will render on top of all other area features. ugh, that's horrible. If you consider micro mapping in future it's probably better not to use the landuse at all instead add a boundary national_park to render the boundary itself and have landuse polygons for wood,meadow,… for the details landuse? no, i didn't use that. i used leisure=park and it's not a national park, only local council ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] cebit
I have not seen this news here on the lists: http://www.h-online.com/open/news/item/CeBIT-2010-Linux-New-Media-Awards-presented-946907.html The jury chose OpenStreetMap as the most innovative open source project. Second place in this category with an equal number of votes was awarded to KDE and CouchDB. Intel prevailed against AMD and Sun as the most Linux-friendly hardware vendor. -- -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Some measure to prevent duplicate uploads of same data ...
While API 0.6 have implemented object versioning, preventing accidentally overwriting someone else's changes, with introduction of atomic uploads now I see many problems with duplicate data. These come often with imports of data or generally if someone uploads any new data without modifying any existing data (like if someone just traces hundreds of buildings from ortophoto, or alike ) Since in JOSM (and possibly in other tools) the atomic upload is the default method, that user presses some upload button and in few seconds all the changes are uploaded to the server, which then starts processing it (this could take some time for larger changes) and once it is finished, it will send new node ID's back to the editor. Unfortunately, sometimes while waiting for server to process the uploaded data, the connection will timeout, so the user sees some error message - thinking the upload failed, he presses upload again, starting to push new copy of all the objects to the server. Later, the server want to return ID's from first upload, but nobody is listening on the orher end anymore. Ultimate result is sometimes having 2 to 4 identical copies of some data, sometimes it is thousands of duplicate nodes and ways. Suggestion for one possible countermeasure: after server receives complete succesful atomic upload from user, compute SHA1, MD5, or some other checksum of the uploaded XML. Store it and if user tries uploading exactly the same thing again (because he thinks the upload have failed, which is not true), send him just some error message instead, like: You have already uploaded this data. Or alternatively, send the user whatever result was there from the last upload (either new set of ID's, or some error message in case that previous upload failed because of some error) I think perhaps last 2 or 3 checksums could be stored in case someone have multiple parallel uploads in multiple editors. Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Some measure to prevent duplicate uploads of same data ...
Hi, On 6 March 2010 00:16, MP singular...@gmail.com wrote: While API 0.6 have implemented object versioning, preventing accidentally overwriting someone else's changes, with introduction of atomic uploads now I see many problems with duplicate data. These come often with imports of data or generally if someone uploads any new data without modifying any existing data (like if someone just traces hundreds of buildings from ortophoto, or alike ) Since in JOSM (and possibly in other tools) the atomic upload is the default method, that user presses some upload button and in few seconds all the changes are uploaded to the server, which then starts processing it (this could take some time for larger changes) and once it is finished, it will send new node ID's back to the editor. Unfortunately, sometimes while waiting for server to process the uploaded data, the connection will timeout, so the user sees some error message - thinking the upload failed, he presses upload again, starting to push new copy of all the objects to the server. Later, the server want to return ID's from first upload, but nobody is listening on the orher end anymore. Ultimate result is sometimes having 2 to 4 identical copies of some data, sometimes it is thousands of duplicate nodes and ways. Suggestion for one possible countermeasure: after server receives complete succesful atomic upload from user, compute SHA1, MD5, or some other checksum of the uploaded XML. Store it and if user tries uploading exactly the same thing again (because he thinks the upload have failed, which is not true), send him just some error message instead, like: You have already uploaded this data. This sounds like a good idea to me. Perhaps it should only be employed for diff uploads with only create's, for all other cases a re-upload will fail with a conflict. An identical measure can be implemented in the client such as JOSM. Only the uploads with solely new objects need to be extra cautious, but even for other uploads JOSM could admittedly be better at treating network errors, for example by looking at the last open changeset and retrieving the new IDs and versions of objects which should have been in the server response. I have a very experimental script that generates the server response based on the content uploaded and the corresponding changeset as downloaded from the api, which I use for bulk uploads, at http://svn.openstreetmap.org/applications/utils/import/bulkupload/change2diff2.py It only works if the changeset contains only the single diff and it makes other significant assumptions. Generally if you're not uploading through a proxy and the diff is not in conflict with existing data (for example because it only creates new objects) I notice that it will always hit the database if 100% of the xml is uploaded, i.e. once the last byte has been sent out the api never cancels the commit, if on the contrary not all bytes were sent out, the api will not be able to parse it as xml, so it's deterministic. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Some measure to prevent duplicate uploads of same data ...
MP wrote: While API 0.6 have implemented object versioning, preventing accidentally overwriting someone else's changes, with introduction of atomic uploads now I see many problems with duplicate data. These come often with imports of data or generally if someone uploads any new data without modifying any existing data (like if someone just traces hundreds of buildings from ortophoto, or alike ) Since in JOSM (and possibly in other tools) the atomic upload is the default method, that user presses some upload button and in few seconds all the changes are uploaded to the server, which then starts processing it (this could take some time for larger changes) and once it is finished, it will send new node ID's back to the editor. Unfortunately, sometimes while waiting for server to process the uploaded data, the connection will timeout, so the user sees some error message - thinking the upload failed, he presses upload again, starting to push new copy of all the objects to the server. Later, the server want to return ID's from first upload, but nobody is listening on the orher end anymore. Ultimate result is sometimes having 2 to 4 identical copies of some data, sometimes it is thousands of duplicate nodes and ways. Suggestion for one possible countermeasure: after server receives complete succesful atomic upload from user, compute SHA1, MD5, or some other checksum of the uploaded XML. Store it and if user tries uploading exactly the same thing again (because he thinks the upload have failed, which is not true), send him just some error message instead, like: You have already uploaded this data. Or alternatively, send the user whatever result was there from the last upload (either new set of ID's, or some error message in case that previous upload failed because of some error) I think perhaps last 2 or 3 checksums could be stored in case someone have multiple parallel uploads in multiple editors. Martin This is really a problem, especially for large data imports. The solution might not be so easy: JOSM offers to upload the data in chunks of different sizes, or even each object separately. If the upload fails (due to timeout), the user might vary these paramenters, so the checksums become useless. There was a discussion on that topic in josm trac: http://josm.openstreetmap.de/ticket/4401 It was suggested, that a final handshake should be required after the diff is sent from the server. If the client does not respond, the upload is discarded. It would be nice to have a solution for this in API 0.7, but in the meantime, the editors should learn to handle this in a better way. The user should be informed, that the dataset is in a dirty state and offer downloading the changeset. The new objects of the current dataset should then be matched heuristically (by their coordinates and tags) with the objects in the changeset. __ Sebastian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline within a park
On 5 Mar 2010, at 13:41 , Robin Paulson wrote: landuse? no, i didn't use that. i used leisure=park sure. ahh… our messy key,tag combinations for areas natural, landuse, leisure … and it's not a national park, only local council we still use it for parks if it's the type of parks protecting nature and add a admin_level similar to political boundary hierarchy key national_park is also documented that it can be used in a wider range of parks. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (amenity=ice_cream)
Roy Wallace ha scritto: Use amenity=* for useful and important facilities. Use shop=* for a place selling a retail product or service It could be a sensible proposal, but at present state the shops where you can sit and eat (or even the take-away shops) are all tagged as amenity. The problem is that the same service could be offered by a more general amenity, such a cafeteria (or a bar, in the mediterranean meaning). So I would prefer something like: amenity=fast_food cuisine=ice_cream or amenity=cafe cuisine=ice_cream and so on. -- Giacomo Boschi http://gwilbor.wordpress.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Map export broken in IE/Opera
Exporting from the OSM slippymap. The options are not visible for either of the image options nor the HTML option. Looks OK in Firefox and Safari. Is this a good enough place to report this problem, or should I send a message or something elsewhere? It was working fine a couple of weeks ago when I last did an export. Thanks. -- Andrew Gregory mailto:and...@scss.com.au http://www.scss.com.au/family/andrew/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile caching (osm startpage)
John Smith schrieb: On 6 March 2010 01:24, Bernhard zwischenbrugger b...@datenkueche.com wrote: Google Cache Time: Cache-Control: public, max-age= //feels like one month (I didn't calculate) I'd say it's a bad idea to specify a cache time, instead there is other caching mechanisms to tell if a tile has changed: ETag: d096ddafba32c0da609007e224530ccd This way if a tile never changes you never need to refresh. But the browser sends the ETag to the server all the time. The server answers 304 not modified. Phnom Penh load times: To get the HTTP header of a picture takes here at the moment 1.3 seconds. To load the picture it's about 2.5 seconds for a single picture. An image that is already in cache takes about 1.3 seconds to load (must wait for 304 header). This values are measured using wget and HEAD at commandline. In browser the load time is even worse. see: http://wiki.openstreetmap.org/wiki/File:Imageloadtime.png Bernhard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Probleem met mapnik rendering voor EPSG:28992
Hallo, Ik probeer tiles te renderen met Mapnik in NL projectie 28992 (ja met de goede proj setting!). Alles lijkt goed te gaan. Via TileCache met Mapnik backend worden tiles gegenereerd. Deze kloppen exact met andere 28992 bronnen qua extent/resolutie opgegeven in tilecache.cfg/OpenLayers. Het enige probleem is dat, denk ik, in deze 28992-projectie de world_boundaries niet worden gerenderd. Dit zie ik ook als ik met generate_image.py probeer. Zie bijv. http://www.geoskating.com/nl.28992.png Als ik in een andere projectie render bijv. 900913 krijg ik wel een beter kaartbeeld: http://www.geoskating.com/nl.90013.png Ik vermoed ergens een mismatch tussen projecties/extents in osm.xml (mijn Map is srs28992) en datasource extent is 2.307,50.134,8.752,54.087 met PG data in 4326) of moeten de world_boundaries een herprojectie naar 28992 krijgen ? Iemand enig idee ? Bedankt en groet, --Just Just van den Broecke j...@justobjects.nl The Netherlands http://www.justobjects.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Probleem met mapnik rendering voor EPSG:28992
Just van den Broecke wrote: Ik vermoed ergens een mismatch tussen projecties/extents in osm.xml (mijn Map is srs28992) en datasource extent is 2.307,50.134,8.752,54.087 met PG data in 4326) of moeten de world_boundaries een herprojectie naar 28992 krijgen ? Iemand enig idee ? Bedankt en groet, De srs op de shapefile layers moet op srs900913; blijven staan. Dan herprojecteert mapnik naar de Map srs. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Probleem met mapnik rendering voor EPSG:28992
Lennard wrote: Just van den Broecke wrote: Ik vermoed ergens een mismatch tussen projecties/extents in osm.xml (mijn Map is srs28992) en datasource extent is 2.307,50.134,8.752,54.087 met PG data in 4326) of moeten de world_boundaries een herprojectie naar 28992 krijgen ? Iemand enig idee ? Bedankt en groet, De srs op de shapefile layers moet op srs900913; blijven staan. Dan herprojecteert mapnik naar de Map srs. Deze heb ik niet gewijzigd: grep srs inc/layer-shapefiles.xml.inc geeft: Layer name=world status=on srs=srs900913; Layer name=coast-poly status=on srs=srs900913; Layer name=builtup status=on srs=srsmercator; Ook als ik builtup op srs900913 zet zie ik geen verschil. In generate_image.py gebruik ik: prj = mapnik.Projection(+proj=sterea +lat_0=52.156160 +lon_0=5.387639 +k=0.079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.237,50.0087,465.658,-0.406857,0.350733,-1.87035,4.0812 +units=m +no_defs) Dit en Map zijn de enige plekken waar 28992 wordt gebruikt. Tilecache zal iets soortgelijks doen (gaat via WMS 28992 request). groet, Just ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Probleem met mapnik rendering voor EPSG:28992
Just van den Broecke wrote: Dit en Map zijn de enige plekken waar 28992 wordt gebruikt. Tilecache zal iets soortgelijks doen (gaat via WMS 28992 request). Na een kort overleg op irc, komen we tot de conclusie dat dit waarschijnlijk gerelateerd is aan http://trac.mapnik.org/ticket/308. Met andere woorden: proj4 vindt de shapefile niet 100% goed om te herprojecteren, en mapnik dropt hem daardoor. Je kunt proberen om de processed_p/shoreline_300 vooraf al te herprojecteren naar 28992. Voor de snelheid is dit sowieso aan te raden. Eventueel in ogr2ogr clippen naar de extent van RD, want ver buiten onze regio zal het er niet zo best meer uitzien. Extent van planet-benelux in RD: select ST_Extent(ST_Transform(way,28992)) from planet_osm_line; st_extent --- BOX(-68410.3434188713 153865.862287649,295804.476664188 636639.887598609) -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Probleem met mapnik rendering voor EPSG:28992
Ja dit is precies waar ik net mee bezig ging: clippen naar RD extent en
dan herprojecteren. Iets als
ogr2ogr -f ESRI Shapefile -s_srs EPSG:... -t_srs EPSG:28992 -spat
${extent} ${dstShp} ${srcShp}
Bedankt voor de hulp alvast! Ik laat weten hoe dit verder verloopt.
groet,
Just van den Broecke
Lennard wrote:
Just van den Broecke wrote:
Dit en Map zijn de enige plekken waar 28992 wordt gebruikt. Tilecache
zal iets soortgelijks doen (gaat via WMS 28992 request).
Na een kort overleg op irc, komen we tot de conclusie dat dit
waarschijnlijk gerelateerd is aan http://trac.mapnik.org/ticket/308.
Met andere woorden: proj4 vindt de shapefile niet 100% goed om te
herprojecteren, en mapnik dropt hem daardoor.
Je kunt proberen om de processed_p/shoreline_300 vooraf al te
herprojecteren naar 28992. Voor de snelheid is dit sowieso aan te raden.
Eventueel in ogr2ogr clippen naar de extent van RD, want ver buiten onze
regio zal het er niet zo best meer uitzien.
Extent van planet-benelux in RD:
select ST_Extent(ST_Transform(way,28992)) from planet_osm_line;
st_extent
---
BOX(-68410.3434188713 153865.862287649,295804.476664188 636639.887598609)
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Probleem met mapnik rendering voor EPSG:28992
Ja dit was het probleem en dus idd op te lossen door de world_boundaries
shapes te clippen/herprojecteren. Bijv. met
ogr2ogr -f ESRI Shapefile -s_srs EPSG:3785 -t_srs EPSG:28992 -spat
311523.765594493 6555476.44574815 822461.515529216 7160903.43417988
processed_p_nl.shp processed_p.shp
waarbij extent verkregen kan worden via
select ST_Extent(ST_Transform(way,3785)) from planet_osm_line;
st_extent
--
BOX(311523.765594493 6555476.44574815,822461.515529216 7160903.43417988)
(Ipv EPSG:900913 EPSG:3785 gebruikt.
)
De SRS-en dan naar 28992 zetten in inc/layer-shapefiles.xml.inc en voila.
nogmaals dank en groet,
Just van den Broecke
Just van den Broecke wrote:
Ja dit is precies waar ik net mee bezig ging: clippen naar RD extent en
dan herprojecteren. Iets als
ogr2ogr -f ESRI Shapefile -s_srs EPSG:... -t_srs EPSG:28992 -spat
${extent} ${dstShp} ${srcShp}
Bedankt voor de hulp alvast! Ik laat weten hoe dit verder verloopt.
groet,
Just van den Broecke
Lennard wrote:
Just van den Broecke wrote:
Dit en Map zijn de enige plekken waar 28992 wordt gebruikt. Tilecache
zal iets soortgelijks doen (gaat via WMS 28992 request).
Na een kort overleg op irc, komen we tot de conclusie dat dit
waarschijnlijk gerelateerd is aan http://trac.mapnik.org/ticket/308.
Met andere woorden: proj4 vindt de shapefile niet 100% goed om te
herprojecteren, en mapnik dropt hem daardoor.
Je kunt proberen om de processed_p/shoreline_300 vooraf al te
herprojecteren naar 28992. Voor de snelheid is dit sowieso aan te raden.
Eventueel in ogr2ogr clippen naar de extent van RD, want ver buiten onze
regio zal het er niet zo best meer uitzien.
Extent van planet-benelux in RD:
select ST_Extent(ST_Transform(way,28992)) from planet_osm_line;
st_extent
---
BOX(-68410.3434188713 153865.862287649,295804.476664188 636639.887598609)
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
--
Just
Just van den Broecke j...@justobjects.nl
Just Objects B.V. tel +31 65 4268627 Skype: justb4
The Netherlands http://www.justobjects.nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] more broken boundaries
It would be useful to have access to a layer showing boundaries sourced externally as they were when originally loaded. That way the current boundary state can always be compared with the original. However the below email is a bit cryptic for me. How are boundaries getting broken? One of the attached changesets indicates that the purpose was to separate administrative boundaries from roads, whereas recently I have been tagging administrative boundaries with keys for highways or waterways that follow the same course. Is there a consensus on the right way to go on this? --- On Fri, 5/3/10, John Smith deltafoxtrot...@gmail.com wrote: From: John Smith deltafoxtrot...@gmail.com Subject: [talk-au] more broken boundaries To: OSM Australian Talk List talk-au@openstreetmap.org Received: Friday, 5 March, 2010, 9:47 AM Anyone have any suggestions on how to approach people accidently breaking boundaries, or better yet thoughts on how to prevent them from being broken in the first place? http://www.openstreetmap.org/browse/changeset/3358719 http://www.openstreetmap.org/browse/changeset/4007178 etc... ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] more broken boundaries
On 6 March 2010 08:09, Neil Penman ianaf4...@yahoo.com wrote: It would be useful to have access to a layer showing boundaries sourced externally as they were when originally loaded. That way the current boundary state can always be compared with the original. However the below email is a bit cryptic for me. How are boundaries getting broken? One of the attached changesets indicates that the purpose was to separate administrative boundaries from roads, whereas recently I have been tagging administrative boundaries with keys for highways or waterways that follow the same course. Is there a consensus on the right way to go on this? It doesn't matter what specifically happens to the boundaries themselves, but it's rather easy to break the admin boundary relations either by merging admin segments, but I'm not sure what happened in the cases I've mentioned, although it appears segments were deleted from the boundary, not just splitting the ways as I had to re-add them. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] more broken boundaries
On Sat, 6 Mar 2010, Neil Penman wrote: One of the attached changesets indicates that the purpose was to separate administrative boundaries from roads, whereas recently I have been tagging administrative boundaries with keys for highways or waterways that follow the same course. Is there a consensus on the right way to go on this? I can't claim a consensus but I do not reuse the nodes of an admin boundary for a road. Roads do change at the whim of the local council as they realign corners etc. It also makes editing the roads difficult - and here it makes it hard for a new user to edit the road without breaking the admin boundary. I do reuse the nodes for waterways because they are far more accurate than anything I can achieve for a river off Landsat imagery, and I have no other means of mapping the waterways in western NSW. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australia BP service station datase
On 6 March 2010 16:07, Nic Roets nro...@gmail.com wrote: I'm also guessing that amenity:express should rather be tagged as shop:convenience which is closer to the OSM tagging convention. I have no strong opinion either way, that's just how it appears in the BP CSV file. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Trunk roads in central Australia
I may be wrong here, but it just seems wrong to me that these roads are marked as trunk: http://www.openstreetmap.org/?lat=-24.5503234863281lon=132.173767089844zoom=9 Except for the Stuart Highway, I'm guessing, but shouldn't they be primary or secondary? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-br] Key:place
Em 4 de março de 2010 23:41, Flávio Henrique yoshi...@gmail.com escreveu: pois em certos municípios do brasil teríamos varias villages, e não seria possível definir qual a sede do município. Qual o impacto disso no osm? Até o presente momento não vi onde estas informações influenciam no mapa. Será que o colega não estava se referindo a isto? http://osm.org/go/M5t2P2C Apesar de aparecer cinco nomes - Brochier - Maratá - Santos Reis - Costa da Serra - S. José do Maratá Apenas duas são cidades: Brochier e Maratá. As outras são distritos. Mas, por causa do número de habitantes, todas estão marcadas como village. -- Rodrigo de Avila Analista de Desenvolvimento +55 51 9733.3488 • rodr...@avila.net.br • www.avila.net.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Key:place
Para quem usa o mapa, o que interessa é o tamanho da cidade. Não faz sentido Guarulhos/SP e Campinas/SP, ambas com mais de 1 milhão de habitantes, terem a mesma classificação que Borá/SP ou Serra da Saudade/MG, ambas com menos de 1000. Sugiro que fique como está: city 100.000 (273 municípios) town 10.000 (2741 municípios) village 1000 (2549 municípios) hamlet 1000 (2 municípios) Como exceção, acho razoável que Borá/SP (pop=837) e Serra da Saudade/MG (pop=890) sejam classificados como village, já que são os dois únicos municípios brasileiros com menos de 1000 habitantes. Sempre colocar também a população, usando como fonte o IBGE: ftp://ftp.ibge.gov.br/Estimativas_Projecoes_Populacao/Estimativas_2009/UF_Municipio.zip Flávio Henrique escreveu: Eu não tenho óbice em nenhuma das duas formas de classificação. Tenho a tendência em gostar mais da opção proposta por você Alexandre. Entretanto, tenho uma dúvida no seguinte trecho: pois em certos municípios do brasil teríamos varias villages, e não seria possível definir qual a sede do município. Qual o impacto disso no osm? Até o presente momento não vi onde estas informações influenciam no mapa. Grato. Flávio Henrique On Thu, Mar 4, 2010 at 23:34, Alexandre Parente Lima alexandre.pare...@gmail.com mailto:alexandre.pare...@gmail.com wrote: Bom dia. Segundo a wiki do openstreetmap, /In //most// Western //countries//, //the// status //of// a //location// (//whether// //it// //is// a //city/town///etc.), //is// //decided// //by// //the// //government//, //and// //is// //not// a //function// //of// //size//. //But// //most// //OSM// //communities// //of// //those// //countries// //have// made a //convention// to use //the// //population// to decide //which// //place// //tag// to use, to //ensure// a more //common// //way// //of// //tagging// //across// //the// //globe//, //and// //not// to //end// up //with// //cities// //of// 1000 //residents// for //example//. In //any// case, //check// //the// //country// //pages// //on// //this// //wiki// to decide //how// to //tag// a //place// in //each// //specific// //country//./ Dessa forma, gostaria de um posicionamento quanto ao uso da tag /place/. Hoje, utilizamos o numero de habitantes para definir se um aglomerado urbano é uma /city//, //town//, , //village//, //halmet/. Acredito que isso não contribui com muita em termos de informação, pelo contrario, pode até confundir, pois em certos municípios do brasil teríamos varias villages, e não seria possível definir qual a sede do município. Minha sugestão seria: *Capitais :* /City/ *Municípios:* /Town/ *Distritos: */Village/ *Vilas, Assentamentos rurais , comunidades, etc, etc : */Halmet/ *Junto ao uso da **tag**:** *population=number Alexandre Parente Lima ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Key:place
Pessoal, desculpe se a pergunta já foi respondida ou parecer sem noção, mas eu ainda não sei qual a diferença no mapa ou para quem pesquisa, se um node é classificado como city, town, etc. Alguém poderia me esclarecer se há diferença visual? Resumindo, a classificação influencia em quê? (não quero passar a idéia de que sou contra a classificação. É só pra entender) Grato. Flávio Henrique 2010/3/5 Aun Johnsen li...@gimnechiske.org Bem atrais fui om suggecao do tag capital=yes, ou capital=admin_level para mapear os capitais. Poder ser usado tambem, e os renderers poder utalizar para prioritar os simbolos no mapa. A 2010/3/5 Luigi Castro Cardeles luigi.carde...@gmail.com: Ou então a solução é uma nova tag para capital/sede? []'s Luigi Castro Cardeles Em 5 de março de 2010 09:44, Alexandre Parente Lima alexandre.pare...@gmail.com escreveu: Flavio, e será que é razoável São Paulo/SP e Santa Rita/PB terem a mesma classificação? Santa Rita/PB e vizinho a João Pessoa/PB, capital do Estado, segundo a classificação atual nada as diferem, e a única informação que tenho é que ambas tem mais de 100.000 habitantes. Na classificação sugerida, com uso da tag population, saberíamos que João Pessoa é a capital do Estado, Santa Rita um município (que por acaso possui diversos distritos e vilas) e por fim sua população. No estado de São Paulo a nova classificação daria destaque a capital, atribuindo a categoria de town a diversas outros município com mais de 100.000 habitantes naquele estado, como: Barueri, Araçatuba, etc, etc Um problema em particular, Município do Conde/PB, sua população é de 20.000 habitantes (somado todas as suas vilas e distritos), só que boa parte (90%) residem no distrito de Jacuma, graças a população que reside em Jacuma (mais de 10.000 hab) e outras vilas a Villa do Conde/PB recebe a classificação de town Bem, é isso. Em 5 de março de 2010 10:03, Flavio Bello Fialho be...@cnpuv.embrapa.br escreveu: Para quem usa o mapa, o que interessa é o tamanho da cidade. Não faz sentido Guarulhos/SP e Campinas/SP, ambas com mais de 1 milhão de habitantes, terem a mesma classificação que Borá/SP ou Serra da Saudade/MG, ambas com menos de 1000. Sugiro que fique como está: city 100.000 (273 municípios) town 10.000 (2741 municípios) village 1000 (2549 municípios) hamlet 1000 (2 municípios) Como exceção, acho razoável que Borá/SP (pop=837) e Serra da Saudade/MG (pop=890) sejam classificados como village, já que são os dois únicos municípios brasileiros com menos de 1000 habitantes. Sempre colocar também a população, usando como fonte o IBGE: ftp://ftp.ibge.gov.br/Estimativas_Projecoes_Populacao/Estimativas_2009/UF_Municipio.zip Flávio Henrique escreveu: Eu não tenho óbice em nenhuma das duas formas de classificação. Tenho a tendência em gostar mais da opção proposta por você Alexandre. Entretanto, tenho uma dúvida no seguinte trecho: pois em certos municípios do brasil teríamos varias villages, e não seria possível definir qual a sede do município. Qual o impacto disso no osm? Até o presente momento não vi onde estas informações influenciam no mapa. Grato. Flávio Henrique On Thu, Mar 4, 2010 at 23:34, Alexandre Parente Lima alexandre.pare...@gmail.com mailto:alexandre.pare...@gmail.com wrote: Bom dia. Segundo a wiki do openstreetmap, /In //most// Western //countries//, //the// status //of// a //location// (//whether// //it// //is// a //city/town///etc.), //is// //decided// //by// //the// //government//, //and// //is// //not// a //function// //of// //size//. //But// //most// //OSM// //communities// //of// //those// //countries// //have// made a //convention// to use //the// //population// to decide //which// //place// //tag// to use, to //ensure// a more //common// //way// //of// //tagging// //across// //the// //globe//, //and// //not// to //end// up //with// //cities// //of// 1000 //residents// for //example//. In //any// case, //check// //the// //country// //pages// //on// //this// //wiki// to decide //how// to //tag// a //place// in //each// //specific// //country//./ Dessa forma, gostaria de um posicionamento quanto ao uso da tag /place/. Hoje, utilizamos o numero de habitantes para definir se um aglomerado urbano é uma /city//, //town//, , //village//, //halmet/. Acredito que isso não contribui com muita em termos de informação, pelo contrario, pode até confundir, pois em certos municípios do brasil teríamos varias villages, e não seria possível definir qual a sede do município. Minha sugestão seria: *Capitais :* /City/ *Municípios:* /Town/ *Distritos: */Village/ *Vilas, Assentamentos rurais , comunidades, etc, etc :
Re: [Talk-br] Key:place
Lembre-se de uma das regras de ouro do OSM, não taguear para o renderizador :) No Mapnik, faz diferença no tamanho da letra utilizada e em qual será mostrada em baixos níveis de zoom. []s Em 5 de março de 2010 14:59, Flávio Henrique yoshi...@gmail.com escreveu: Pessoal, desculpe se a pergunta já foi respondida ou parecer sem noção, mas eu ainda não sei qual a diferença no mapa ou para quem pesquisa, se um node é classificado como city, town, etc. Alguém poderia me esclarecer se há diferença visual? Resumindo, a classificação influencia em quê? (não quero passar a idéia de que sou contra a classificação. É só pra entender) Grato. Flávio Henrique 2010/3/5 Aun Johnsen li...@gimnechiske.org Bem atrais fui om suggecao do tag capital=yes, ou capital=admin_level para mapear os capitais. Poder ser usado tambem, e os renderers poder utalizar para prioritar os simbolos no mapa. A 2010/3/5 Luigi Castro Cardeles luigi.carde...@gmail.com: Ou então a solução é uma nova tag para capital/sede? []'s Luigi Castro Cardeles Em 5 de março de 2010 09:44, Alexandre Parente Lima alexandre.pare...@gmail.com escreveu: Flavio, e será que é razoável São Paulo/SP e Santa Rita/PB terem a mesma classificação? Santa Rita/PB e vizinho a João Pessoa/PB, capital do Estado, segundo a classificação atual nada as diferem, e a única informação que tenho é que ambas tem mais de 100.000 habitantes. Na classificação sugerida, com uso da tag population, saberíamos que João Pessoa é a capital do Estado, Santa Rita um município (que por acaso possui diversos distritos e vilas) e por fim sua população. No estado de São Paulo a nova classificação daria destaque a capital, atribuindo a categoria de town a diversas outros município com mais de 100.000 habitantes naquele estado, como: Barueri, Araçatuba, etc, etc Um problema em particular, Município do Conde/PB, sua população é de 20.000 habitantes (somado todas as suas vilas e distritos), só que boa parte (90%) residem no distrito de Jacuma, graças a população que reside em Jacuma (mais de 10.000 hab) e outras vilas a Villa do Conde/PB recebe a classificação de town Bem, é isso. Em 5 de março de 2010 10:03, Flavio Bello Fialho be...@cnpuv.embrapa.br escreveu: Para quem usa o mapa, o que interessa é o tamanho da cidade. Não faz sentido Guarulhos/SP e Campinas/SP, ambas com mais de 1 milhão de habitantes, terem a mesma classificação que Borá/SP ou Serra da Saudade/MG, ambas com menos de 1000. Sugiro que fique como está: city 100.000 (273 municípios) town 10.000 (2741 municípios) village 1000 (2549 municípios) hamlet 1000 (2 municípios) Como exceção, acho razoável que Borá/SP (pop=837) e Serra da Saudade/MG (pop=890) sejam classificados como village, já que são os dois únicos municípios brasileiros com menos de 1000 habitantes. Sempre colocar também a população, usando como fonte o IBGE: ftp://ftp.ibge.gov.br/Estimativas_Projecoes_Populacao/Estimativas_2009/UF_Municipio.zip Flávio Henrique escreveu: Eu não tenho óbice em nenhuma das duas formas de classificação. Tenho a tendência em gostar mais da opção proposta por você Alexandre. Entretanto, tenho uma dúvida no seguinte trecho: pois em certos municípios do brasil teríamos varias villages, e não seria possível definir qual a sede do município. Qual o impacto disso no osm? Até o presente momento não vi onde estas informações influenciam no mapa. Grato. Flávio Henrique On Thu, Mar 4, 2010 at 23:34, Alexandre Parente Lima alexandre.pare...@gmail.com mailto:alexandre.pare...@gmail.com wrote: Bom dia. Segundo a wiki do openstreetmap, /In //most// Western //countries//, //the// status //of// a //location// (//whether// //it// //is// a //city/town///etc.), //is// //decided// //by// //the// //government//, //and// //is// //not// a //function// //of// //size//. //But// //most// //OSM// //communities// //of// //those// //countries// //have// made a //convention// to use //the// //population// to decide //which// //place// //tag// to use, to //ensure// a more //common// //way// //of// //tagging// //across// //the// //globe//, //and// //not// to //end// up //with// //cities// //of// 1000 //residents// for //example//. In //any// case, //check// //the// //country// //pages// //on// //this// //wiki// to decide //how// to //tag// a //place// in //each// //specific// //country//./ Dessa forma, gostaria de um posicionamento quanto ao uso da tag /place/. Hoje, utilizamos o numero de habitantes para definir se um aglomerado urbano é uma /city//, //town//, , //village//, //halmet/. Acredito que isso não contribui com muita em termos de informação, pelo contrario, pode até confundir, pois em
Re: [Talk-br] Key:place
mas como voce tem duas cidades perto (city), por inquanto Mapnik render so um deles no zoom pequeno (8), e os duas no zoom mais alto (14). Tags como population= e capital= poder ser no futuro alterar este, como o cidade mais grande ou o capital ganha prioridade do render. A 2010/3/5 Alexandre Parente Lima alexandre.pare...@gmail.com: A diferença esta na renderização do nome do local. (tamanho da fonte) Citytownvilagehalmet Outra diferença é em que plano ele é renderizado. (zoom) Mais ou menos assim: city town vilage halmet Alexandre Parente Lima Em 5 de março de 2010 15:59, Flávio Henrique yoshi...@gmail.com escreveu: Pessoal, desculpe se a pergunta já foi respondida ou parecer sem noção, mas eu ainda não sei qual a diferença no mapa ou para quem pesquisa, se um node é classificado como city, town, etc. Alguém poderia me esclarecer se há diferença visual? Resumindo, a classificação influencia em quê? (não quero passar a idéia de que sou contra a classificação. É só pra entender) Grato. Flávio Henrique 2010/3/5 Aun Johnsen li...@gimnechiske.org Bem atrais fui om suggecao do tag capital=yes, ou capital=admin_level para mapear os capitais. Poder ser usado tambem, e os renderers poder utalizar para prioritar os simbolos no mapa. A 2010/3/5 Luigi Castro Cardeles luigi.carde...@gmail.com: Ou então a solução é uma nova tag para capital/sede? []'s Luigi Castro Cardeles Em 5 de março de 2010 09:44, Alexandre Parente Lima alexandre.pare...@gmail.com escreveu: Flavio, e será que é razoável São Paulo/SP e Santa Rita/PB terem a mesma classificação? Santa Rita/PB e vizinho a João Pessoa/PB, capital do Estado, segundo a classificação atual nada as diferem, e a única informação que tenho é que ambas tem mais de 100.000 habitantes. Na classificação sugerida, com uso da tag population, saberíamos que João Pessoa é a capital do Estado, Santa Rita um município (que por acaso possui diversos distritos e vilas) e por fim sua população. No estado de São Paulo a nova classificação daria destaque a capital, atribuindo a categoria de town a diversas outros município com mais de 100.000 habitantes naquele estado, como: Barueri, Araçatuba, etc, etc Um problema em particular, Município do Conde/PB, sua população é de 20.000 habitantes (somado todas as suas vilas e distritos), só que boa parte (90%) residem no distrito de Jacuma, graças a população que reside em Jacuma (mais de 10.000 hab) e outras vilas a Villa do Conde/PB recebe a classificação de town Bem, é isso. Em 5 de março de 2010 10:03, Flavio Bello Fialho be...@cnpuv.embrapa.br escreveu: Para quem usa o mapa, o que interessa é o tamanho da cidade. Não faz sentido Guarulhos/SP e Campinas/SP, ambas com mais de 1 milhão de habitantes, terem a mesma classificação que Borá/SP ou Serra da Saudade/MG, ambas com menos de 1000. Sugiro que fique como está: city 100.000 (273 municípios) town 10.000 (2741 municípios) village 1000 (2549 municípios) hamlet 1000 (2 municípios) Como exceção, acho razoável que Borá/SP (pop=837) e Serra da Saudade/MG (pop=890) sejam classificados como village, já que são os dois únicos municípios brasileiros com menos de 1000 habitantes. Sempre colocar também a população, usando como fonte o IBGE: ftp://ftp.ibge.gov.br/Estimativas_Projecoes_Populacao/Estimativas_2009/UF_Municipio.zip Flávio Henrique escreveu: Eu não tenho óbice em nenhuma das duas formas de classificação. Tenho a tendência em gostar mais da opção proposta por você Alexandre. Entretanto, tenho uma dúvida no seguinte trecho: pois em certos municípios do brasil teríamos varias villages, e não seria possível definir qual a sede do município. Qual o impacto disso no osm? Até o presente momento não vi onde estas informações influenciam no mapa. Grato. Flávio Henrique On Thu, Mar 4, 2010 at 23:34, Alexandre Parente Lima alexandre.pare...@gmail.com mailto:alexandre.pare...@gmail.com wrote: Bom dia. Segundo a wiki do openstreetmap, /In //most// Western //countries//, //the// status //of// a //location// (//whether// //it// //is// a //city/town///etc.), //is// //decided// //by// //the// //government//, //and// //is// //not// a //function// //of// //size//. //But// //most// //OSM// //communities// //of// //those// //countries// //have// made a //convention// to use //the// //population// to decide //which// //place// //tag// to use, to //ensure// a more //common// //way// //of// //tagging// //across// //the// //globe//, //and// //not// to //end// up //with// //cities// //of// 1000 //residents// for //example//. In //any// case, //check// //the// //country// //pages// //on// //this// //wiki// to decide //how// to //tag// a //place// in //each//
Re: [Talk-br] Key:place
Ok. Entendi. Obrigado pessoal. Flávio Henrique 2010/3/5 Alexandre Parente Lima alexandre.pare...@gmail.com A diferença esta na renderização do nome do local. (tamanho da fonte) Citytownvilagehalmet Outra diferença é em que plano ele é renderizado. (zoom) Mais ou menos assim: *city* *town* *vilage* *halmet* Alexandre Parente Lima ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Micro-Mapping
Moin, +1 auch ich finde die relative Genauigkeit im Sinne der Lage der Objekte zueinander wichtiger als die absolute Genauigkeit, die man zwar anstreben, aber nicht von vornherein als Bedingung voraussetzen sollte. Auch nur 'relativ genaue' - im Meterbereich - Gebäudeumrisse können - besonders im ländlichen Raum - anhand des Ensembles als Orientierungspunkte auf einer ausgedruckten/angezeigten Karte dienen - auch ganz ohne GPS. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Anfänger-Frage zum vorhandenen Mappin g der Insel Lindau und des Bodensees
Grüß Euch, beim Betrachten der Insel Lindau (http://www.openstreetmap.org/?lat=47.54673lon=9.68428zoom=16layers=B000FTF) sind mir zwei Dinge aufgefallen: - Die Umrisse der Insel selbst sind nicht - wie ich erwartet hätte - als inner-Teil eines Multipolygons markiert, sondern über den Eisenbahndamm als Teil des outer-Polygons. Ist das so üblich? - Der Bodensee selbst hat Layer=-5 - warum das? Gruß, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Gewinnt Linux New Media Award
Moin, Frederik Ramm schrieb: I am just a mapper, but I come in peace Der Spruch gefällt mir - trug er bereits ein entsprechendes Oberbekleidungsstück, oder darf ich den Slogan zusammen mit dem OSM Logo auf ein Shirt drucken? (Bei einer evtl. Merchandising-Aktion falle ich voraussichtlich eh durch das Größenraster - hat aber Vorteile, was die Werbefläche betrifft ;-) ) Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Info: skobbler-Update mit OSM ist live
Hallo, ich wollte nur kurz bescheid geben, dass skobbler auf Basis von OSM gestern live gegangen ist. Heute folgt noch die Pressemitteilung. Als Routing-Engine benutzen wir den CloudMade-Service. Die Kartendarstellung während der Navigation ist unsere Eigenentwicklung. Ärgerlich ist, dass der CloudMade-Server in der jetzigen Version keine Turn-Restriction-Relationen auswertet. Soll sich aber laut CloudMade bis April ändern. Angezeigt werden alle Geschwindigkeitsbegrenzungen, die auf Basis von maxspeed eingetragen sind. Probleme gibt es unter Umständen auch noch in der Advisordarstellung, wenn an einer T-Kreuzung Abbiegespuren eingezeichnet wurden, dann wird anstatt einer T-Kreuzung erstmal eine V-Kreuzung dargstellt. Hier ist ein Beispiel, wo die Husarenstraße zum Linksabbiegen auf die Graurheindorferstraße trifft: http://www.openstreetmap.org/?lat=50.747584lon=7.094348zoom=18layers=B000FTF. Jochen Topf wird heute auf der FOSSGIS einen neuen Routing-Layer im OSM-Inspektor vorstellen, der von uns gesponsored wurde. Dieser zeigt Probleme von potentiell nicht verbundenen Wegen sowie redundant übereinander liegenden Wegen auf, die zu Problemen beim Routing führen. Gruß Oliver -- View this message in context: http://n2.nabble.com/Info-skobbler-Update-mit-OSM-ist-live-tp4679680p4679680.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPX-Files bearbeiten
Am 05.03.2010 00:42, schrieb Dimitri Junker: Hallo, kann mir jemand ein Programm zum bearbeiten von GPX-Files nennen? Ich habe einige ausprobiert und nichts vernünftiges gefunden. Was ich brauche ist: -Entfernen von Müll (Punktwolken) -mehrere gpx-Files zusammenfügen u.ä. Dimitri routeconverter siehe: routeconverter.de gpx editor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPX-Files bearbeiten
Am 05.03.2010 00:42, schrieb Dimitri Junker: Hallo, kann mir jemand ein Programm zum bearbeiten von GPX-Files nennen? Ich habe einige ausprobiert und nichts vernünftiges gefunden. Was ich brauche ist: -Entfernen von Müll (Punktwolken) -mehrere gpx-Files zusammenfügen u.ä. Dimitri routeconverter siehe: routeconverter.de gpx editor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPX-Files bearbeiten
Hallo Simon, kann mir jemand ein Programm zum bearbeiten von GPX-Files nennen? Ich habe einige ausprobiert und nichts vernünftiges gefunden. Was ich brauche ist: -Entfernen von Müll (Punktwolken) -mehrere gpx-Files zusammenfügen u.ä. Wie wäre es mit QLandkarteGT? Das kann noch viel mehr nette Sachen. :-) Liebe Grüße... Susanne ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfänger-Frage zum vorhandenen Mapping der Insel Lindau und des Bodensees
Moin, Andreas Braunmiller schrieb: Grüß Euch, beim Betrachten der Insel Lindau (http://www.openstreetmap.org/?lat=47.54673lon=9.68428zoom=16layers=B000FTF) sind mir zwei Dinge aufgefallen: - Die Umrisse der Insel selbst sind nicht - wie ich erwartet hätte - als inner-Teil eines Multipolygons markiert, sondern über den Eisenbahndamm als Teil des outer-Polygons. Ist das so üblich? gemessen an der einzigen - mir auf Anhieb einfallenden - Vergleichssituation in Deutschland http://www.openstreetmap.org/?lat=54.916lon=8.567zoom=11layers=B000FTF - ja Die Wasserfläche ist dort - am Damm - definitiv zu enden. - Der Bodensee selbst hat Layer=-5 - warum das? Obsoletes Überbleibsel - wie so einige andere Layer - aus vergangenen Zeiten ... als die Renderer laufen lernten ... Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPX-Files bearbeiten
Hallo Simon, Sorry, zu schnell getippt, das war ein anderes Reply. ;-) sed/Simon/Dimitri Liebe Grüße... Susanne ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] problem mit wput
hi, habe logging noch nicht angeschaltet und noch nicht experimentiert... evtl. kennt jemand das problem bzw. idealerweise die lösung. habe eine intakte pdf datei und schiebe sie mit wput auf meinen server. dort angekommen ist sie kaputt, trotzdem die korrekte größe angezeigt wird und sie auch heruntergeladen werden kann. ist nun schon einige male vorgekommen. als wput option nutze ich --tries=10 und --reupload (ggf. sinngemäß) - --binary ? - mehr versuche? - andere option? ciao gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Info: skobbler-Update mit OSM ist live
Am 5. März 2010 09:45 schrieb Oliver Kuehn (skobbler) osm.oliver.ku...@gmx.de: Probleme gibt es unter Umständen auch noch in der Advisordarstellung, wenn an einer T-Kreuzung Abbiegespuren eingezeichnet wurden, dann wird anstatt einer T-Kreuzung erstmal eine V-Kreuzung dargstellt. Hier ist ein Beispiel, wo die Husarenstraße zum Linksabbiegen auf die Graurheindorferstraße trifft: http://www.openstreetmap.org/?lat=50.747584lon=7.094348zoom=18layers=B000FTF. Da könnte man doch analog zu highway=service, service=parking_aisle einfach service=korrekte engl. Bezeichnung taggen. Damit könnte die routing-engine diese Stückchen erkennen und eventuell auch bevorzugen, da die Ampelanlage umgangen werden kann. Würde euch das helfen? Jochen Topf wird heute auf der FOSSGIS einen neuen Routing-Layer im OSM-Inspektor vorstellen, der von uns gesponsored wurde. Dieser zeigt Probleme von potentiell nicht verbundenen Wegen sowie redundant übereinander liegenden Wegen auf, die zu Problemen beim Routing führen. Cool! Wann ist eigentlich mit einer Version für Android zu rechnen? Viel Erfolg! Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Info: skobbler-Update mit OSM ist live
Moin, Am 05.03.2010 09:45, schrieb Oliver Kuehn (skobbler): Jochen Topf wird heute auf der FOSSGIS einen neuen Routing-Layer im OSM-Inspektor vorstellen, der von uns gesponsored wurde. Dieser zeigt Probleme von potentiell nicht verbundenen Wegen sowie redundant übereinander liegenden Wegen auf, die zu Problemen beim Routing führen. Schickes Ding, danke dafür! Ich denke, das kann sehr nützlich sein. Ich hab gerade gesehen, dass es relativ viele false positives gibt (up to 5m distance to highway=blubb). Gibt es ein Tag, um der Auswertung mitzuteilen, dass man sich das Problem angesehen hat und das aber tatsächlich so korrekt ist, wie es schon in OSM steht? Das würde sehr dabei helfen, den bestehenden Fehler abzuarbeiten, weil man nicht ständig durch unechte Fehler abgelenkt wird. Gruß, olvagor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Info: skobbler-Update mit OSM ist live
Probleme gibt es unter Umständen auch noch in der Advisordarstellung, wenn an einer T-Kreuzung Abbiegespuren eingezeichnet wurden, dann wird anstatt einer T-Kreuzung erstmal eine V-Kreuzung dargstellt. Hier ist ein Beispiel, wo die Husarenstraße zum Linksabbiegen auf die Graurheindorferstraße trifft: http://www.openstreetmap.org/?lat=50.747584lon=7.094348zoom=18layers=B000FTF. Da könnte man doch analog zu highway=service, service=parking_aisle einfach service=korrekte engl. Bezeichnung taggen. Damit könnte die routing-engine diese Stückchen erkennen und eventuell auch bevorzugen, da die Ampelanlage umgangen werden kann. Würde euch das helfen? Ich muß mal intern diskutieren, ob es wirklich hilft, wenn man es als Abbiegespur (turning lane) kennzeichnet. Man muß ja unterscheiden, ob es eine physische Abbiegespur ist (wie beim Rechtsabbiegen von der Husarenstraße in die Graurheindorfer Straße, oder ob es sich um eine virtuelle Spur handelt, die nur behelfsmäßig in die eigentliche Strasse eingezeichnet wird (wie beim Linksabbiegen). Die kommerziellen Kartenanbieter kennzeichnen mit einer Relation den inner_crossing-Bereich, der zum Routing genutzt, aber nicht gerendered werden sollen. Wann ist eigentlich mit einer Version für Android zu rechnen? Mai ist ein realistisches Datum. Viel Erfolg! Vielen Dank. Ich habe aus der Technik die Indikation bekommen, dass gestern etwa 1.000 Bugs über unseren Rückkanal gemeldet worden sind. Eine Statistik und ein Beurteilung der Qualität der Meldungen steht allerdings noch aus. -- View this message in context: http://n2.nabble.com/Info-skobbler-Update-mit-OSM-ist-live-tp4679680p4680020.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Info: skobbler-Update mit OSM ist live
On Fri, Mar 05, 2010 at 10:50:46AM +0100, olvagor wrote: Am 05.03.2010 09:45, schrieb Oliver Kuehn (skobbler): Jochen Topf wird heute auf der FOSSGIS einen neuen Routing-Layer im OSM-Inspektor vorstellen, der von uns gesponsored wurde. Dieser zeigt Probleme von potentiell nicht verbundenen Wegen sowie redundant übereinander liegenden Wegen auf, die zu Problemen beim Routing führen. Schickes Ding, danke dafür! Ich denke, das kann sehr nützlich sein. Ich hab gerade gesehen, dass es relativ viele false positives gibt (up to 5m distance to highway=blubb). Gibt es ein Tag, um der Auswertung mitzuteilen, dass man sich das Problem angesehen hat und das aber tatsächlich so korrekt ist, wie es schon in OSM steht? Das würde sehr dabei helfen, den bestehenden Fehler abzuarbeiten, weil man nicht ständig durch unechte Fehler abgelenkt wird. Bisher gibt es das leider nicht. Wir werden heute nachmittag hier auf der Konferenz noch eine Session haben, wo wir solche Dinge besprechen wollen. Vielleicht haben wir da ja eine Idee. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] problem mit wput
nimm mal binary. kenn ich noch vom guten alten ftp. bedeutet eigentlich: kopiere das file genau so rüber ohne auch nur ein bit zu ändern gruss wambacher, der sich jetzt zur kaffeemaschine kopiert ;-) - Der Fehler tritt nicht sporadisch sondern nur ab und zu auf - Fehlermeldung eines DAUS -- View this message in context: http://n2.nabble.com/problem-mit-wput-tp4679839p4680241.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Info: skobbler-Update mit OSM ist live
Am 5. März 2010 10:38 schrieb Martin Simon grenzde...@gmail.com: Am 5. März 2010 09:45 schrieb Oliver Kuehn (skobbler) osm.oliver.ku...@gmx.de: Probleme gibt es unter Umständen auch noch in der Advisordarstellung, wenn an einer T-Kreuzung Abbiegespuren eingezeichnet wurden, dann wird anstatt einer T-Kreuzung erstmal eine V-Kreuzung dargstellt. Hier ist ein Beispiel, wo die Husarenstraße zum Linksabbiegen auf die Graurheindorferstraße trifft: http://www.openstreetmap.org/?lat=50.747584lon=7.094348zoom=18layers=B000FTF. Da könnte man doch analog zu highway=service, service=parking_aisle einfach service=korrekte engl. Bezeichnung taggen. Damit könnte die routing-engine diese Stückchen erkennen und eventuell auch bevorzugen, da die Ampelanlage umgangen werden kann. soweit ich das verstanden habe geht es um die Anzeige der Kreuzungsart im OSMInspector (in einem noch ganz neuen Layer). Dafür wollen wir doch nicht allen Ernstes die Daten verbiegen? Service ist so ein Stück m.E. in den seltensten Fällen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation so korrekt erstellt ? (Besonders osmc:symbol)
Hallo, habe nach einer existierenden Rel. gesucht, keine gefunden, so habe ich diese erstellt 442671 Im Nachhinen bin ich mir nicht sicher ob ich besonders die Zeile osmc:symbol richtig gemacht habe. osmc:name Pfälzerwald Wanderweg Grün-Gelbes Kreuz (Oberbexbach - Ludwigshafen a. Rhein)osmc:symbol green:yellow:green_bar_verticalroute hikingsymbol weißer Hintergrund, gelber waagrechter Balken in der Mitte, grüner senkrechter Balken in der Mittetype route Das Kreuz ist Grün-Gelb. Im Beispiel: http://www.kaisersnetz.de/PWV-Hassloch/mar1.html Übrigens, wie finde ich zuverlässig bereits existierende Relationen? Unter http://wiki.openstreetmap.org/wiki/Relation_listssind sie zwar, doch fehlen zu den meisten Beschreibungen. -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Micro-Mapping
Bevor ich Vermessungswerkzeuge heraushole, was kann ich noch tun? Ich gehe wenn moeglich einen Track immer auch der rechten Strassenseite und zwar hin und zurueck. Daraus ergibt sich ein Schlauch, in dessen Mitte die Nodes kommen. Dadurch werden sehr viele Stoerungen durch Reflektionen etc. direkt sichtbar. Es koennte aber auch interessant sein, OSM dann an anderer Stelle zu helfen. Z.B. mit keepright und anderen Tools schauen, ob man Fehler beheben kann. Sonst hast Du in Deiner Region jeden Papierkorb, aber Strassen ohne Namen, Fluesse durch Gleise... Gruesse, -- Jonas Stein n...@jonasstein.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Linienbündel / Kreuzungsmapping (was : skobbler-Update mit OSM ist live)
Da könnte man doch analog zu highway=service, service=parking_aisle einfach service=korrekte engl. Bezeichnung taggen. Damit könnte die routing-engine diese Stückchen erkennen und eventuell auch bevorzugen, da die Ampelanlage umgangen werden kann. soweit ich das verstanden habe geht es um die Anzeige der Kreuzungsart im OSMInspector (in einem noch ganz neuen Layer). Dafür wollen wir doch nicht allen Ernstes die Daten verbiegen? Service ist so ein Stück m.E. in den seltensten Fällen. Das ist leider die bekannte Linienbündel-Diskussion. Bei OSM werden tendenziell lieber einfzelne Fahr/Abbiegespuren als getrennte Wege gemapt. Diese dann zusammenzufassen, damit man weiss, wo ein Spurwechsel möglich ist und wo eine rechtliche/bauliche Trennung besteht (durchgezogene Linien, Reiter/Leitplanke), das müsste eine Relation leisten. Nur bekommt man dann Karten, die noch weniger mit Potlach editierbar sind. Kaiserlei-Kreis in Offenbach ist so ein Fall, bei dem man es auf die Spitze treiben könnte, was Fahrspuren versus baulich getrennte Wege anbelangt: http://osm.org/go/0D0aLbRnA-- Der derzeitige Status zeigt noch nichtmal ansatzweise, wie komplex dieser Kreisverkehr ist... Skobbler täte natürlich trotzdem gut daran, nicht nur die jeweils nächste, sondern auch die übernächste Aktion anzusagen. An besagter Einmündung mit vorheriger Teilung wäre jetzt schon möglich In 200m rechts halten (Abbiegewinkel 60 Grad) und dann sofort (nächste Aktion 50m) rechts abbiegen auf die L08/15. Und dass dieser Weg benutzt wird ist auch ohne spezielles Tagging (service- link oder turn-restriction an der links/geradaus-Spur) klar, denn der Weg rechts ab ist ganz einfach kürzer... -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation so korrekt erstellt ? (Besonders osmc:symbol)
fudde...@freenet.de schrieb: Hallo, habe nach einer existierenden Rel. gesucht, keine gefunden, so habe ich diese erstellt 442671 Im Nachhinen bin ich mir nicht sicher ob ich besonders die Zeile osmc:symbol richtig gemacht habe. osmc:name Pfälzerwald Wanderweg Grün-Gelbes Kreuz (Oberbexbach - Ludwigshafen a. Rhein)osmc:symbol green:yellow:green_bar_verticalroute hikingsymbol weißer Hintergrund, gelber waagrechter Balken in der Mitte, grüner senkrechter Balken in der Mittetype route Also eigentlich gehen nur die Symbole, die hier http://topo.geofabrik.de/symbols_de.html aufgelistet sind. Da musst du dich wohl für einen Kompromiss in grün-gelb entscheiden... Das Ergebins siehst du aber im Laufe des abends noch in lonvias hiking map. Das Kreuz ist Grün-Gelb. Im Beispiel: http://www.kaisersnetz.de/PWV-Hassloch/mar1.html Übrigens, wie finde ich zuverlässig bereits existierende Relationen? Unter http://wiki.openstreetmap.org/wiki/Relation_listssind sie zwar, doch fehlen zu den meisten Beschreibungen. Am besten mit dem routes-plugin von josm den fraglichen Bereich runterladen, oder in lonvias hiking map reinzoomen und nachschauen ;-) Wobei du mit josm mehr erreichst, wenn die Relation falsch getaggt ist. Im Relationsfenster tauchen die trotzdem auf. Dein name-tag ist ein wenig überlang. Da hätte Grün-Gelb Pfälzerwald eventuell gereicht. Der Name wird von einigen Renderen an den Weg geschrieben, deshalb sollte der kurz sein. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel / Kreuzungsmapping (was : skobbler-Update mit OSM ist live)
Am 5. März 2010 14:30 schrieb Johann H. Addicks addi...@gmx.net: Service ist so ein Stück m.E. in den seltensten Fällen. Das ist leider die bekannte Linienbündel-Diskussion. nö, es geht hier um die Frage, ob eine Abbiegespur mit Service getaggt werden sollte. M.E. nicht. Gruß Martin PS: Abbiegespuren sind häufig baulich getrennt, oft durch Fußgängerinseln. Diese könnte man evtl. verkehrwiderrechtlich bzw. mit Sonderrechten auch mit dem Auto überqueren, sofern keine Leitplanken, Stahlrohrrahmen o.ä. dem entgegenstehen, und dafür bräuchte man dann eine Relation. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Übersicht der gemeldeteten Bugs von skob bler-Nutzern (was: skobbler-Update mit OSM ist live)
Hallo, hier ist noch mal ein Link, wo man (ungefiltert) die gemeldeten Bugs über den skobbler-Rückkanal einsehen kann: http://beta.skobbler.de/osmbugs Sobald wir sicherstellen können, dass wir die relevanten und richtigen Fehler herausfiltern können, werden wir diese direkt an OpenStreetBugs weiterleiten. Gruß Oliver -- View this message in context: http://n2.nabble.com/Info-skobbler-Update-mit-OSM-ist-live-tp4679680p4681110.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von skob bler-Nutzern (was: skobbler-Update mit OSM ist live )
Wenn die dann auch einer abarbeitet ... Am 5. März 2010 15:28 schrieb Oliver Kuehn (skobbler) osm.oliver.ku...@gmx.de: Hallo, hier ist noch mal ein Link, wo man (ungefiltert) die gemeldeten Bugs über den skobbler-Rückkanal einsehen kann: http://beta.skobbler.de/osmbugs Sobald wir sicherstellen können, dass wir die relevanten und richtigen Fehler herausfiltern können, werden wir diese direkt an OpenStreetBugs weiterleiten. Gruß Oliver -- View this message in context: http://n2.nabble.com/Info-skobbler-Update-mit-OSM-ist-live-tp4679680p4681110.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Wikipedia -- http://tools.wikimedia.de/~flacus/IWLC/ OSM -- http://osm.flacus.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von skob bler-Nutzern
Hallo, Oliver Kuehn (skobbler) schrieb: hier ist noch mal ein Link, wo man (ungefiltert) die gemeldeten Bugs über den skobbler-Rückkanal einsehen kann: http://beta.skobbler.de/osmbugs Ich habe mir mal exemplarisch ein paar Meldungen in meiner Gegend angesehen. Ist es evtl. möglich, auch die Aktion, die Aulöser für die Meldung ist, mit auszugeben? Es ist schwierig, etwas zu verbessern, wenn nur da steht: Der vorgeschlagene Abbiegevorgang ist nicht zulässig. Da weiß ich ja nicht, was vorgeschlagen wurde. noch schwieriger wird es hier: Die vorgeschlagene Route ist offensichtlich nicht optimal. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von skob bler-Nutzern
Am 05.03.2010 15:28, schrieb Oliver Kuehn (skobbler): hier ist noch mal ein Link, wo man (ungefiltert) die gemeldeten Bugs über den skobbler-Rückkanal einsehen kann: http://beta.skobbler.de/osmbugs Sobald wir sicherstellen können, dass wir die relevanten und richtigen Fehler herausfiltern können, werden wir diese direkt an OpenStreetBugs weiterleiten. Habt ihr eigentlich mehr Informationen über die Bugs, als ihr anzeigt? Ich kann mir kaum vorstellen, was ihr mit sowas anfangen könnt: Die vorgeschlagene Route ist offensichtlich nicht optimal Gruß, olvagor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von sk obbler-Nutzern
Am 05.03.2010 um 15:41 schrieb Stefan Dettenhofer (StefanDausR): Hallo, Oliver Kuehn (skobbler) schrieb: hier ist noch mal ein Link, wo man (ungefiltert) die gemeldeten Bugs über den skobbler-Rückkanal einsehen kann: http://beta.skobbler.de/osmbugs Ich habe mir mal exemplarisch ein paar Meldungen in meiner Gegend angesehen. Ist es evtl. möglich, auch die Aktion, die Aulöser für die Meldung ist, mit auszugeben? Es ist schwierig, etwas zu verbessern, wenn nur da steht: Der vorgeschlagene Abbiegevorgang ist nicht zulässig. Da weiß ich ja nicht, was vorgeschlagen wurde. noch schwieriger wird es hier: Die vorgeschlagene Route ist offensichtlich nicht optimal. Wenn man das Skobbler Interface kennt, versteht man das etwas besser: http://twitpic.com/16qthy Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von skob bler-Nutzern
Am 05.03.2010 15:48, schrieb olvagor: Habt ihr eigentlich mehr Informationen über die Bugs, als ihr anzeigt? Ich kann mir kaum vorstellen, was ihr mit sowas anfangen könnt: Die vorgeschlagene Route ist offensichtlich nicht optimal Stefan hatte die gleiche Idee :-) Ignoriert diese Mail. Gruß, olvagor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von skob bler-Nutzern
hier ist noch mal ein Link, wo man (ungefiltert) die gemeldeten Bugs über den skobbler-Rückkanal einsehen kann: http://beta.skobbler.de/osmbugs Ich habe mir mal exemplarisch ein paar Meldungen in meiner Gegend angesehen. Ist es evtl. möglich, auch die Aktion, die Aulöser für die Meldung ist, mit auszugeben? Es ist schwierig, etwas zu verbessern, wenn nur da steht: Der vorgeschlagene Abbiegevorgang ist nicht zulässig. Da weiß ich ja nicht, was vorgeschlagen wurde. Das ist uns bewußt. Deshalb ballern wir das Feedback auch nicht einfach direkt in OpenStreetBugs rein. In der nächsten Version werden wir zusätzliche Informationen über einen Link mitliefern: die letzen x Meter der gefahrenen Route vor der Meldung des Fehlers sowie die dazugehörige Fahranweisung, und wenn es möglich ist, auch einen Ausschnitt aus der jeweils geplanten Route. Letzteres ist aber noch unklar, ob es direkt in der nächsten Version kommt. Wir wollen das Rückkanal-Element über mehrere Iterationen verbesseren. Gruß Oliver -- View this message in context: http://n2.nabble.com/Info-skobbler-Update-mit-OSM-ist-live-tp4679680p4681256.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von sk obbler-Nutzern
hier ist noch mal ein Link, wo man (ungefiltert) die gemeldeten Bugs über den skobbler-Rückkanal einsehen kann: http://beta.skobbler.de/osmbugs Nachdem ich die ersten 5 Meldungen von dort bearbeitet habe: zwei Wünsche a) für jeden Bug eine eindeutige ID, damit man ggf. im Josm-Uploadkommentar drauf verweisen kann b) Bugs verschieben? Es kommt wohl immer die Koordinate an der der User die Taste drückt. Wenn er das erst später tut, dann sucht man ziemlich bzw es ist zwecklos, wenn der Kommentar nicht genügend hergibt. Aber wenn man es dann findet und nicht gleich schließen kann wg. Uneindeutigkeit, dann sollen zumindest andere nicht auch noch die gleiche Sucharbeit haben. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von sk obbler-Nutzern
Die vorgeschlagene Route ist offensichtlich nicht optimal. Solche habe ich auch einige... kann man eigentlich nur als unglöst geschlosssen bezeichnet. Gibt's aber nicht. also erledigt. Wenn es zu dem Fehler vielleicht noch GPX-Track von 60s davor und 30s danach geben würde, das wäre ideal. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gem eldeteten Bugs von s kobbler-Nutzern
Am 05.03.2010 15:28, schrieb Oliver Kuehn (skobbler): hier ist noch mal ein Link, wo man (ungefiltert) die gemeldeten Bugs ?ber den skobbler-R?ckkanal einsehen kann: http://beta.skobbler.de/osmbugs Sobald wir sicherstellen k?nnen, dass wir die relevanten und richtigen Fehler herausfiltern k?nnen, werden wir diese direkt an OpenStreetBugs weiterleiten. Habt ihr eigentlich mehr Informationen ?ber die Bugs, als ihr anzeigt? Ich kann mir kaum vorstellen, was ihr mit sowas anfangen k?nnt: Die vorgeschlagene Route ist offensichtlich nicht optimal ich hab in meiner gegend auch mal drüber geschaut. nur ganz wenige user geben hilfreiche kommentare mit wie: Beschreibung: Friedrich-Naumann-Str führt als einbahnstr auf die braunfelsstraße zu nicht auf die funkstr man fährt über die funkstr in die Friedrich Naumann Str rein [skobbler, 05.03.2010 00:02] und wenig überraschend sind fast alles falsche abbiegeanweisungen, die von der fehlenden unterstützung für abbiege-relationen verursacht werden. Solche Fehler kann man eigentlich gleich wieder löschen und erst wieder neu erfassen, wenn die engine das bestehende Datenmaterial auch richtig interpretiert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von sk obbler-Nutzern
Am Freitag 05 März 2010 15:49:16 schrieb Jonas Krückel: Die vorgeschlagene Route ist offensichtlich nicht optimal. Wenn man das Skobbler Interface kennt, versteht man das etwas besser: http://twitpic.com/16qthy Keineswegs. Der User muss ja nichts zusätzliches eingeben oder machen, Skobbler sollte einfach den betreffenden Abschnitt irgendwie mitprotokollieren, so dass klar ist, *welche* route nicht optimal ist. So Dinge wie: Route von A nach B über L123, K567, B23, L123 Und die Kunst für den Programmierer wäre dann, die Liste so zu kürzen, dass weiterhin klar bleibt, wie die Route lief ohne dass jeder OSM-Way dort eingetragen werden muss. ;-) Gruß, Bernd -- Jedes gelöste Problem ist einfach. - Thomas Alva Edison signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation so korrekt erstellt ? (Besonders osmc:symbol)
Hi! Andre Joost wrote: Also eigentlich gehen nur die Symbole, die hier http://topo.geofabrik.de/symbols_de.html aufgelistet sind. Da musst du dich wohl für einen Kompromiss in grün-gelb entscheiden... Das Ergebins siehst du aber im Laufe des abends noch in lonvias hiking map. Richtig. Momentan kannst du ein mehrfarbiges Kreuz nicht exakt darstellen. Aber vielleicht wird es da mal Zeit für eine Erweiterung. In der Lonvia-Karte siehtst Du allerdings nur dann etwas, wenn Dein Weg der einzige auf dem Wegstück ist - wenn da noch andere verlaufen, dann siehst Du evtl. auch gar nix davon. Übrigens, wie finde ich zuverlässig bereits existierende Relationen? Wenn es um Wanderwege geht und nicht um andere Relationen, gibt es hier noch aufbereitete Listen: http://topo.geofabrik.de/route_list_germany.html http://topo.geofabrik.de/Wanderwegverzeichnis.html http://topo.geofabrik.de/Relationsprobleme.html Dein name-tag ist ein wenig überlang. Da hätte Grün-Gelb Pfälzerwald eventuell gereicht. Der Name wird von einigen Renderen an den Weg geschrieben, deshalb sollte der kurz sein. Der Name ist in der Tat etwas lang. Ich würde aber eher Wanderweg Oberbexbach - Ludwigshafen a. Rhein vorschlagen. Die Markierung gehört in die Tags symbol und osmc:symbol und muß im Namen nicht ein drittes mal wiederholt werden. bye Nop -- View this message in context: http://n2.nabble.com/Relation-so-korrekt-erstellt-Besonders-osmc-symbol-tp4680616p4681465.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel / Kreuzungsmapping (was : skobbler-Update mit OSM ist live)
On Fri, Mar 05, 2010 at 03:21:23PM +0100, Martin Koppenhoefer wrote: Am 5. März 2010 14:30 schrieb Johann H. Addicks addi...@gmx.net: Service ist so ein Stück m.E. in den seltensten Fällen. Das ist leider die bekannte Linienbündel-Diskussion. nö, es geht hier um die Frage, ob eine Abbiegespur mit Service getaggt werden sollte. M.E. nicht. doch, natuerlich gehoert das dazu... aber um zur urspruenglichen frage zu kommen: sinnvollerweise duerfte man hier nicht das highway-tag verwenden, sondern muesste ein zusatzattribut vergeben. denn meist ist die abbiegespur teil einer bereits als highway=... getaggten strasse. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von sk obbler-Nutzern
Am 05.03.2010 um 16:32 schrieb Bernd Wurst: Am Freitag 05 März 2010 15:49:16 schrieb Jonas Krückel: Die vorgeschlagene Route ist offensichtlich nicht optimal. Wenn man das Skobbler Interface kennt, versteht man das etwas besser: http://twitpic.com/16qthy Keineswegs. Der User muss ja nichts zusätzliches eingeben oder machen, Skobbler sollte einfach den betreffenden Abschnitt irgendwie mitprotokollieren, so dass klar ist, *welche* route nicht optimal ist. So Dinge wie: Route von A nach B über L123, K567, B23, L123 Ja, wollen sie ja in Zukunft auch machen. Mir ging es mehr allgemein darum, dass man auch sehen kann, wie die Nutzer von Skobbler das zu Gesicht bekommen und wie solche Meldungen dann entstehen. Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wildwechsel
Hallo! Ich wollte einige Wegabschnitte mit Wildwechsel markieren, habe aber dazu keinen Tag gefunden. Im Wiki habe ich nur [1] gefunden, was ja auch noch nicht so richtig ausgereift ist. Bei tagwatch und tagstat bin ich auch nicht richtig fündig geworden. Ich kann mir eigentlich nicht vorstellen, daß bisher niemand Warnungen vor Wildwechsel erfaßt hat. Christian [1] http://wiki.openstreetmap.org/wiki/Proposed_features/hazard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel / Kreuzungsmapping (was : skobbler-Update mit OSM ist live)
PS: Abbiegespuren sind häufig baulich getrennt, oft durch Fußgängerinseln. Diese könnte man evtl. verkehrwiderrechtlich bzw. mit Sonderrechten auch mit dem Auto überqueren, sofern keine Leitplanken, Stahlrohrrahmen o.ä. dem entgegenstehen, und dafür bräuchte man dann eine Relation. Wie will man denn allen Ausnahmen von der Regel gerecht werden? Klar kann man dafür wieder irgendeine Realation neben der Relation in der Relation machen. Nur wer setzt das letztendlich tatsächlich um und vor allem wer will das Pflegen? Das Strippenmodell ist für genaues mappen einfach zu dünn. Das reicht für simple Fälle wie Straße von A nach B, versagt aber schon bei so einfachen Fällen wie 2:1 oder einseitige Überholverbote etc. Und wenn es ganz kompliziert wird gehts rätseln los. Aber wenn ich wirklich das umsetzen will was ich sehe, muss ich das auch so beschreiben und darstellen können. Das passt so irgendwie nicht. Auf der einen Seite hätte man am liebesten jegliche Möglichkeit abgedeckt, hat dafür aber nur den Minimalkonses an Darstellungsmöglichkeit. Hier mal so ein ganz simples Ding. http://osm.org/go/0MEAePiSJ Landstraße kann du gerade und links weg, rechts grüne Pfeil Spur mit Zebra. Das gleiche nochmal mit der Bundesstraße von Süden her. Da hast du dann die Wahl es entweder ganz einfach zu halten und ein Kreuz zu machen, unterschlägst aber damit wieder Geografische Informationen und solche wie beispielsweise grüner Pfeil. Oder man macht so eine Krücke wie es jetzt ist. Beides nicht gerade Prall. Wie macht man es nun richtig? Im Anhang mal ein Skizze der eigentlich simplen Situation. Kannst ja mal einen Vorschlag machen der Darstellbar ist, geroutet werden kann, einer Geodatenbank würdig ist und solche extra Bratwürste wie Rettung berücksichtigt. Gruß Mirko attachment: kreuzung.jpg___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wildwechsel
Am 5. März 2010 17:06 schrieb Christian H. Bruhn br...@arcor.de: Hallo! Ich wollte einige Wegabschnitte mit Wildwechsel markieren, habe aber dazu keinen Tag gefunden. Es gibt noch: http://wiki.openstreetmap.org/wiki/Key:traffic_sign Aber Du willst ja vermutlich die Strecke auf der das Schild warnt kennzeichnen und nicht das Schild an sich eintragen? Ob man das Tag auch an ways oder nur als node verwenden kann/soll weiß ich nicht. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Info: skobbler-Update mit OSM ist live
Am 5. März 2010 13:49 schrieb Martin Koppenhoefer dieterdre...@gmail.com: soweit ich das verstanden habe geht es um die Anzeige der Kreuzungsart im OSMInspector (in einem noch ganz neuen Layer). Dafür wollen wir doch nicht allen Ernstes die Daten verbiegen? Service ist so ein Stück m.E. in den seltensten Fällen. Nein, natürlich nicht. Es ist nur die frage, ob man service=* als genauere Definition von highway=service ansieht oder als welchen Zweck erfüllt diese Straße?. ein primary=*, secondary=*, tert... etc wäre nicht gerade elegant... Und so wie ich es verstanden habe, ging es um die Darstellung der Kreuzungsart in skobbler... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Skobbler-Bugs: Kreisverkehre
Die Skobbler-Engine (egal welcher Part) scheint sich schwer zu tun (oder zumindest die Nutzer zu verwirren), wenn es über komplexe Kreisverkehre geht. Also solche, die eben nicht nur als simpler Kreisverkehr gemapt sind, sondern aus mehr als nur einem Way-Polygon bestehen. Dann -so scheint es mir- erkennt Skobbler das nicht als Kreisverkehr und gibt verwirrende Abbiegeanweisungen, so als ob es sich um normale (enge) Straßenkreuzungen handeln würde. Zumindest deuten die vielen Bugmeldungen an Kreisverkehren darauf hin. Entweder lernt die Engine diese Kreisverkehre trotzdem fuzzy zu erkennen. Oder wir denken uns eine Kreisverkehrs-Relation aus, damit die Ansagen 6. Ausfahrt berechnet werden können ohne Fuzzy-Technik. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel / Kreuzungsmapping (was : skobbler-Update mit OSM ist live)
Am 5. März 2010 16:37 schrieb Guenther Meyer d@sordidmusic.com: On Fri, Mar 05, 2010 at 03:21:23PM +0100, Martin Koppenhoefer wrote: Am 5. März 2010 14:30 schrieb Johann H. Addicks addi...@gmx.net: Service ist so ein Stück m.E. in den seltensten Fällen. Das ist leider die bekannte Linienbündel-Diskussion. nö, es geht hier um die Frage, ob eine Abbiegespur mit Service getaggt werden sollte. M.E. nicht. doch, natuerlich gehoert das dazu... aber um zur urspruenglichen frage zu kommen: sinnvollerweise duerfte man hier nicht das highway-tag verwenden, sondern muesste ein zusatzattribut vergeben. denn meist ist die abbiegespur teil einer bereits als highway=... getaggten strasse. Ja, und genau darum ging es mir (mittels service=*), nicht wie Martin annahm darum, diese Straßen zu highway=service umzutaggen... Dasselbe gibt es auch schon bei railway=* [1] und das ist von highway=service recht weit entfernt... ;-) Gruß, Martin [1]http://wiki.openstreetmap.org/wiki/Tag:service%3Dspur ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wildwechsel
Ich wollte einige Wegabschnitte mit Wildwechsel markieren, habe aber highway=path maxheight=1 Oder in der Langform: Als Wanderer erkennst Du, dass Du (versehtlich) auf einem Wildwechsel unterwegs bist spätestens dann, wenn immer mehr Zweige und Bäume auf Bauchhöhe im Weg sind, der Trampelpfad aber immernoch gut zu erkennen ist. Was nicht heisst, dass auch das Wild das bestehende menschliche Wegenetz gern annimmt, wenn's nicht gleich eine Forstautobahn ist. Die Wutze wollen schließlich auch bequem vorwärtskommen. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler-Bugs: Kreisverkehre
Hallo Johann, Entweder lernt die Engine diese Kreisverkehre trotzdem fuzzy zu erkennen. Oder wir denken uns eine Kreisverkehrs-Relation aus, damit die Ansagen 6. Ausfahrt berechnet werden können ohne Fuzzy-Technik. Es gibt in Deutschland 10 Relationen mit type = route route = junction junction = roundabout http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de/8b1f387493350a9e.html und 9 Relationen mit type = junction junction = roundabout http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de/90c6f102232ced0b.html Wobei mir persönlich ersteres besser gefällt, aber beides sollte für Skobbler relativ einfach umsetzbar sein.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von skob bler-Nutzern (was: skobbler-Update mit OSM ist live)
Am Freitag 05 März 2010 15:28:33 schrieb Oliver Kuehn (skobbler): hier ist noch mal ein Link, wo man (ungefiltert) die gemeldeten Bugs über den skobbler-Rückkanal einsehen kann: http://beta.skobbler.de/osmbugs Danke, habe gleich mal ein paar davon abgearbeitet. Die meisten kann man ja auch ohne Ortskenntnis beheben. Oder könnte, siehe unten. Sobald wir sicherstellen können, dass wir die relevanten und richtigen Fehler herausfiltern können, werden wir diese direkt an OpenStreetBugs weiterleiten. Ich finde wichtige Änderungen die man vorher noch machen sollte wären: - Beim Einbahnstraßenproblem sollte die Himmelsrichtung angegeben werden, in die der User dirigiert worden ist. Man kann zwar oft mit einem Vergleich mehrerer Drittquellen ziemlich sicher herausfinden, wie rum die Einbahnstraße geht, aber die Infos liegen Skobbler ja eigentlich direkt schon vor. - Selbiges gilt auch bei Hier geht es nicht mehr weiter. Skobbler hat ja schon die Info, wie der User denn fahren sollte und sogar bis wo er gefahren ist. Das geht aus den aktuellen bugreports so noch nicht hervor. - Bei Straße ist nicht in der Karte oder bei falschem Straßennamen könnte man dem User noch ein Eingabefeld für den richtigen/fehlenden Straßennamen bieten. - Bei allerlei Problemen mit existierenden Straßen könne man direkt eine Liste der möglicherweise gemeinten Straßen anzeigen, die der User dann einfach auswählt um seine Angabe zu konkretisieren. Selbiges bei Kreisverkehren. Aber generell ist das der richtige Weg! Ich selbst habe einen RSS-Feed für meine lokale Umgebung bei OpenStreetBugs und kann so immer wenn ich Zeit und Lust habe die neuen Fehler gleich beheben. Gruß, Bernd -- Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr. - Albert Einstein signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler-Bugs: Kreisverkehre
Am Freitag 05 März 2010 17:43:00 schrieb Johann H. Addicks: Entweder lernt die Engine diese Kreisverkehre trotzdem fuzzy zu erkennen. Es sollte eine lösbare Aufgabe sein, im Preprocessing Kreisverkehre zu vereinheitlichen. Meist wurden die Kreisverkehre ja aufgetrennt weil sich z.B. Relation-Checker gerne mal über nicht verbundene Relationen beschweren. Wenn man also jeden Kreisverkehr, der kein Kreis ist (Anfang != Ende) einfach so lange mit direkt am Anfang oder Ende zusammen hängenden weiteren Kreisverkehren vereint, sollte man nach einigen Schritten einen Kreis erhalten. Der Preprocessor sollte dann selbst einen Bugreport generieren wenn diese Logik nicht zum Erfolg führt. Gruß, Bernd -- Das Usenet ist prinzipiell ein recht lustiger Haufen, machmal ein lustiger Haufen kleinkarierter, besserwissender und arroganter Arschlöcher aber doch immer irgendwie lustig. - Oliver C. Thornton, de.rec.reisen.misc, 26.7.2003 signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wildwechsel
Am 5. März 2010 17:48 schrieb Johann H. Addicks addi...@gmx.net: Ich wollte einige Wegabschnitte mit Wildwechsel markieren, habe aber highway=path maxheight=1 Oder in der Langform: Als Wanderer erkennst Du, dass Du (versehtlich) auf einem Wildwechsel unterwegs bist spätestens dann, wenn immer mehr Zweige und Bäume auf Bauchhöhe im Weg sind, der Trampelpfad aber immernoch gut zu erkennen ist. Dann aber bitteschön mit Zusatzattributen path=wild_boar,roe_deer,red_deer Und eintragen darf das in Abweichung vom OSM-Grundsatz, dass jeder alles darf, nur jemand mit gültigem Jagdschein. Weidmannsheil, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPX-Files bearbeiten
Bartosz Fabianowski schrieb: gpsbabel Wie sieht deine Lösung aus, um mit gpsbabel Punktwolken zu entfernen? Bisher konnte ich keine zufriedenstellenden Resultate erzeugen, weshalb sich die nicht hochgeladenen Logs bei mir megameterweise häufen. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
