Re: [OSM-talk] openstreetbug feature enhancement request
On 4 Dec 2008, at 02:56, maning sambale wrote: Hi, An openstreetbug feature enhancement request (or for future bug tracking tool): Add the data layer (as in the main OSM map) to view the the underlying tags If you want this why not integrate OpenStreetBugs into the the main osm website that already has the data layer? Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Updated view of 'A year of edits on OSM' and also Santa's Routes!
A few weeks ago ITO published a planet view of edits to OpenStreetMap over the past year. http://www.flickr.com/photos/peterito/3054501076/in/pool-itomedia This showed lots of good stuff (and loads of hard work!) but also shows some large scale graffiti which was immediately christened as 'Santa's routes' (see comment on the Flickr page). Some of these routes have now been removed. We have just updated this image to show the current situation which shows what is now left in the dataset and still needs clearing (unless they are ferry routes). Can I suggest that people find them and edit them out if appropriate (this is not easy with big features and the current editors)? Can I also suggest that people make a comment on the Flickr page if they have removed one to avoid duplicate work? We will update this image every few days until they are clear, another good reason to leave a comment if you have removed a trail. It you want to keep up with other images published by ITO then why not subscribe to the 'ItoMedia' pool. Regards, Peter Miller ITO World Ltd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] find corners of exported maps
Hi, I wonder how I compute the coordinates of the corners of the images received from the web export function for an osmarender image. I specify geodetic center position(degrees), zoom level and image size and get at nice map image. The projection is of cource Mercator and I can linearly map mercator coordinates onto the image. But how do I know the coordinates of the corners of the returned image ? The url I use is : http://server.tah.openstreetmap.org/MapOf/index.php?long=10.17456lat=56.01566z=6w=500h=592format=png' The tile-size for each level is 256x256 so given the zoom-level I could compute the pixel density from the world map size in mercator projection. That works for east direction which is linear, but for the northern direction the projection is nonlinear and I am not sure if the geodetic center that I specify is at the center of the returned image or not. cheers Olav perl code for computing the pixel density # $ol = east length of map section # pix,$piy = pixel size of image # find zoom level my $dnmax=85.0511; # max for osmarender my ($momax, $mnmax)=mercate($dnmax, 180); my $zlevel=int( log( 2*$momax / $ol ) / log(2) + 1); # osm zoom # find real size of map my $ompp=2*$momax/(2**$zlevel)/256; # east meters per pixel for this level my $nmpp=2*$mnmax/(2**$zlevel)/256; # north meters per pixel for this level ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Where have all the contributors gone?
however, the recent drop-off in mappers correlates very nicely with the fall in non-business sunshine hours. and is slightly correlated with mean daytime temperature (at least in the UK). If anyone out there who was contributing in the summer and has now stopped could share the reasons I might help shed some light. I haven't actually stopped, it's just slowed down. But I imagine others that could stop temporarily. i've pretty much stopped - the flash on my camera drains the battery too quickly for night-time mapping... What about weekends though? I do almost all my mapping at weekends, even in the summer, and managed to do some mapping on all 10 weekend days in November. :-) Nick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] find corners of exported maps
Olav Kvittem schrieb: Hi, I wonder how I compute the coordinates of the corners of the images received from the web export function for an osmarender image. I specify geodetic center position(degrees), zoom level and image size and get at nice map image. The projection is of cource Mercator and I can linearly map mercator coordinates onto the image. But how do I know the coordinates of the corners of the returned image ? The url I use is : http://server.tah.openstreetmap.org/MapOf/index.php?long=10.17456lat=56.01566z=6w=500h=592format=png' The tile-size for each level is 256x256 so given the zoom-level I could compute the pixel density from the world map size in mercator projection. That works for east direction which is linear, but for the northern direction the projection is nonlinear and I am not sure if the geodetic center that I specify is at the center of the returned image or not. have a look at the debugHelper.pl in [EMAIL PROTECTED] it will give you the latlon center of the tile bbox and the latlon of the center of the tile. -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
On Thu, Dec 4, 2008 at 12:10 AM, Christoph Böhme [EMAIL PROTECTED] wrote: At the moment I am trying to figure out if bug reports reports can be stored directly in the osm database using standard nodes and tags. Please, please don't take or advocate this approach. The OSM core tables should, ideally, contain geo-data. We already anticipate much of the meta-data (e.g. created_by tags, usernames) to be applied to changesets (which are in themselves natively metadata). There's been a long and steady agreement that future bug tracking systems won't just slap nodes into the midst of our geotables. However, this is another subject that needs more doing and less talking :-) Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Andy Allan [EMAIL PROTECTED] schrieb: On Thu, Dec 4, 2008 at 12:10 AM, Christoph Böhme [EMAIL PROTECTED] wrote: At the moment I am trying to figure out if bug reports reports can be stored directly in the osm database using standard nodes and tags. Please, please don't take or advocate this approach. The OSM core tables should, ideally, contain geo-data. We already anticipate much of the meta-data (e.g. created_by tags, usernames) to be applied to changesets (which are in themselves natively metadata). There's been a long and steady agreement that future bug tracking systems won't just slap nodes into the midst of our geotables. I was not aware of this agreement. When I first started thinking about a bug tracker I intended to keep the bug reports in data structures separate from the osm database. But in the following discussions I got the feeling that a bug tracker which allowed free-form tagging would be very welcomed. But implementing this means basically replicating the node-objects (and the way-objects too if you want to mark buggy areas). So, I concluded it would be the easiest to just introduce a new set of tags and manage them differently in the clients. However, I can see why this is not a very clean solution and I am happy to implement in a different dataset. However, this is another subject that needs more doing and less talking :-) I am really eager to start programming something but at the moment I am still trying to figure out what exactly. I do not want to spend time writing a bug tracker that is then rejected because of the way it stores the bug reports. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Updated view of 'A year of edits on OSM' and also Santa's Routes!
Deleted way 27597540 ( http://api.openstreetmap.org/browse/way/27597540/history) http://api.openstreetmap.org/browse/way/27597540/historyincluding 5 nodes, 303045069, 303045070, 303045071, 303045072, 303045073... User 'pefok'...Ran from a lake in Canada into the Atlantic, across South America, out into the Pacific and back again, no objects had any tags even created_by... d 2008/12/4 Peter Miller [EMAIL PROTECTED] A few weeks ago ITO published a planet view of edits to OpenStreetMap over the past year. http://www.flickr.com/photos/peterito/3054501076/in/pool-itomedia This showed lots of good stuff (and loads of hard work!) but also shows some large scale graffiti which was immediately christened as 'Santa's routes' (see comment on the Flickr page). Some of these routes have now been removed. We have just updated this image to show the current situation which shows what is now left in the dataset and still needs clearing (unless they are ferry routes). Can I suggest that people find them and edit them out if appropriate (this is not easy with big features and the current editors)? Can I also suggest that people make a comment on the Flickr page if they have removed one to avoid duplicate work? We will update this image every few days until they are clear, another good reason to leave a comment if you have removed a trail. It you want to keep up with other images published by ITO then why not subscribe to the 'ItoMedia' pool. Regards, Peter Miller ITO World Ltd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Yahoo WMS server?
Hi, is there a stand-alone yahoo WMS server? Yahoos license seem to allow this and some users of my osm2go ask for yahoo images. Going through a wms server would be the easiest and cleanest solution i think. Thanks, Till ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] ERDAS Titan chooses OpenStreetMap as its default basemap
http://erdastitan.blogspot.com/2008/12/erdas-titan-client-932c-released.html Erdas is part of Leica Geosystems. Titan is an infrastructure for sharing geodata, especially targetted for coordination in emergencies. They latest relase of their client has OSM as the default basemap. - OSM is becoming the choice for disaster management. The open source Sahana has supported OSM since Cyclone Nargis earlier this year. http://talksahana.com/2008/06/11/gis-catalog-managing-layers/ -Mikel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Yahoo WMS server?
Hi, Till Harbaum / Lists wrote: is there a stand-alone yahoo WMS server? None that I'm aware of. We're going through a lot of pain with JOSM to display Yahoo background images, and we wouldn't do that if there was a WMS. Yahoos license seem to allow this Tell me more? Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] can your yournavigation support inter-island routing
Is this supported by yournavigation routing? Inter-island routing in areas with route:ferry tag cheers, maning -- |-|--| | __.-._ |Ohhh. Great warrior. Wars not make one great. -Yoda | | '-._7' |Freedom is still the most radical idea of all -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com/ | | _)_/L I http://epsg4253.wordpress.com/ | |-|--| ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] can your yournavigation support inter-island routing
Yes. http://www.yournavigation.org/?flat=52.96331flon=4.76825tlat=53.0023tlon=4.78954v=motorcarfast=1layer=mapnik It's the slowest form of transport : routing bicycle=3 foot=3 goods=3 hgv=3 motorcycle=3 motorcar=3 psv=3/ On Fri, Dec 5, 2008 at 4:41 AM, maning sambale [EMAIL PROTECTED] wrote: Is this supported by yournavigation routing? Inter-island routing in areas with route:ferry tag cheers, maning -- |-|--| | __.-._ |Ohhh. Great warrior. Wars not make one great. -Yoda | | '-._7' |Freedom is still the most radical idea of all -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com/ | | _)_/L I http://epsg4253.wordpress.com/ | |-|--| ___ 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] can your yournavigation support inter-island routing
Ahh! Forgot to check that the routing planet file data was a week old. I added a new route=ferry a couple of days ago. But it works on other places: http://www.yournavigation.org/?flat=9.465166flon=123.223267tlat=9.420631tlon=123.316479v=motorcarfast=1layer=mapnik great work by the way. On Fri, Dec 5, 2008 at 1:14 PM, Nic Roets [EMAIL PROTECTED] wrote: Yes. http://www.yournavigation.org/?flat=52.96331flon=4.76825tlat=53.0023tlon=4.78954v=motorcarfast=1layer=mapnik It's the slowest form of transport : routing bicycle=3 foot=3 goods=3 hgv=3 motorcycle=3 motorcar=3 psv=3/ On Fri, Dec 5, 2008 at 4:41 AM, maning sambale [EMAIL PROTECTED] wrote: Is this supported by yournavigation routing? Inter-island routing in areas with route:ferry tag cheers, maning -- |-|--| | __.-._ |Ohhh. Great warrior. Wars not make one great. -Yoda | | '-._7' |Freedom is still the most radical idea of all -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com/ | | _)_/L I http://epsg4253.wordpress.com/ | |-|--| ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM routing
I want to know if it is possible to have a web based routing solution on OSM data. If so I would appreciate more info on how. Regards Andre ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM routing
Yes there are: 1. http://www.yournavigation.org/ 2. http://www.openrouteservice.org/ (seems to be down currently) For Metro Manila, I think this would be useable for now but not so in other areas of the Philippines: http://lists.openstreetmap.org/pipermail/talk-ph/2008-December/000181.html But, it's just a matter of time. On Fri, Dec 5, 2008 at 2:28 PM, Andre Schoonbee [EMAIL PROTECTED] wrote: I want to know if it is possible to have a web based routing solution on OSM data. If so I would appreciate more info on how. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] End-of-year party
Hey guys, Ik moet verstek laten gaan de 14e. Ik zit voor mijn werk in het buitenland. Veel plezier! En tot gauw Martijn 2008/12/1 Zoran Kovacevic [EMAIL PROTECTED] ik zou zeggen go-go-go en post meteen ff op www.openstreetmap.nl cu On 1 dec 2008, at 12:07, Floris Looijesteijn wrote: Joepie! Ik ben even langs het door mij voorgestelde cafe gelopen (De Vergulde Gaper) en we kunnen daar gewoon een tafel reserveren. Zal ik dat even regelen? Het cafe is op 5 minuten lopen vanaf Amsterdam Centraal Station. De locatie op onze kaart klopt niet helemaal dus die heb ik aangepast... Het is op de hoek van de Prinsenstraat en Prinsengracht. Groet, Floris OSM-vrienden, Het heeft even wat op zich laten wachten, maar heb nu toch even de datum geprikt voor onze end-of-year party. Het is zondag de 14e december geworden. Locatie: Amsterdam. Mocht je je nog niet hebben opgegeven, schroom niet en wees welkom. Houdt de wiki in de gaten voor de laatste ontwikkelingen: http://wiki.openstreetmap.org/wiki/Netherlands_Mapping_Parties_2008#OSM_end-of-year_party_-_Amsterdam Gr, Henk Hoff ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- http://www.kovacevic.nl/blog ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] End-of-year party
Beste Talk'ers, Ik heb op de Software Freedom Day-stek een aankondiging van de End-of-year party geplaatst. -- Met vriendelijke groet, Bas de Lange 06 - 166 26 950 Software Freedom Day Nederland hoofdorganisator http://nl.youtube.com/watch?v=y0_KiVdIOtc Bringing freedom to a street near you! http://www.softwarefreedom.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] Mapnik rendering of AU cities
With the discussion of places, I noticed that on the slippy map with the mapnik renderer, only the names of Sydney and Canberra appear on the 500km and 200km scales. I have looked at the tags for the Sydney, Canberra and Melbourne nodes; and I do not understand why Melbourne is not shown as I do not see any substantial differences in the tags. Wiki says that population can be used for rendering at different zooms, but Melbourne has 10 times the population of Canberra. Ideally, I would like to see names of all the major (state capital) cities in the whole of Australia view. As an aside, in the USA most of the major cities are not state capitals. Does anyone understand why Melbourne is not shown on the whole of Australia view? Regards, Roy Rankin ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Mapnik rendering of AU cities
Roy Rankin wrote: With the discussion of places, I noticed that on the slippy map with the mapnik renderer, only the names of Sydney and Canberra appear on the 500km and 200km scales. Does anyone understand why Melbourne is not shown on the whole of Australia view? Probably cos it's the only way Sydney-siders can make themselves feel superior :-) Matt ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Mapnik rendering of AU cities
I'm not positive, but I think that the very low zoom views don't actually get a lot (any?) of their data from the live OSM data. Rather they do, but they are only updated on very occasionally. There is just too much data to be continually recreating tiles that large from the main database. The coastlines, for example, used to come from shapefiles from another source, because we hadn't done our coasts. They now come mostly from our database, but I think they are still extracted out every so often and turned into shapefiles, not recreated on the fly for low zoom levels. Maybe the cities shown at low zoom levels come from something similar - a list of major cities in each country or something? Sydney and Canberra would be the biggest and the Capitol, so I could see that. Or maybe they haven't updated these zoom levels since Melbourne was added as a node? In any case, ask on the talk list, where somebody who deals with the low zoom levels is likely to see it. Stephen 2008/12/4 Roy Rankin [EMAIL PROTECTED]: With the discussion of places, I noticed that on the slippy map with the mapnik renderer, only the names of Sydney and Canberra appear on the 500km and 200km scales. I have looked at the tags for the Sydney, Canberra and Melbourne nodes; and I do not understand why Melbourne is not shown as I do not see any substantial differences in the tags. Wiki says that population can be used for rendering at different zooms, but Melbourne has 10 times the population of Canberra. Ideally, I would like to see names of all the major (state capital) cities in the whole of Australia view. As an aside, in the USA most of the major cities are not state capitals. Does anyone understand why Melbourne is not shown on the whole of Australia view? Regards, Roy Rankin ___ 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-de] einheitliche Darstellung von Autobahn-Zubringern (einfache Form)
Solange die Fahrbahnen der Auf- bzw. Abfahrt baulich getrennt sind sollten sie als getrennte Wege erfasst werden. Sind sie einen Abschnitt lang nur mit Fahrbahnmarkierung getrennt erfasse ich sie als einen Weg. dem stimme ich voll zu, das entspricht dann auch der realität. Realität ist, dass alle Autobahnfahrspuren als Einbahnstrassen zu werten sind (STVO: Das Wenden auf der Autobahn ist verboten!). Die Autobahn beginnt da, wo die entsprechende Hinweistafel steht - in der Regel unmittelbar nach der letzten Kreuzung an der die Auffahrt beginnt. Darum ist es sinnvoll die Fahspuren grundsätzlich getrennt zu erfassen und als Einbahnstrassen zu taggen um jegliche Fehlinterpretation durch Mensch und Maschine bzgl. der erlaubten Fahrmanöver auszuschliessen. da sind wir halt einfach anderer meinung ;-) ich tagge es halt einfach so wie die starssen gebaut sind, und du wie es für die navis vieleicht einfacher zu handhaben ist. wobei ich der meinung bin wenn ein navi sagt du sollt auf einer einfahrt/ausfahrt wenden, dann ist es schlecht programmiert, und wenn der fahrer das dann auch noch macht, dann sollte er vieleicht nochmal ein paar fahrstunden nehmen ;-) gruesse ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachteil barometrischer Höhenmesser
Hallo Garry, Das hat dann aber nur noch am Rande mit OSM zu tun Oh - ganz im Gegenteil! Bisher reduziert sich OSM ja in der DB auf ein zweidimensionales Modell. Aber der Ruf nach der dritten Dimension wird immer lauter. Entsprechend wichtg ist es, dass wir uns Gedanken zur qualitativen Erfassung der Höhendaten und deren Darstellung bezüglich der verschiedenen Referenzhöhen, Geoide und Ellipsoide machen. Zur Erfassung der Höhe ist die barometrische Höhenmessung die einfachste, genaueste und preiswerteste. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf dem 25C3
Hallo, On Wednesday 03 December 2008 10:44:32 Andreas Hubel wrote: Ich werde auch da sein. Sollen wir analog zum letzen mal nen Workshop / Treffen auf http://events.ccc.de/congress/2008/wiki/Workshops eintragen? ich finde ein Treffen ist auf jeden Fall eine gute Idee. Ein Workshop würde bestimmt auch gut ankommen, aber den müsste halt jemand vorbereiten. ;) Gruß PhiBo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
was aber wiederum klar macht, dass solche Polygone nicht unbedingt als maxspeed-Default dienen können! Stefan Frederik Ramm schrieb: Hallo, Sascha Silbe wrote: Geschlossene Ortschaft nach StVO (die gelben Ortstafeln) und die Ausdehnung eines Ortes (- Adressen) sind nicht identisch. Genau, und built-up area ist einfach bebautes Gebiet - also was man typischerweise von einem Luftbild sofort einzeichnen kann. Der Begriff hat im Englischen nicht den scharf begrenzten Charakter von unserem geschlossene Ortschaft. Es ist also damit zu rechnen, dass jemand, der nicht aus Deutschland ist, eine Grenze, die mit built-up area getaggt ist, so veraendern wuerde, dass sie eben dem bebauten Gebiet entspricht. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MotorwayCheck
Jochen Topf schrieb: On Wed, Dec 03, 2008 at 10:11:28PM +0100, Gary68 wrote: tja, was ist korrekt? in map features stehen als werte für oneway= yes/no or 1/-1 daher ist die liste etwas länglich und true evtl. nicht korrekt? Also true war immer korrekt und in Europa gibt es 100.000 ways mit oneway=true. (Ca. genausoviele mit =1 und dreimal so viele mit =yes.) Weiß nicht, warum das nicht in Map Features ist. :-( Jochen Da gab es doch vor einiger Zeit mal eine längere Diskussion auf dieser (oder talk?) Liste, daß xy=true (bzw. false) irgendwie nur von Informatikern intuitiv verstanden wird. Wenn ich mich recht entsinne, war daher der Konsens besser yes / no zu verwenden. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MotorwayCheck
anyway, habe jetzt true/false auch als valide implementiert. wäre vielleicht mal was für einen bot? Deutschland und Österreich sind online: http://wiki.openstreetmap.org/wiki/MotorwayCheck ciao gerhard Am Donnerstag, den 04.12.2008, 11:19 +0100 schrieb Ulf Lamping: Jochen Topf schrieb: On Wed, Dec 03, 2008 at 10:11:28PM +0100, Gary68 wrote: tja, was ist korrekt? in map features stehen als werte für oneway= yes/no or 1/-1 daher ist die liste etwas länglich und true evtl. nicht korrekt? Also true war immer korrekt und in Europa gibt es 100.000 ways mit oneway=true. (Ca. genausoviele mit =1 und dreimal so viele mit =yes.) Weiß nicht, warum das nicht in Map Features ist. :-( Jochen Da gab es doch vor einiger Zeit mal eine längere Diskussion auf dieser (oder talk?) Liste, daß xy=true (bzw. false) irgendwie nur von Informatikern intuitiv verstanden wird. Wenn ich mich recht entsinne, war daher der Konsens besser yes / no zu verwenden. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MotorwayCheck
On Thu, Dec 04, 2008 at 11:19:41AM +0100, Ulf Lamping wrote: Jochen Topf schrieb: On Wed, Dec 03, 2008 at 10:11:28PM +0100, Gary68 wrote: tja, was ist korrekt? in map features stehen als werte für oneway= yes/no or 1/-1 daher ist die liste etwas länglich und true evtl. nicht korrekt? Also true war immer korrekt und in Europa gibt es 100.000 ways mit oneway=true. (Ca. genausoviele mit =1 und dreimal so viele mit =yes.) Weiß nicht, warum das nicht in Map Features ist. :-( Jochen Da gab es doch vor einiger Zeit mal eine längere Diskussion auf dieser (oder talk?) Liste, daß xy=true (bzw. false) irgendwie nur von Informatikern intuitiv verstanden wird. Wenn ich mich recht entsinne, war daher der Konsens besser yes / no zu verwenden. Finde ich im Prinzip richtig. Aber dann muss man das auch 1. auf talk diskutieren und nicht nur hier 2. die bestehenden Tags umsetzen Solange von so einer Überlegung keiner was mitbekommt und noch 100.000 Fälle so getagged sind, kann man das nicht als Fehler markieren. Jochen -- Jochen Topf [EMAIL PROTECTED] http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tagwatch
Hallo, Seit Mitte November läuft TagWatch nicht mehr, da keine Daten von OSM-Wiki geladen werden können. Falls Ihr aktuellere Daten haben wollt, dann wäre es schön, falls jemand den Fehler im Skript sucht und findet. Ich habe dazu momentan keine Zeit. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachteil barometrischer H�henmesser // Re: LKW-Routing (TV-Bericht)
Hi Torsten, Sicher, dass die staendig nachkalibrieren? Woran erkennen die denn, ob nun der barometrische oder der GPS-Wert fehlerhaft ist? Das Zauberwort hier ist Statistik: Das Gerät kann nicht wissen was richtig ist. Sehr wohl kann es aber davon ausgehen, daß man normalerweise keine größeren Höhensprünge auf/abwärts macht, weder am Barometer noch am GPS. Kurzfristige Sprünge aus einer Quelle die so nicht aus der anderen Quelle stammen können damit eliminiert werden. Genauso kann man davon ausgehen daß die Ergebnisse der beiden Quellen nicht auseinanderlaufen dürfen, und es ist weiter bekannt daß ein Barometer wegdriften kann. Also wird man den Barometer-Mittelwert über Zeit auf den GPS-Mittelwert angleichen, und die kurzfristigen Schwankungen vom Barometer nehmen. Das scheitert genau dann wenn der Barometer auch grob nicht mehr mit dem GPS zusammenpasst: im Flugzeug mit künstlich erhöhtem Luftdruck in der Kabine. Was ich an Versuchsreihen von verschiedenen Leuten im Internet gelesen habe, laesst eigentlich nicht darauf schliessen, dass da waehrend des Betriebs grossartig nachkalibriert wird. Wozu auch. Ein vorher kalibrierter, barometrischer Hoehenmesser ist fuer unsere Zwecke bei den meisten Wetterlagen mehr als genau genug. Ich kann vom Vergleich Pulsuhren mit Map76s sicher sagen, daß über den Verlauf von 4h (Fahrradrundtour) der rein Barometrische Höhenmesser bei insgesamt 400m Aufstieg um 50-70m mehr Aufstieg als Abstieg gezeigt hat. Dies war beim 76 nicht so - da waren es nur 5-10m Differenz. -- Ciao, Holger (GUS-KOTAL, GUS#1100, GRR#51) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 69 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] einheitliche Darstellung von Autobahn-Zubringern (einfache Form)
On Thu, Dec 04, 2008 at 09:07:44AM +0100, Christian Mayr wrote: da sind wir halt einfach anderer meinung ;-) ich tagge es halt einfach so wie die starssen gebaut sind, und du wie es für die navis vieleicht einfacher zu handhaben ist. wobei ich der meinung bin wenn ein navi sagt du sollt auf einer einfahrt/ausfahrt wenden, dann ist es schlecht programmiert, und wenn der fahrer das dann auch noch macht, dann sollte er vieleicht nochmal ein paar fahrstunden nehmen ;-) Woher weiss das Navi denn das das eine Einfahrt/Ausfahrt ist? Man muss es ihm sagen - Genau das macht Gary und ich mache es ebenso ... Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MotorwayCheck
danke für die Österreich-Version, Line 1 habe ich mal erledigt - sende CC an talk-at lg Wolfgang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gary68 Sent: Thursday, December 04, 2008 11:28 AM To: talk-de Subject: Re: [Talk-de] MotorwayCheck anyway, habe jetzt true/false auch als valide implementiert. wäre vielleicht mal was für einen bot? Deutschland und Österreich sind online: http://wiki.openstreetmap.org/wiki/MotorwayCheck ciao gerhard Am Donnerstag, den 04.12.2008, 11:19 +0100 schrieb Ulf Lamping: Jochen Topf schrieb: On Wed, Dec 03, 2008 at 10:11:28PM +0100, Gary68 wrote: tja, was ist korrekt? in map features stehen als werte für oneway= yes/no or 1/-1 daher ist die liste etwas länglich und true evtl. nicht korrekt? Also true war immer korrekt und in Europa gibt es 100.000 ways mit oneway=true. (Ca. genausoviele mit =1 und dreimal so viele mit =yes.) Weiß nicht, warum das nicht in Map Features ist. :-( Jochen Da gab es doch vor einiger Zeit mal eine längere Diskussion auf dieser (oder talk?) Liste, daß xy=true (bzw. false) irgendwie nur von Informatikern intuitiv verstanden wird. Wenn ich mich recht entsinne, war daher der Konsens besser yes / no zu verwenden. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] upload failure
Hallo, ich bin neu bei OpenStreetMap und wollte probeweise meinen ersten Track hochladen. Ich habe ein Garmin GPS 60 und den Track mit Hilfe von GPSBabel in ein GPX-File umgewandelt. Leider bekomme ich immer folgende Fehlermeldung: Found no good GPX points in the input data. At least 75% of the trackpoints lacked a time tag. Im Josm Editor kann ich mir den Track ohne Probleme anzeigen lassen. Kann mir jemand helfen? Grüße, Astrid ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] upload failure
Astrid schrieb: ich bin neu bei OpenStreetMap und wollte probeweise meinen ersten Track hochladen. Ich habe ein Garmin GPS 60 und den Track mit Hilfe von GPSBabel in ein GPX-File umgewandelt. Leider bekomme ich immer folgende Fehlermeldung: Found no good GPX points in the input data. At least 75% of the trackpoints lacked a time tag. Wie sieht denn das GPX File aus? Fehlen tatsächlich die Zeit-Tags? so sollte es aussehen: trkpt lat=53.56341667 lon=6.74895000 time2008-06-26T17:48:22Z/time /trkpt trkpt lat=53.56331667 lon=6.7487 time2008-06-26T17:48:37Z/time /trkpt Ich persönlich ziehe mir die Tracks mittels EasyGPS vom Etrex runter. Das lässt sich dann problemlos auf OSM importieren. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
On Thu, Dec 04, 2008 at 01:15:59AM +0100, Frederik Ramm wrote: Genau, und built-up area ist einfach bebautes Gebiet - also was man typischerweise von einem Luftbild sofort einzeichnen kann. OK, gutes Argument. Der Begriff hat im Englischen nicht den scharf begrenzten Charakter von unserem geschlossene Ortschaft. Dann würde ich doch einfach mal boundary=geschlossene Ortschaft als Tag vorschlagen, das ist dann eindeutig. :-| Aber letztendlich kommt es eh hauptsächlich auf eine passende Beschreibung im Wiki und in den Presets an... CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagwatch
Dirk Stöcker wrote: Seit Mitte November läuft TagWatch nicht mehr, da keine Daten von OSM-Wiki geladen werden können. Was ist der Grund dafür? Grüße, Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MotorwayCheck
hallo gerhard Gary68 schrieb: [...] Deutschland und Österreich sind online: http://wiki.openstreetmap.org/wiki/MotorwayCheck hier http://www.gary68.de/osm/qa/c12/c12_austria.htm ist es bei nr. 32 und 33 (für mehr hatte ich noch keine zeit) so, dass eine brücke anfängt. sonst passt aber alles. hat der check-algorithmus damit ein problem oder mache ich was falsch oder übersehe ich was? viele grüße hermann ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
On Wed, Dec 03, 2008 at 01:55:45PM +0100, Garry wrote: Ortsschilder sind willkürlich aufgestellt - soll heissen sie folgen nicht irgendwelchen Flächenausdehnungen. Nein, aber sie definieren eine Fläche. Innerhalb dieser Fläche gelten bestimmte Regeln, außerhalb andere. Es gibt Strassen die mitten durch einen Ort gehen aber dennoch keien innerörtliche Strassen sind Genau deshalb brauchen wir ein eigenes Tag dafür. Aber ein Argument kontra als Fläche eintragen ist es nicht. Die einzigste Vernünftige Lösung ist die Wegsegmente selbst als innerörtlich zu taggen. Jeden einzelnen Weg markieren (egal ob per Relation oder Tag) ist sowohl Verschwendung von Mapper-Zeit als auch fehleranfällig. Die Fläche wird an genau den Stellen verankert, wo die Schilder stehen; ggf. werden noch ein paar Hilfspunkte gesetzt, damit die Straßen, die die Grenze nicht überschreiten, auch wirklich inner/ausserhalb sind. Das ist - wenn man die Schilderpositionen bereits hat - eine Sache von einer Minute, und damit ist es dauerhaft und eindeutig definiert. Keine Änderung im Inneren kann dazu führen, daß eine Straße plötzlich als außerorts interpretiert wird. Bei Relation oder Tag am Weg passiert das dagegen sehr schnell. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe, niemand macht mehr mit!
Hallo Liste, Norbert Kück schrieb: [...] Was ist schlecht daran, dass sich die Mapper im Zuge zunehmender Flächendeckung verändern? Klar, dass die Eroberer ohne weiße Flecken die Lust verlieren können. Sie werden weggehen oder eine andere Motivation zum Weitermachen entwickeln. [...] Also, diese Sorgen habe ich derzeit nicht. In der Umgebung und in meinen bevorzugten Reisegebieten gibt es noch so viele Unstimmigkeiten und weiße Flecken, das ich trotz fleißiger Mitstreiter noch ewig zu tun habe :-) Motivation gibt es genügend - ich brauche die erfaßten Daten zum Teil für Veröffentlichungen. Allerdings weiß ich auch noch, was mich als Anfänger genervt hat. Ich bin erst im Sommer 08 dazu gekommen. Vieles wurde hier schon angesprochen: unübersichtliche oder fehlende Dokumentation, schwierig zu bedienende Programme (wobei das selbst in den paar Monaten dank großer Mühen besser geworden ist)und vor allem Unklarheiten! Ich will nicht seitenlang diskutieren, wie ein Zaun zu taggen ist. Ich habe dazu keine Zeit. Ich will ganz einfach nur wissen, wie ich den Zaun eintragen soll. An solchen Dingen mangelt es teilweise und das ist ein großes Ärgernis, für mich jedenfalls. Manchmal habe ich auch den Eindruck, es gibt eine Einigung, aber die ist nicht an zentraler Stelle zu finden. Gruß Dieter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe, niemand macht mehr mit!
Hallo, Dieter TD wrote: Ich will nicht seitenlang diskutieren, wie ein Zaun zu taggen ist. Ich habe dazu keine Zeit. Ich will ganz einfach nur wissen, wie ich den Zaun eintragen soll. OSM ist derzeit halt noch ein Projekt fuer Mitdenker und weniger eins fuer Mitlaeufer ;-) Der Grund dafuer ist, dass Standards halt einfach ihre Zeit brauchen, bis sie sich bewaehrt haben und bis irgendwann jeder sagt klar, dies und das taggen wir immer so und so. Davor liegt eine lange Strecke des Ausprobierens, und verbindliche Wahrheiten gibt es nicht. Diese Chaos-Zeit tritt bei uns an die Stelle eine diktatorischen Festlegung a la Mapping-Industrie. Das ist sozusagen unsere Art, ein Schema auszuarbeiten. Dabei bleiben einige, die ein weniger dickes Fell haben als Du, vermutlich auf der Strecke, weil man ihnen eben nicht sagen kann, was sie machen sollen. Aber daran ist nichts zu aendern - wenn diese Leute nicht bereit und in der Lage sind, in dem Zielfindungsprozess mitzumachen, dann muessen sie eben warten, bis dieser Prozess weiter fortgeschritten ist. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
offensichtlich geht es darum zwei Begriffe auseinander zu halten: 1.) das bebaute Gebiet - dehnt sich automatisch (comunity-driven) aus, wenn ein neues Haus gebaut wird - wichtig für die Renderer, damit es nett aussieht - das müßte eigentlich built-up-area sein? 2.) jenes Gebiet, in dem ein niedrigeres Tempolimit gilt als auf Überlandstraßen - wichtig für Router - maxspeeds reichen hier nicht, weil relativ klar ist, daß Überland maxspeed auch als Reisegeschwindigkeit erreicht werden kann, innerhalb von Orten etwa die Hälfte oder knapp mehr - das müßte dann city-limit sein? jedenfalls dehnt sich das nicht automatisch aus, sondern ist (in D, A, ...) durch Ortstafeln begrenzt und heißt hier D: geschlossene Ortschaft, A: Ortsgebiet, ... ; in England wird es offensichtlich durch das Vorhandensein von drei Laternen begründet ;-) Für mich (beim Routen) macht es einen Unterschied, ob Tempo 50 Überland vorkommt, da setze ich Reisegeschwindigkeit 50, im Ort bei Tempo 50 etwa Reisegeschwindigkeit 10 - 30 (je nach Straßentyp) - dazu muß man halt wissen, wo man ist. lg Wolfgang PS: fast offtopic: beim Setzen von Ortstafeln ist man in Österreich sehr pingelig (in Deutschland habe ich in einer vorigen Meldung mal mitgelesen, daß nicht unbedingt an allen Straßen Ortstafeln stehen müssen ;-), Ortstafeln müssen an den Orteinfahrten aller öffentlichen Straßen stehen, sonst gilt das Tempolimit nicht. Das ging ja sogar soweit, daß Vertreter der slowenischen Minderheit in Kärnten zweisprachige Ortstafeln per Verfassungsgerichtshofsurteil herbeigeführt haben. Dieser ist nämlich der Ansicht, daß die Ortstafel nur gilt, wenn sie dort zB zweisprachig ist. Auch mit Werbetafeln am gleichen Ständer gab es schon viele Probleme. Mit einigen wenigen Ausnahmen, die taxativ in der (Ö) StVO aufgezählt sind, darf nun keine Werbung mehr am gleichen Ständer sein, sonst ist die Ortstafel ungültig. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sascha Silbe Sent: Thursday, December 04, 2008 1:02 PM To: Openstreetmap allgemeines in Deutsch Subject: Re: [Talk-de] Ortsgebiet On Thu, Dec 04, 2008 at 01:15:59AM +0100, Frederik Ramm wrote: Genau, und built-up area ist einfach bebautes Gebiet - also was man typischerweise von einem Luftbild sofort einzeichnen kann. OK, gutes Argument. Der Begriff hat im Englischen nicht den scharf begrenzten Charakter von unserem geschlossene Ortschaft. Dann würde ich doch einfach mal boundary=geschlossene Ortschaft als Tag vorschlagen, das ist dann eindeutig. :-| Aber letztendlich kommt es eh hauptsächlich auf eine passende Beschreibung im Wiki und in den Presets an... CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] upload failure
Am Donnerstag, den 04.12.2008, 12:45 +0100 schrieb Chris66: Astrid schrieb: ich bin neu bei OpenStreetMap und wollte probeweise meinen ersten Track hochladen. Ich habe ein Garmin GPS 60 und den Track mit Hilfe von GPSBabel in ein GPX-File umgewandelt. Leider bekomme ich immer folgende Fehlermeldung: Found no good GPX points in the input data. At least 75% of the trackpoints lacked a time tag. Wie sieht denn das GPX File aus? Fehlen tatsächlich die Zeit-Tags? so sollte es aussehen: trkpt lat=53.56341667 lon=6.74895000 time2008-06-26T17:48:22Z/time /trkpt trkpt lat=53.56331667 lon=6.7487 time2008-06-26T17:48:37Z/time /trkpt Ich persönlich ziehe mir die Tracks mittels EasyGPS vom Etrex runter. Das lässt sich dann problemlos auf OSM importieren. Grüße Chris Hallo Chris, das gpx-file sieht so aus: ?xml version=1.0 encoding=UTF-8? gpx version=1.0 creator=GPSBabel - http://www.gpsbabel.org; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=http://www.topografix.com/GPX/1/0; xsi:schemaLocation=http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd; time2008-12-04T10:21:53Z/time bounds minlat=51.268048799 minlon=7.211564686 maxlat=51.274054013 maxlon=7.224189593/ trk name30-NOV-08/name trkseg /trkseg /trk trk name30-NOV-08 #2/name number1/number trkseg trkpt lat=51.273562750 lon=7.223502360 ele56.374512/ele /trkpt trkpt lat=51.273906073 lon=7.222153377 ele169.810059/ele /trkpt trkpt lat=51.273903809 lon=7.222169470 ele169.810059/ele /trkpt ... usw. Jedem Trackpunkt müsste demnach ein Zeit-Tag beigefügt sein, was bei mir offensichtlich nicht der Fall ist. Woran liegt das? Wie kann ich die einfügen? Grüße, Astrid ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] upload failure
Hallo Astrid, Jedem Trackpunkt müsste demnach ein Zeit-Tag beigefügt sein, was bei mir offensichtlich nicht der Fall ist. Woran liegt das? Wie kann ich die einfügen? Das liegt daran, daß der Track in dem Garmin abgespeichert wurde. Beim Speichern spart Garmin die Zeitstempel ein, vermutlich um Platz zu sparen. Nun gibt es 3 Möglichkeiten: 1) den aktiven Tracklog nicht speichern und gleich verwenden, dann sind dort noch die Zeitstempel drin. 2) den Tracklog auf der Speicherkarte mit schreiben lassen, dort bleiben die timestamps drin 3) ein kleines Script schreiben, welches dort Zeitstempel einfügt. Zu 3 gibt es auch ein Programm, welches ich leider auf die Schnelle nicht wiedergefunden habe. Gruß Kai -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] upload failure
Hallo Astrid, 3) ein kleines Script schreiben, welches dort Zeitstempel einfügt. Zu 3 gibt es auch ein Programm, welches ich leider auf die Schnelle nicht wiedergefunden habe. Habe das Script doch gefunden: http://wiki.openstreetmap.org/wiki/User:Farzaneh Gruß Kai -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
1.) das bebaute Gebiet - dehnt sich automatisch (comunity-driven) aus, wenn ein neues Haus gebaut wird - wichtig für die Renderer, damit es nett aussieht - das müßte eigentlich built-up-area sein? Das ist für mich eigentlich place=city/town/... 2.) jenes Gebiet, in dem ein niedrigeres Tempolimit gilt als auf Überlandstraßen - wichtig für Router - maxspeeds reichen hier nicht, weil relativ klar ist, daß Überland maxspeed auch als Reisegeschwindigkeit erreicht werden kann, innerhalb von Orten etwa die Hälfte oder knapp mehr - das müßte dann city-limit sein? Einigen wir uns ruhig auf city_limit, das ist schon in den Presets drin, wenn auch nur als traffic_sign und für Nodes (?). Jetzt ist nur noch die Frage, als welches Feature es zu taggen ist. Also geschlossener Weg wie von mir vorgeschlagen, Relation mit betroffenen Wegen (und Straßenlaternen etc.) drin, Tag an jedem betroffenen Weg (und ...), einfach nur Nodes setzen bei den Schildern (Berechnung betroffener Wege skaliert vermutlich nicht gut genug für Router, insb. wenn Ortsschilder fehlen / noch nicht gemappt sind). Sonst noch Vorschläge? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
Hallo, Wolfgang W. Wasserburger wrote: das müßte dann city-limit sein? City Limit ist im US-Englisch einfach die Stadtgrenze, hat mit Verkehr nichts zu tun. jedenfalls dehnt sich das nicht automatisch aus, sondern ist (in D, A, ...) durch Ortstafeln begrenzt und heißt hier D: geschlossene Ortschaft, A: Ortsgebiet, ... ; in England wird es offensichtlich durch das Vorhandensein von drei Laternen begründet ;-) In England, meine ich mich zu erinnern, ist die reduzierte Geschwindigkeit tatsaechlich in built-up areas vorgeschrieben, d.h. dort fallen die beiden Begriffe zusammen und es duerfte eine Menge Streitigkeiten geben ;-) Ich frag mal die Englaender. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] upload failure
Hallo Kai, vielen Dank, ich werde es nachher mal damit probieren und in Zukunft die Tracks nicht im Garmin speichern... Grüße, Astrid Am Donnerstag, den 04.12.2008, 13:52 +0100 schrieb [EMAIL PROTECTED]: Hallo Astrid, 3) ein kleines Script schreiben, welches dort Zeitstempel einfügt. Zu 3 gibt es auch ein Programm, welches ich leider auf die Schnelle nicht wiedergefunden habe. Habe das Script doch gefunden: http://wiki.openstreetmap.org/wiki/User:Farzaneh Gruß Kai ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MotorwayCheck
Hermann Schwärzler: hallo gerhard Gary68 schrieb: [...] Deutschland und Österreich sind online: http://wiki.openstreetmap.org/wiki/MotorwayCheck hier http://www.gary68.de/osm/qa/c12/c12_austria.htm ist es bei nr. 32 und 33 (für mehr hatte ich noch keine zeit) so, dass eine brücke anfängt. sonst passt aber alles. hat der check-algorithmus damit ein problem oder mache ich was falsch oder übersehe ich was? Der JOSM-Validator zeigt sofort, dass dort zwei Wege direkt übereinander liegen. Ich hab versucht die zu löschen, aber da sie Teil einer Relation sind gibt es beim Upload Probleme. ...oh... moment... jetzt hat's doch geklappt :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] upload failure
Hallo Astrid, Hallo Kai, vielen Dank, ich werde es nachher mal damit probieren und in Zukunft die Tracks nicht im Garmin speichern... Nach dem runterladen vom Garmin bietet es sich an, mit GPSBabel die Zeitstempel zu verschieben. Sonst ist es recht einfach, festzustellen, wann Du Dich wo aufgehalten hast. Das möchte nicht jeder gerne von sich preisgeben (Auch wenn das jetzt sicherlich einigen nicht passen sollte, ich finde das man die Zeitstempel schon verschieben sollte...) Gruß Kai -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radfernwege in mehreren Relationen abbilden
Am 03.12.08 schrieb Falk Zscheile: Für den Radfernweg D 11 (Ostsee-Oberbayern) und dem dem Radfernweg Berlin-Kopenhagen existiert jeweils eine eigene Relation. Der D 11 ist im Bereich Berlin-Rostock identisch mit mit dem Radfernweg Berlin-Kopenhagen. Da der Radfernweg weiter im Süden auch noch einige andere Routen enthält, ist das meiner Meinung nach ein prima Kandidat für eine Superrelation. Ansonsten, da das viele Änderungen nach sich ziehen würde, kannst Du überlegen, ob Du im Relation Analyzer raussuchst, welche Wege fehlen (dort sind die Weg-IDs sortiert), und diese dann mit einem Editor in der osm-Datei der Relation einträgst und z.B. mit curl speicherst (http://wiki.openstreetmap.org/wiki/Using_curl_to_upload_data). Gruß, Fabian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Der Vertrag ist unterzeichnet. Das Projekt ist bis 31.3.2009 verlängert. Die Daten sind unterwegs. Jetzt liegt es an uns, was wir daraus machen... Sven Geggus wird den WMS-Server aufsetzen und die Daten ggf. in unser Format transformieren. Jochen Topf kümmert sich um die Erfolgs-Statistik und hat Ideen zu einem Mal-Wettbewerb. http://wiki.openstreetmap.org/wiki/DE:Luftbilder_aus_Bayern Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte mit Öffentlichen Verkehrsmitteln
Sehr schön. Permalink wäre noch toll. Ist drin! Währe noch schön, wenn auch das gewählte Overlay mit in den Permalink aufgenommen wird. http://dev.openlayers.org/docs/files/OpenLayers/Control/Permalink-js.html#OpenLayers.Control.Permalink.createParams be blessed Natanael -- Web: http://natanael.comiles.eu eMail: natanaela _at_ gmx.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachteil barometrischer HXhenmesser // Re: LKW-Routing (TV-Bericht)
Hallo Holger, Holger Issle schrieb: Ei klar, aber das gilt ja nur für rein barometrische Höhenmesser, nicht für die in Garmin-Geräten verbauten. Die Garmins kalibrieren den Höhenmesser anhand der GPS-Höhe ständig nach und sind deshalb recht genau. Da gleichen sich die Fehler beider Systeme gegenseitig aus. Aus der Beschreibung zum Garmin GPSMAP 60CSx: Der GPSMAP 60CSx beinhaltet außerdem einen barometrischen Höhenmesser, welcher die Höhenbestimmung sehr exakt ermöglicht. Garmin Oregon 400t (rund 450 EUR): barometrischer Höhenmesser Garmin eTrex Vista HCx (rund 200 EUR): barometrische Höhenmessung Und wenn man sich mal die Anleitung genau durchliest: Wenn die Frage angezeigt wird, ob Sie die genaue Höhe wissen, wählen sie 'Ja'. Wenn Sie die Höhe nicht wissen, wählen Sie 'Nein', um die Druckoption zu verwenden. Wenn Sie den Druck nicht wissen, wählen Sie 'Nein', um die standardmäßige GPS-Höhe zu verwenden. Meine Übersetzung: Wenn dem Nutzer die Höhe bekannt ist, kalibriert sich das Gerät auf den aktuellen Luftdruck. Wenn der Luftdruck sich ändert: Pech, Höhe falsch. Wenn dem Nutzer die Höhe nicht bekannt ist, errechnet das Gerät aus dem aktuellen Luftdruck die Höhe (barometrische Höhenformel) und kalibriert sich darauf. Wenn der Luftdruck sich ändert: Pech, ... Wenn dem Nutzer die Höhe und der Druck nicht bekannt sind / bekannt sein wollen, dann geht das Gerät ausschließlich von den GPS-Daten aus. Wenn Störungen vorhanden sind: Pech, Höhe falsch. Ach, wie primitiv die digitale Welt doch manchmal sein kann :-) Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachteil barometrischer HXhenmesser // Re: LKW-Routing (TV-Bericht)
Holger Issle schrieb: Also wird man den Barometer-Mittelwert über Zeit auf den GPS-Mittelwert angleichen, und die kurzfristigen Schwankungen vom Barometer nehmen. Wenn die Werte mit dem GPS-Mittelwert vergleichen werden, erachte ich sie für nutzlos. Stell Dir vor, Du stehst unter einer Regenwolke, dann hast Du einmal die Fehlmessung durch die GPS-Störungen und einmal die Verfälschung durch den Druck. Gerade für Bergsteiger dürfte sowas total fatal sein :-) Das scheitert genau dann wenn der Barometer auch grob nicht mehr mit dem GPS zusammenpasst: im Flugzeug mit künstlich erhöhtem Luftdruck in der Kabine. Flugzeuge verwenden neben barometrischen Messern hauptsächlich Funkhöhenmesser, die über Radarstrahlen und die Echolaufzeit zum Boden ermitteln und dann mit Geländemodellen auf Meeresspiegel rechnen. Richtige Höhenmesser muss man auf Temperatur kalibrieren, damit sie einigermaßen genau messen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nochmals Grenzen und admin_level
Mario Salvini [EMAIL PROTECTED] wrote: In Bonn gibts einen ganzen Haufen admin_level=10 und auch ein paar admin_level=9. Stimmen die jetzt alle nach neuem Schema? Die paar 9er sollten die 4 Stadtbezirke sein, den Rest habe ich erstmal auf 10 gesetzt... Guck mal auf DE:Grenzen bei Bonn und Wikipedia etc. Bonn scheint mehrere inkompatible Unterteilungssysteme haben. Bin niht sicher, welches da in OSM umgesetzt wurde und wie das in Relation zu den Karten in der Wikipedia steht, ich erkenne da auf fluechtigem Blick gelegentlich Widersprueche. Vermutlich sollten wir bzgl. Details in OSM mal abwarten, wie wir uns prinzipiell entscheiden bzgl. Staedten mit mehreren inkompatiblen Unterteiungssystemen. Das kommt sporadisch vor. Mit der Staedteliste werde ich tendentiell naechste Woche weitermachen koennen, dann haben wir den Ueberblick, wie oft sowas in Staedten 100.000 vorkommt und vielleicht schon eine Loesungsidee... Mir schwebt schon was vor, aber ich moechte noch das Ende der Liste abwarten... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Markus schrieb: Der Vertrag ist unterzeichnet. Das Projekt ist bis 31.3.2009 verlängert. Na herzlichen Glückwunsch! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
Eine Area macht wenig sinn, weil man einfach bei den Stellen zwischen Ortseingabsschilder Nodes nicht wirklich weiß, wass man tun soll. Ich würde vorschlagen wir lösen das StVO-abhängige Straße ist innerorts über eine Relation. Relation mit z.B. dem type=ROAD_IS INTOWN und packen da alle Wegstücke rein, die laut StVO innerorts sind. In den meisten Fällen deckt sich das sogar mit der place-Area (welche ja nur als Heuristik herhalten kann, da nicht 100% deckungsgleich) und außerdem ist es für die Router und die Tagger so am Einfachsten. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
From: Sascha Silbe [mailto:[EMAIL PROTECTED] 1.) das bebaute Gebiet - dehnt sich automatisch (comunity-driven) aus, wenn ein neues Haus gebaut wird - wichtig für die Renderer, damit es nett aussieht - das müßte eigentlich built-up-area sein? Das ist für mich eigentlich place=city/town/... ist auch schlüssig - für meinen automatischen Import brauche ich halt eine einheitliche Variante, weil ich's sonst nicht automatisiseren kann 2.) jenes Gebiet, in dem ein niedrigeres Tempolimit gilt als auf Überlandstraßen - wichtig für Router - maxspeeds reichen hier nicht, weil relativ klar ist, daß Überland maxspeed auch als Reisegeschwindigkeit erreicht werden kann, innerhalb von Orten etwa die Hälfte oder knapp mehr - das müßte dann city-limit sein? Einigen wir uns ruhig auf city_limit, das ist schon in den Presets drin, wenn auch nur als traffic_sign und für Nodes (?). Jetzt ist nur noch die Frage, als welches Feature es zu taggen ist. Also geschlossener Weg wie von mir vorgeschlagen, Relation mit betroffenen Wegen (und Straßenlaternen etc.) drin, Tag an jedem betroffenen Weg (und ...), einfach nur Nodes setzen bei den Schildern (Berechnung betroffener Wege skaliert vermutlich nicht gut genug für Router, insb. wenn Ortsschilder fehlen / noch nicht gemappt sind). Sonst noch Vorschläge? habe gerade auch wo gelesene, daß city_limit das amerikanische pendant zu built-up-area ist; ist also vielelicht auch nciht optimal. aus meiner Sicht reicht es beim Routen auch aus, wenn ich's auf primary/secondary/tertiary habe; resdiential sollte sowieso nur im Ort vorkommen und auf allem anderne kann man eh' nicht schnell fahren ;-) CU W ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
On Thu, Dec 04, 2008 at 03:27:33PM +0100, Wolfgang W. Wasserburger wrote: aus meiner Sicht reicht es beim Routen auch aus, wenn ich's auf primary/secondary/tertiary habe; resdiential sollte sowieso nur im Ort vorkommen und auf allem anderne kann man eh' nicht schnell fahren ;-) Für Geschwindigkeitsabschätzung beim Routen mag das reichen, aber nicht notwendigerweise für alles andere auch. Zumindest in DE hängt von der geschlossenen Ortschaft mehr ab als nur die erlaubte Geschwindigkeit. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
On Thu, Dec 04, 2008 at 03:27:25PM +0100, Mario Salvini wrote: Eine Area macht wenig sinn, weil man einfach bei den Stellen zwischen Ortseingabsschilder Nodes nicht wirklich weiß, wass man tun soll. Was genau meinst Du? Und warum soll der Router das besser wissen als ein Mapper? Ich würde vorschlagen wir lösen das StVO-abhängige Straße ist innerorts über eine Relation. Siehe eine der vorgehenden Mails in diesem Thread von mir: Das ist unnötiger Aufwand (alle Straßen innerorts in eine Relation packen) und fehleranfällig (neu angelegte Straßen müssen in die Relation aufgenommen werden, das vergisst man schnell mal). CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
was noch? (das auch noch irgendwo verwendet wird ...) -Original Message- From: Sascha Silbe [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 3:39 PM To: [EMAIL PROTECTED]; Openstreetmap allgemeines in Deutsch Subject: Re: [Talk-de] Ortsgebiet On Thu, Dec 04, 2008 at 03:27:33PM +0100, Wolfgang W. Wasserburger wrote: aus meiner Sicht reicht es beim Routen auch aus, wenn ich's auf primary/secondary/tertiary habe; resdiential sollte sowieso nur im Ort vorkommen und auf allem anderne kann man eh' nicht schnell fahren ;-) Für Geschwindigkeitsabschätzung beim Routen mag das reichen, aber nicht notwendigerweise für alles andere auch. Zumindest in DE hängt von der geschlossenen Ortschaft mehr ab als nur die erlaubte Geschwindigkeit. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] einheitliche Darstellung vonAutobahn-Zubringern (einfache Form)
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Florian Lohoff On Thu, Dec 04, 2008 at 09:07:44AM +0100, Christian Mayr wrote: da sind wir halt einfach anderer meinung ;-) ich tagge es halt einfach so wie die starssen gebaut sind, und du wie es für die navis vieleicht einfacher zu handhaben ist. wobei ich der meinung bin wenn ein navi sagt du sollt auf einer einfahrt/ausfahrt wenden, dann ist es schlecht programmiert, und wenn der fahrer das dann auch noch macht, dann sollte er vieleicht nochmal ein paar fahrstunden nehmen ;-) Woher weiss das Navi denn das das eine Einfahrt/Ausfahrt ist? Man muss es ihm sagen - Genau das macht Gary und ich mache es ebenso ... Das stört mich auch nicht im geringsten. Und wenn ich mich nicht irre erkennt man das an motorway_link gruesse ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] einheitliche Darstellung von Autobahn-Zubringern (einfache Form)
Florian Lohoff schrieb: Woher weiss das Navi denn das das eine Einfahrt/Ausfahrt ist? Man muss es ihm sagen - Genau das macht Gary und ich mache es ebenso ... Das erkennt man in diesem Fall am Strassen-Typ. Und was machst du bei all den anderen Strassen, wo man aufgrund einer durchgezogenen Linie auch nicht wenden darf? Sollen die auch alle doppelt eingetragen werden? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachteil barometrischer HXhenmesser // Re: LKW-Routing (TV-Bericht)
[mailto:[EMAIL PROTECTED] Im Auftrag von Tobias Wendorff Gesendet: Donnerstag, 4. Dezember 2008 14:47 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Nachteil barometrischer HXhenmesser // Re: LKW-Routing (TV-Bericht) Hallo Holger, Holger Issle schrieb: Ei klar, aber das gilt ja nur für rein barometrische Höhenmesser, nicht für die in Garmin-Geräten verbauten. Die Garmins kalibrieren den Höhenmesser anhand der GPS-Höhe ständig nach und sind deshalb recht genau. Da gleichen sich die Fehler beider Systeme gegenseitig aus. Aus der Beschreibung zum Garmin GPSMAP 60CSx: Der GPSMAP 60CSx beinhaltet außerdem einen barometrischen Höhenmesser, welcher die Höhenbestimmung sehr exakt ermöglicht. Garmin Oregon 400t (rund 450 EUR): barometrischer Höhenmesser Garmin eTrex Vista HCx (rund 200 EUR): barometrische Höhenmessung Und wenn man sich mal die Anleitung genau durchliest: Wenn die Frage angezeigt wird, ob Sie die genaue Höhe wissen, wählen sie 'Ja'. Wenn Sie die Höhe nicht wissen, wählen Sie 'Nein', um die Druckoption zu verwenden. Wenn Sie den Druck nicht wissen, wählen Sie 'Nein', um die standardmäßige GPS-Höhe zu verwenden. und das bedeutet das du zum kallibrieren des höhenmessers entweder die höhe angeben kannst den druck angeben kannst oder die höhe vom GPS benutzten kannst danach wird die höhe immer anhand des druckes bestimmt. in den einstellungen ist standardmäsig auch eingestellt das der höhenmesser nach dem einschalten durch die gps höhe kallibriert wird. gruesse ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachteil barometrischer HXhenmesser // Re: LKW-Routing (TV-Bericht)
Hallo Tobias, Und wenn man sich mal die Anleitung genau durchliest: Wenn die Frage angezeigt wird, ob Sie die genaue Höhe wissen, wählen sie 'Ja'. Wenn Sie die Höhe nicht wissen, wählen Sie 'Nein', um die Druckoption zu verwenden. Wenn Sie den Druck nicht wissen, wählen Sie 'Nein', um die standardmäßige GPS-Höhe zu verwenden. Meine Übersetzung: --snip Wenn dem Nutzer die Höhe und der Druck nicht bekannt sind / bekannt sein wollen, dann geht das Gerät ausschließlich von den GPS-Daten aus. Wenn Störungen vorhanden sind: Pech, Höhe falsch. Ich lese das so: Der Benutzer kennt die Höhe nicht, den Druck nicht, also nehme ich die aktuelle GPS-Höhe und kalibriere den Höhenmesser auf diesen Wert. Nach diesem Kalibrieren wird wieder der Luftdruck für die Höhe verwendet. (Übrigens haben die Garmin ein eingebautes Thermometer, geben die Daten nur nicht aus ;-), da die Daten zu ungenau wären, da im Gerät gemessen und die Benutzer dann wieder maulen würden: Zeigt ja ganz falsche Temperaturen an.) Gruß Kai -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachteil barometrischer Höhenmesser // Re: LKW-Routing (TV-Bericht)
Holger Issle schrieb: Ich kann vom Vergleich Pulsuhren mit Map76s sicher sagen, daß über den Verlauf von 4h (Fahrradrundtour) der rein Barometrische Höhenmesser bei insgesamt 400m Aufstieg um 50-70m mehr Aufstieg als Abstieg gezeigt hat. Dies war beim 76 nicht so - da waren es nur 5-10m Differenz. Wobei die Werte von akkumulierten Auf- und Abstieg aber nichts mit der Drift vom Hoehenmesser zu tun haben. Fuer die Aufstiegs- und Abstiegswerte werden je nach Geraet unterschiedliche Algorithmen genutzt. Selbst wenn bei einem Geraet die absolute Anfangshoehe gleich der absoluten Endhoehe ist, dann muessen die Aufstiegs- und Abstiegswerte nicht zwangslaeufig uebereinstimmen. Einzig sinnvoller Vergleich waere es, am Start die absoluten Hoehen abzugleichen und dann am Ende die absoluten Hoehen zu vergleichen. Beim automatischen Kalibrieren kann das Geraet eigentlich nur testen, ob der barometrische Wert innerhalb des Bereiches liegt, der sich aus GPS-Hoehe und der Geanuigkeit der GPS-Position ergibt. In diesem Fall weiss er, dass der barometrische Wert nicht stimmt. Wenn der barometrische Wert aber innerhalb des Erwartungsintervall liegt, dann kann das Geraet eigentlich nichts mehr machen, als dem wesentlich genaueren Barometer zu vertrauen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Link: BKG weißt auf OSM hin!
Sven Geggus schrieb: John07 [EMAIL PROTECTED] wrote: Weil OSM soo einfach ist ;-) Die Editoren sind einfach. Für die Renderer gilt das jedoch mitnichten. Du hast das Smilie aber schon gesehen, oder? Ich weiß selbst sehr gut aus eigener Erfahrung, wie einfach die einzelnen Bestandteile von OSM sind. Besonders wenn man die reine Anwenderseite verlässt erfordert es schnell sehr viel Fachkenntnis. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] jre 6 update 11
Hallo, seit der Installation des Java Runtime Environment Updates Version 6 update 11 unter XP schmiert JOSM sofort ab sobald ich irgendeinen der WMS-Server nutzen will. Habe nur das ewms-plugin installiert (ich weiss, dass das experimentell ist!!) Erst die Installation der vorherigen Version (jre 6 update 10) hat Abhilfe geschaffen. Gruss Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Garry schrieb: John07 schrieb: Das ist nicht unser Problem. Ich denke, du stolperst auch fast wöchentlich in irgendeinem Medium über ein Bericht von Leuten, die sich vom Navi in den Schlammfeldweg, den Sumpf oder gleich in Fluss haben leiten lassen. Tja, selbst dran Schuld wenn man nicht mehr auf Schilder schaut. Schließlich fährt weiterhin der Mensch und nicht das Navi das Auto. Aus Dummheit irgendwo hineinzufahren weil man seine Umgebung nicht mehr wahrnimmt und blind dem Navi vetraut ist die eine Sache. Was anderes ist es aber wenn Du (als LKW) aufgrund fehlerhafter Informationen in eine Strasse geleitet wirst aus der Du mangels Wendemöglichkeiten nicht mehr ohne weiteres herauskommst. Aus Schildern ist das nicht unbedingt ersichtlich. Ok, ich verstehe deinen Punkt. Und wenn man dann in Strassen geführt wird die zu eng beparkt sind um mit dem LKW durchzukommen (hatte ich letzte Woche) macht es auch keinen Spass... Ja, und. Wenn ein Unfall ist machts auch kein Spaß. Aber was hat das bitte mit unseren Daten zu tun Wendige Verkehrsteilnehmer können mit 90%igen Karten (bzgl. Erfassungsgrad, Fehlerfreiheit) schon was Anfangen - für LKW routing was man sich hier auf die Fahnen schreiben will ist das aber noch deutlich zu wenig. Ich denke wir sollten darauf schaun, was jetzt da ist. Imo fast gar nichts, oder gibt es bereits funktionierende LKW-Karten bzw. Navis? In diesem Sinne ist unser Datenmaterial bereits ein großer Fortschritt. Ein Restrisiko bleibt immer, aber wir versuchen das Risiko, auch durch die Möglichkeit zur Mitarbeit der LKW-Fahrer, zu minimieren. Ich hab das auch schonmal erlebt, der Busfahrer verlässt sich auf sein Navi (glaube kaum, dass das irgendwie speziell war) und wir sind fast in einer kleinen Wohnstraße stecken geblieben. Das Routing war alles andere als ideal. Aber wenn man in einer unbekannten Gegend unterwegs ist, ist soetwas nicht vermeidbar. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Bernd Wurst schrieb: Hallo. Am Donnerstag, 4. Dezember 2008 schrieb Garry: Die andere Möglichkeit ist noch mehr public zu machen dass auf den Garmins routingfähige OSM-Karten laufen um damit die anderen Hersteller unter Zugzwang zu setzen um den Marktanteilverlust entgegenzuwirken. Routingfähige Karten lassen sich legal momentan nur mit einer Software für teuer Geld produzieren. Alle anderen Methoden, insbesondere das Verbreiten dieser Karten ist nach momentanem Kenntnisstand illegal. Darauf eine Kampagne oder ähnliches aufzubauen finde ich unpassend. Oder um es anders zu sagen: Garmin hat für das Aufspielen von Fremdkarten nicht mehr getan als Microsoft für das Fremderstellen von Office-Dateien. Das Format ist einfach mehr schlecht als Recht gehacked (ohne Routing-Funktion) bzw. ein Hersteller hat wohl eine Lizenz erworben, die recht teuer ist. Beides ist nicht wirklich das was man will und eignet sich IMHO gar nicht um Garmin als den Erlöser darzustellen. Ich frag mich immer, wer wohl der erste Hersteller sein wird, der uns offiziell unterstützt bzw. ein OSM-Navi baut. Wir sollten mal eine Wette machen ;-) Im Bezug auf den Text oben. Wir sollten wenn dann versuchen einen Hersteller für uns zu gewinnen. Der kann dann mit OSM werben. Aber das wir für einen Hersteller werben (ja, indirekt tun wir es ja schon), der uns nicht mal wirklich unterstützt bzw. eher behindert, sehe ich nicht ein. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
On Thu, Dec 04, 2008 at 03:52:02PM +0100, Wolfgang W. Wasserburger wrote: was noch? Z.B. (in DE): - Nutzung von Radwegen durch Mofas (§ 2 (4) 6) - Abstand für langsame Fahrzeuge / FZ länger 7m (§4) - Fahrbahnwahl (§ 7 (3) 1, § 42 (1) d) - Parken: Nähe von Bahnübergang (§ 12 (3) 6), Vorfahrtsstraße (§ 12 (3) 8), ... - Beleuchtung beim Parken (§ 17 (4) 1, ...) - Fahrbahnseite für Fußgänger (§ 25 (1)) ... (das auch noch irgendwo verwendet wird ...) Wenn Du meinst: Was schon von irgendeiner Software ausgewertet wird, dann lautet die Antwort: Nichts mangels passender Datenquellen. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagwatch
Am Donnerstag 04 Dezember 2008 11:39:52 schrieb Dirk Stöcker: Falls Ihr aktuellere Daten haben wollt, dann wäre es schön, falls jemand den Fehler im Skript sucht und findet. Ist die Fehlermeldung zufällig: Can't use an undefined value as a HASH reference at libs/constructHTMLStats.pm line 1054. Ich habe vor ein paar Tagen deswegen schonmal eine Mail bekommen diesbezüglich. Ich wollte mich wenn es meine Zeit erlaubt am WE mal davor setzten und der Sache auf dem Grund gehen. Wenn dies ein allgemeines Problem ist, umso besser. Gruß Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ÖPNV Haltestellenverzeichnis
Hallo (nochmal), habe heute vom örtlichen Verkehrsbetrieb eine Liste der Bushaltestellen für osm bekommen inclusive GPS-Koordinaten, im Prinzip ein export aus deren Linienmanagementsystem, Format xls. Jetzt brauche ich mal guten Rat, wie ich das am besten in osm importiere ohne die schon vorhandenen gemappten Einträge zu verdoppeln, also so eine Art update vorhandener nodes. Gibts das, geht das?? Wenn ich daraus eine osm-Datei baue, die in josm lade, dann muss ich alles von Hand nacharbeiten, aber das würde ich gern vermeiden. Alsoich höreund bin für guten Rat dankbar! Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
Sascha Silbe schrieb: Jeden einzelnen Weg markieren (egal ob per Relation oder Tag) ist sowohl Verschwendung von Mapper-Zeit als auch fehleranfällig. Die Fläche wird an genau den Stellen verankert, wo die Schilder stehen; ggf. werden noch ein paar Hilfspunkte gesetzt, damit die Straßen, die die Grenze nicht überschreiten, auch wirklich inner/ausserhalb sind. Das ist - wenn man die Schilderpositionen bereits hat - eine Sache von einer Minute, und damit ist es dauerhaft und eindeutig definiert. 1. Schaffst du mit der Flaeche ein Hilfskonstrukt, das keinerlei Entsprechung in der Realitaet hat. Es wird auch auf kaum einer Karte eingezeichnet werden, so dass auch die Masse der Nutzer als Kontrollinstrument ausfaellt. 2. Wird man jede Menge Hilfspunkte brauchen. Selbst im einfachsten Fall (kleines Kuhdorf mit genau einer Durchgangsstrasse) kommt man nicht ohne Hilfspunkte aus. Mit eindeutig hat das dann auch nicht mehr das Geringste zu tun, da ja die Anzahl und die Lage der Hilfspunkte beliebig ist. 3. Ist das alles andere als schnell Gemacht. Stell dir mal eine Grossstadt vor. Wieviel tausend Ortseingangsschilder mag Berlin haben? Die muss man alle per Hand in die richtige Reihenfolge bringen und noch einige hundert Hilfspunkte hinzufuegen. Das enstehend Konstrukt duerfte so kompliziert sein, dass es selten fehlerfrei sein duerfte. 4. Wenn man in der Naehe vom Ortsrand etwas aendert, darf man dann erstmal muehselig suchen, wo denn die Grenzlinie verlaeuft, damit man sie entsprechend anpassen kann. Da ja nicht alle Ortsschilder von Zauberhand ploetzlich drin sind, werden die Grenzlinien nach und nach langsam entsehen. Insofern muss man davon ausgehen, dass in der Anfangszeit die reale Ortsgrenze und die fiktive Grenzlinie weit auseinander liegen werden. Keine Änderung im Inneren kann dazu führen, daß eine Straße plötzlich als außerorts interpretiert wird. Bei Relation oder Tag am Weg passiert das dagegen sehr schnell. Ja. Aber der dadurch entstehende Fehler betrifft dann auch nur einen kleinen Strassenabschnitt und wirkt sich nicht auf andere Elemente aus. Wenn aber bei deiner Grenzlinie eine Panne passiert (bei den entstehenden Riesengebilden bestimmt nicht unwahrscheinlich ist), dann wirkt sich der Fehler auf tausende von anderen Elementen aus, die von deiner Grenzlinie gar nichts wissen. Man stelle sich mal vor, jemand definiert (aus Spass oder unbeabsichtigf) eine Ortsgrenze, die mit vier Eckpunkten ganz Europa umfasst. Mit so einer Kleinigkeit waere dann das komplette Routing lahmgelegt. Also robust ist was anderes. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
Mario Salvini schrieb: Ich würde vorschlagen wir lösen das StVO-abhängige Straße ist innerorts über eine Relation. Relation mit z.B. dem type=ROAD_IS INTOWN und packen da alle Wegstücke rein, die laut StVO innerorts sind. In den meisten Fällen deckt sich das sogar mit der place-Area (welche ja nur als Heuristik herhalten kann, da nicht 100% deckungsgleich) und außerdem ist es für die Router und die Tagger so am Einfachsten. Noch viel einfacher ist es, den Weg nicht in eine Relation zu packen, sondern die Information einfach an jeden betroffenen Weg per Tag anzuhaengen. Das ist auch leichter zu kontrollieren und es kann auch nicht so leicht kaputt gehen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetBug lässt sich nicht mehr sc hließen
Meinst du den mit weitere Wegführung ergänzen ? Torsten yep ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachteil barometrischer HXhenmesser // Re: LKW-Routing (TV-Bericht)
Hallo Kai, [EMAIL PROTECTED] schrieb: Wenn dem Nutzer die Höhe und der Druck nicht bekannt sind / bekannt sein wollen, dann geht das Gerät ausschließlich von den GPS-Daten aus. Wenn Störungen vorhanden sind: Pech, Höhe falsch. Ich lese das so: Der Benutzer kennt die Höhe nicht, den Druck nicht, also nehme ich die aktuelle GPS-Höhe und kalibriere den Höhenmesser auf diesen Wert. Ja klar, das meinte ich doch: Kalibrierung durch GPS. Womit dann schon der erste Fehler reinkommt: GPS-Höhe falsch = alles falsch. Nach diesem Kalibrieren wird wieder der Luftdruck für die Höhe verwendet. Genau - und nach der ersten Temperator- oder Luftdruckveränderung wieder alles für die Tonne. (Übrigens haben die Garmin ein eingebautes Thermometer, geben die Daten nur nicht aus ;-), da die Daten zu ungenau wären, da im Gerät gemessen und die Benutzer dann wieder maulen würden: Zeigt ja ganz falsche Temperaturen an.) Ah, temperaturkompensiert sind sie also? Nur bei einem Handgerät wäre ich immer noch skeptisch. Viele Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radfernwege in mehreren Relationen abbilden
Am 04.12.08 schrieb Falk Zscheile: Am 4. Dezember 2008 14:32 schrieb Fabian Schmidt: Verstehe ich das richtig? -- Ich muss mir die bestehende Relation vom Server holen, diese mit den fehlenden Wegen anreichern und dann das ganze wieder zum Server hochladen? Ja. Du schickst dem Server die Datei so, wie sie am Ende aussehen soll, dieser ersetzt nur Timestamp und Nutzer. Etwas komplizierter wird es erst ab Version 0.6. Gegen Schaden kannst Du Dir die alte Version aufheben oder mit Hilfe der History die alte Version wiederherstellen. Bearbeiten brauchst Du nur die relation, damit solltest Du an den ways und nodes auch durch Änderungen nichts kaputt machen können. Gruß, Fabian.___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Hallo Jonas, John07 schrieb: Ich frag mich immer, wer wohl der erste Hersteller sein wird, der uns offiziell unterstützt bzw. ein OSM-Navi baut. Wir sollten mal eine Wette machen ;-) nunja, man müsste eine Art StartUp-Unternehmen gründen, einen Partner in Fernost finden und die Geräte dann hier auf den Markt bringen. Allerdings sind die Geräte bei uns mittlerweile so günstig, dass das nicht so einfach wäre, vorallem weil hier in DE ja noch Logistik, Händlerbeteiligung, CE und ElektroG draufkommen. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Tobias Wendorff schrieb: Hallo Jonas, John07 schrieb: Ich frag mich immer, wer wohl der erste Hersteller sein wird, der uns offiziell unterstützt bzw. ein OSM-Navi baut. Wir sollten mal eine Wette machen ;-) nunja, man müsste eine Art StartUp-Unternehmen gründen, einen Partner in Fernost finden und die Geräte dann hier auf den Markt bringen. Allerdings sind die Geräte bei uns mittlerweile so günstig, dass das nicht so einfach wäre, vorallem weil hier in DE ja noch Logistik, Händlerbeteiligung, CE und ElektroG draufkommen. Das wäre die andere Möglichkeit. Ich dachte aber ursprünglich an einen Hersteller der schon im Geschäft ist. Oder ein Elektronikhardwarehersteller, der ins Navigeschäft einsteigen will. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Garry schrieb: Was nützen ein paar Qudratkilomter perfekt erfasstes LKW-Routinggebiet wenn daneben noch ganze Orte und Städte fehlen. Hier ist der Auwand derzeit einfach an der falschen Stelle investiert. Wir wären immerhin der erste Hersteller, der so etwas überhaupt Pilotmäßig anbietet (außer speziell für LKWs gebaute Navis, die aber ein schweine Geld kosten). Ich denke, wenn man höhenbeschränkungen sieht, kann man diese ja auch direkt aufschreiben. Villeicht wäre es auch eine Idee, sich beim Fahren einen Camcorder rechts auf das Armaturenbrett zu stellen. Da kann man dann wirklich alles erfassen, ohne nachzudenken. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV Haltestellenverzeichnis
Hallo Michael, Michael Rathai schrieb: habe heute vom örtlichen Verkehrsbetrieb eine Liste der Bushaltestellen für osm bekommen inclusive GPS-Koordinaten, im Prinzip ein export aus deren Linienmanagementsystem, Format xls. cool. Kleines Script drum schreiben und dann ab zu OSM. Wenn Du hierbei Hilfe brauchst, helfe ich Dir gerne, da ich ähnliche Imports mit Eigen- und Fremddaten bereits durchgeführt habe. Jetzt brauche ich mal guten Rat, wie ich das am besten in osm importiere ohne die schon vorhandenen gemappten Einträge zu verdoppeln, also so eine Art update vorhandener nodes. Gibts das, geht das?? Nach großflächiger Meinung scheint wohl die beste Variante zu sein, die Nodes speziell zu markieren (fixme_busstop oder so) und dann einfach reinzuladen. Eventuell noch eine WIKI-Seite mit einer Information zu den Daten. Wenn ich daraus eine osm-Datei baue, die in josm lade, dann muss ich alles von Hand nacharbeiten, aber das würde ich gern vermeiden. Nach der Meinung vieler OSM-Mitglieder (eindeutig nicht meine Meinung) sollten solche Imports sich selbst regulieren, also wenn ein User einen solchen Node findet, soll er sinnvoll damit umgehen. Die Arbeit soll ja nicht an Dir, sondern an allen Usern haften bleiben. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetBug lässt sich nicht mehr sc hließen
Hab hier auch einen, der sich nicht schließen lässt, trotz mehrerer Versuche an verschiedenen Tagen etc. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
Ja genau! Denn ein Ortsschild-Polygon ist nicht praktikabel. Es besteht dann auch immer die Verwechslungsgefahr mit der Ortsgernze. Eine Relation wäre für kleine Orte Ok, aber alle Starßen von Berlin in eine Relation zu packen, dürfte auch nicht benutzerfreundlich sein. Dann müssten pro Stadtbezirk Relationen aufgebaut werden, die dann wieder in einer Superrelation zusammengefasst werden... Also ein tag an alle ways innerhalb der Ortsschildgrenze ist für alle Anwendungen sinnvoll (auch für maxspeed!). Es ist ja auch zu beachten, dass jeder Weg am Ortsschild aufgeteilt werden muss! Gruß, Stefan Torsten Leistikow schrieb: Noch viel einfacher ist es, den Weg nicht in eine Relation zu packen, sondern die Information einfach an jeden betroffenen Weg per Tag anzuhaengen. Das ist auch leichter zu kontrollieren und es kann auch nicht so leicht kaputt gehen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Tobias Wendorff schrieb: nunja, man müsste eine Art StartUp-Unternehmen gründen, einen Partner in Fernost finden und die Geräte dann hier auf den Markt bringen. Villeicht finden sich hier ja ein paar Sachkundige, die so ein Gerät von Grund auf entwickeln können. Es sollte dann natürlich komplett an OSM angepasst sein und möglichst die Fehler der Anderen ausbeulen. Dann kann man sich einen Produzenten in China suchen, der ein paar hundert Stück baut. Jedoch braucht man dazu erstmal Kunden. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Markus schrieb: Der Vertrag ist unterzeichnet. Das Projekt ist bis 31.3.2009 verlängert. Die Daten sind unterwegs. Herzlichen Glückwunsch meinerseits. Ich werde auf jeden Fall fleißig mitarbeiten, damit wir möglicht viel verarbeiten können. Am besten wäre es natürlich, man kann ALLES einpflegen, was man erkennen kann. Btw: Wie sieht es mit meinem Kachelvorschlag aus? Oder gibt es alternative Ideen? signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
André Reichelt schrieb: Ich denke, wenn man höhenbeschränkungen sieht, kann man diese ja auch direkt aufschreiben. Villeicht wäre es auch eine Idee, sich beim Fahren einen Camcorder rechts auf das Armaturenbrett zu stellen. Da kann man dann wirklich alles erfassen, ohne nachzudenken. Okay, wenn Du mit dem Auto mappen willst, sollten wir uns vielleicht erst mit einem New Alternative Technology-Hersteller kurzschließen und dann mit Solarkraft fahren :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] jre 6 update 11
Michael Rathai schrieb: seit der Installation des Java Runtime Environment Updates Version 6 update 11 unter XP schmiert JOSM sofort ab sobald ich irgendeinen der WMS-Server nutzen will. Habe nur das ewms-plugin installiert (ich weiss, dass das experimentell ist!!) Erst die Installation der vorherigen Version (jre 6 update 10) hat Abhilfe geschaffen. Hi, kann ich nicht bestätigen. JOSM 1096 java 1.6.0_11-b03 Win XP SP3 EWMS 11990 Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
André Reichelt schrieb: Herzlichen Glückwunsch meinerseits. Ich werde auf jeden Fall fleißig mitarbeiten, damit wir möglicht viel verarbeiten können. Am besten wäre es natürlich, man kann ALLES einpflegen, was man erkennen kann. Ich bete nur, dass die Bilder nicht im Sommer aufgenommen wurden, da man sonst die Straßen und Wege vor lauter Vegetation nicht sieht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Jedoch braucht man dazu erstmal Kunden. Gerät incl OSM-Karte 200 €: +1 Markus Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Du kannst Dir die Luftbilder 2007 für Regensburg doch z.B. hier http://stadtplan.regensburg.de/stadtplan.html ansehen! Stadtplan abwählen - Luftbilder (Orthofotos) - Bayern (2m Bodenauflösung) anwählen Aber Achtung, es gibt für Regensburg auch welche in sehr viel besserer Auflösung! Gruß, Stefan Tobias Wendorff schrieb: Ich bete nur, dass die Bilder nicht im Sommer aufgenommen wurden, da man sonst die Straßen und Wege vor lauter Vegetation nicht sieht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Stefan Dettenhofer (StefanDausR) schrieb: Aber Achtung, es gibt für Regensburg auch welche in sehr viel besserer Auflösung! Bei den 0,02m kann man schon ins Schwärmen bekommen. Naja, villeicht bekommen wir die ja irgendwann, wenn das die erhofften Vorteile für die LVA bringt. Immerhin könnten wir dann auch einen sehr genauen Grundrissplan machen. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Am Mittwoch 03 Dezember 2008 schrieb Florian Lohoff: On Wed, Dec 03, 2008 at 07:11:59PM +0100, Guenther Meyer wrote: ein node besteht aus einer id, koordinaten, und dem hoehen-tag. das ganze als kurzen way zu mappen erfordert zwei nodes und zusaetzlich den way mit dem tag. mehr als die doppelte datenmenge... Da ein way typischerweise eh reihenweise nodes hat ist die datenmenge ziemlich zu vernachlaessigen. Und so lange das datenmodell das zerschneiden des weges und damit duplizieren des namens und saemtlicher anderer tags fuer ein bridge, layer, maxspeed etc braucht muessen wir uns hier keine sorgen machen. Da eine beschraenkung immer eine strecke und NIE ein punkt ist ist es auch als solches zu taggen. falsch! eine unterfuehrung laesst sich problemlos als punkt vereinfachen, da die ausdehnung in diesem fall unwichtig ist. und was ist mit dingen wie gates oder bollards? das sind definitiv punktfoermige beschraenkungen! Und wenn du daten sparen willst dann mach dir generisch gedanken zum datenmodell. Diskussionen hats reichlich gegeben ... sicher waere das mehr als sinnvoll, aber das ist ein ganz anderes thema... man kann auch optimieren, ohne das datenmodell zu aendern. und genau das versuche ich. ein punkt auf einer strasse, der die bestimmte maximalhoehe angibt, reicht aus, um fuer einen lkw, der hoeher ist, ein unueberwindbares hindernis darzustellen (was es in der realitaet auch ist), und ihn davon abzuhalten, diesen weg zu benutzen. ein router wird genau dies beruecksichtigen. um das hoehenlimit darzustellen, benoetigt's genau einen punkt, an dem das icon positioniert wird. das ist vollkommen ausreichend. Dann mach es so - ich werde es anders machen das ist dein gutes recht. ich versuche nur, eine meiner meinung nach bessere loesung anzubieten. Restrictions sind bei OSM bisher alles way tags - nur weil was immer schon so gemacht wurde, heisst das nicht, dass man es nicht noch verbessern koennte. wenn jeder so denken wuerde, lebten wir immer noch in der steinzeit... 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] LKW-Routing (TV-Bericht)
Guenther Meyer schrieb: um das hoehenlimit darzustellen, benoetigt's genau einen punkt, an dem das icon positioniert wird. das ist vollkommen ausreichend. Dann mach es so - ich werde es anders machen das ist dein gutes recht. ich versuche nur, eine meiner meinung nach bessere loesung anzubieten. Ein Punkt wird nicht reichen! Stellt Euch vor, man befährt das Gebiet aus wiedrigen Umständen mittig. Dann gibt es ein Problem. Ich denke, dass wir das REAL untertunnelte Gebiet markieren sollten. Wenn wirklich irgendwo an nem Parkplatz nur oben ein Balken hängt, soll es auch nur ein Punkt sein. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
André Reichelt schrieb: Villeicht finden sich hier ja ein paar Sachkundige, die so ein Gerät von Grund auf entwickeln können. Es sollte dann natürlich komplett an OSM angepasst sein und möglichst die Fehler der Anderen ausbeulen. Klar, sowas haben wir ja aktuell - nennt sich Globalisierung. Die Know-How Länder (z.B. wir) entwickeln die Konzepte, das Design und vielleicht sogar die Algorithmen. China Co. (Tigerstaaten) produzieren sie dann. Allerdings haben wir ein Problem: Unser Know-How ist verdammt teuer - und auch die Produktion in Kleinserien ist verdammt teuer. Wenn Du alleine siehst, wie teuer die Gehäuseherstellung wäre, hättest Du schon keine Lust mehr. Dann kommt noch die Europäische Lotterie (ElektroG) dazu sowie möglicherweise irgendwelche Patentverletzungen, von denen Du bislang nichts weist. Dann kann man sich einen Produzenten in China suchen, der ein paar hundert Stück baut. Jedoch braucht man dazu erstmal Kunden. André, es gibt keine Lila-Kühe. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Am Donnerstag 04 Dezember 2008 schrieb Torsten Leistikow: Guenther Meyer schrieb: nein. eine bruecke beginnt und endet normalerweise weit vor bzw. nach der strasse, die sie ueberquert. abgesehen davon ist das layer tag nur fuer die optische darstellung relevant, und da ist es durchaus sinnvoll, das mit einem way zu machen. Ein layer-Tag gehoert sowohl an die obere als auch an die untere Strasse. nicht unbedingt. wenn ich das richtig verstanden habe, wird eine strasse ohne layer-angabe als layer=0 angenommen. drum sollte eigentlich das taggen einer der strassen reichen. Und es ist nicht (nur) fuer den Renderer da, sondern damit drueckt man auch aus, wie die Querung relativ zur Erdoberflaeche verlaeuft: Hier im Flachland gibt es die Variante, dass die Strasse mit der Bruecke fuer die Querung erhoeht wird, oder das die unterfuehrende Strasse abgesenkt wird (und natuerlich Mischformen). Wenn man das in OSM abbilden will, dann braucht man dafuer auch das layer-Tag. schon richtig. nur geht's hier um routing, und ich wuesste jetzt keinen grund, wozu man das layer-tag hier brauchen koennte. richtig, nur teil der strasse, die betroffen ist. falsch mal was (fälschlicherweise) verschoben wird, macht's eigentlich nichts aus, ob der punkt jetzt zwei meter vorher oder nachher kommt. die information, dass es dort ein hindernis gibt, bleibt ja erhalten. Warum sollte das spaetere verschieben eine Fehler sein? Kann ja durchaus eine verbesserung darstellen. drum war faelschlicherweise auch eingeklammert... Wenn der Punkt mit der Begrenzung nur Teil der betroffenen Strasse ist, dann werden da aber die Validator aufjaulen, weil man zwei Punkte direkt uebereinander hat, einer mit einer Hoehenbeschraenkung fuer die unterer Strasse und einer mit einer Gewichtsbeschraenkung fuer die obere Strasse. Das soll die Loesung sein? dann muss man den validator eben anpassen. es ist die meiner meinung nach einfachste loesung. Und wenn es dir auf ein paar Meter Genauigkeit nicht ankommt, dann kann man ja auch einfach einen Streckenabschnitt mit der Beschraenkung markieren. dann muesste es aber ganz genau stimmen, weil du sonst mit dem von florian lohoff angesprochenen beispiel probleme kriegen koenntest. 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] Luftbilder LVA Bayern - Vertrag unterschrieben
Stefan Dettenhofer (StefanDausR) schrieb: Du kannst Dir die Luftbilder 2007 für Regensburg doch z.B. hier http://stadtplan.regensburg.de/stadtplan.html ansehen! Stadtplan abwählen - Luftbilder (Orthofotos) - Bayern (2m Bodenauflösung) anwählen Komisch, ich bekomme da nur Bildchen in 1:10.000 und da kann ich noch nicht mal die Vegetation erkennen :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Warum muss da gleich einen eigene Hardware mit? Eine gute Software würde doch schon reichen, oder? NaviPOWM ist ja schon einmal ein guter Ansatz! Gruß, Stefan Tobias Wendorff schrieb: Markus schrieb: Jedoch braucht man dazu erstmal Kunden. Gerät incl OSM-Karte 200 €: +1 Markus Ich würde eine Null hinten dran setzen. Für 200 EUR bekommst Du bei einer 1.000er Serie gerade mal ein geeignetes Touchscreen-DPL. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Ja die haben für die 0,2m-Auflösung den Maßstab begrenzt, da es noch Luftbilder in besserer Qualität gibt! Stefan Tobias Wendorff schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Du kannst Dir die Luftbilder 2007 für Regensburg doch z.B. hier http://stadtplan.regensburg.de/stadtplan.html ansehen! Stadtplan abwählen - Luftbilder (Orthofotos) - Bayern (2m Bodenauflösung) anwählen Komisch, ich bekomme da nur Bildchen in 1:10.000 und da kann ich noch nicht mal die Vegetation erkennen :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Am Donnerstag 04 Dezember 2008 schrieb André Reichelt: Ein Punkt wird nicht reichen! Stellt Euch vor, man befährt das Gebiet aus wiedrigen Umständen mittig. Dann gibt es ein Problem. was meinst du bitte damit? 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
