Re: [OSM-legal-talk] License Use Case
Hi Frederik, Thank you very much for you previous answer ! (When you write picture ID, I presume that you mean an identifier of any kind used internally in the web server to identify a picture.) (When you write location, I presume that you mean the latitude longitude (not the address) where the picture has been taken.) Let us suppose (as you mentioned) that the web server contains an OSM derived database associating each picture identifier with the latitude longitude where the picture has been taken. Moreover, let us suppose that a user wants to keep private an address (and the latitude longitude of the address) he provides: - The user can still upload a picture through the web site to the web server, providing the address where the picture has been taken, - But the user can also indicate through the web site that the address (and the latitude longitude of the address) must not be published. As a consequence, such users might not want the OSM derived database (described above) to be published. Is there any solution to protect the privacy of such users while complying with the ODbL license ? Thank you very much for your help. Xavier ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Now: Wikiteam
On Sun, 07 Nov 2010 08:08:19 +0100 Matthias Meißer dig...@arcor.de wrote: Hi Elizabeth, no it's not. But if you have a look at http://wiki.openstreetmap.org/wiki/WikiProject_Cleanup you will see, that some major pages need to be updated and bring to another form. Labeling as stubs is just one tool for others to find pages that might need more attention. If the author of the page sees as nonsense, he is free to remove this label of course. Matthias so we get another set of edit wars? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Now: Wikiteam
2010/11/7 Elizabeth Dodd ed...@billiau.net: so we get another set of edit wars? Not necessarily. Just because two people may disagree doesn't automatically make that a war. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Now: Wikiteam
Maybe eventually we'll end up with two separate projects - one that edits the wiki and one that does the mapping (and ignores the wiki)? Maybe that's happening already? Cheers, Andy :-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Sat, 2010-11-06 at 22:58 -0400, Russ Nelson wrote: Apollinaris Schoell writes: I consider it improving osm by a human mapper according the spirit of the project instead a container full of imports with not much value. If a human surveys on ground or based on personal knowledge and image tracing it has 100 times more value than any imported data I have some sympathy for your position, but I was told explicitly by the New York State Department of Environmental Conservation that their shapefile is to be considered primary over the signs in the field. Thus, mapping NYS DEC Forest Lands in the field is 0 times more value than their authoritative shapefile, which I've imported. How do you know that the shapefile is correct, unless you survey on the ground? Just because their shapefile says a road travels 20m then turns and travels 50m, if the actual road travels 30m then turns and travels 40m, it doesnt matter what they consider 'primary' or 'authoritive', if its wrong. Or for example if a map says a cliff is in position x, if the cliff is actually in position y, you should correct that. This whole thing of trusting the data before your own eyes/knowledge, is what causes problems such as the Latin American issue discussed recently. I somehow think that if it came to a court, the on-the-ground signs would be taken as a primary source, over some mystery government coordinates. If we're only talking about administrative boundaries, thats a different story, as theres no easy way to verify that data on-the-ground, but just because some government departments data says the sky is green and the grass is blue, that doesnt mean it should be entered into the database, if someone surveys it and finds its wrong, otherwise OSM simply becomes a collection of other peoples unverified databases. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline in mapnik
On Sun, 2010-11-07 at 01:05 +0100, Vladimir Vyskocil wrote: I checked the shoreline last modification date with : wget --server-response --spider http://tile.openstreetmap.org/shoreline_300.tar.bz2 and the answer show : Last-Modified: Fri, 24 Sep 2010 23:44:09 GMT It's about 1 month and half ago !! Is this process broken ? Vlad. I think we went back to some older shapefiles after reports of a significant problem with one of more recent updates. I just updated the files with coastlines generated from the planet file this week. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Sun, Nov 7, 2010 at 6:28 PM, David Murn da...@incanberra.com.au wrote: If we're only talking about administrative boundaries, thats a different story, as theres no easy way to verify that data on-the-ground Since when is no easy way to verify equivalent to unable to be corrected? If the shapefile is wrong, the information in OSM should be corrected. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Osmosis exception
Do any of those paths have spaces in them? That might cause the issue. Also, are multiple drive letters involved? The osmosis.bat launch script appears to have an issue where it requires Osmosis to be on the same drive as the working directory. Brett On Sun, Nov 7, 2010 at 11:46 PM, Carsten Nielsen list_re...@toensberg.dkwrote: When extracting a OSM dataset for denmark from the geofabrik europe file, I use a line like this on my Windows 7 system call %OSMTOOLS%\Osmosis\osmosis-0.37\bin\osmosis.bat --read-bin %DATADIR%\europe.osm.pbf --bounding-polygon-0.6 file=%DATADIR%\CTN OSM DK mm.poly.txt --write-xml-0.6 file=%DATADIR%\denmark_mm.osm But I get en error like this Exception in thread main java.lang.NoClassDefFoundError: org/codehaus/classworlds/Launcher Caused by: java.lang.ClassNotFoundException: org.codehaus.classworlds.Launcher at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) Could not find the main class: org.codehaus.classworlds.Launcher. Program will exit. Any clues to what I might do wrong ? Carsten ___ 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] Google fumbles again in latin america
David Murn writes: On Sat, 2010-11-06 at 22:58 -0400, Russ Nelson wrote: Apollinaris Schoell writes: I consider it improving osm by a human mapper according the spirit of the project instead a container full of imports with not much value. If a human surveys on ground or based on personal knowledge and image tracing it has 100 times more value than any imported data I have some sympathy for your position, but I was told explicitly by the New York State Department of Environmental Conservation that their shapefile is to be considered primary over the signs in the field. Thus, mapping NYS DEC Forest Lands in the field is 0 times more value than their authoritative shapefile, which I've imported. How do you know that the shapefile is correct, unless you survey on the ground? Because the shapefile contains the listing of property that the DEC claims to own, and over which people are free to travel without fear of trespass. It's not possible for anyone to verify the shape of the data on the ground. The reason it's in OSM is because we have more attributes than the DEC has. Someone on the ground could mark the property as having a swimming area, where the DEC's data might not have that. THAT is verifiable on the spot, and THAT is why it belongs in OSM. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline in mapnik
On Nov 7, 2010, at 3:57 PM, Jon Burgess wrote: On Sun, 2010-11-07 at 01:05 +0100, Vladimir Vyskocil wrote: I checked the shoreline last modification date with : wget --server-response --spider http://tile.openstreetmap.org/shoreline_300.tar.bz2 and the answer show : Last-Modified: Fri, 24 Sep 2010 23:44:09 GMT It's about 1 month and half ago !! Is this process broken ? Vlad. I think we went back to some older shapefiles after reports of a significant problem with one of more recent updates. I just updated the files with coastlines generated from the planet file this week. Thank you Jon! Can I ask if it would be possible to include in those shapefiles a processed coastline that's just the outlines, rather than the tiled land area polygon? osm2pgsql doesn't import natural=coastline (a hardcoded exception) and sometimes it's useful to put lines on coastlines, for which the processed_p data isn't very well suited. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] TagWatch
Hoi Allen, Zoeken naar tags is mij geleerd om te doen via TagWatch: http://tagwatch.stoecker.eu/Netherlands/En/tags.html. In mijn zoektochten ontdekte ik echter TagWatch Advanced ;-): http://taginfo.openstreetmap.de/ Zien jullie na- of voordelen tov 'oude' TagWatch? Groet Robert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Forest Lake Mapping Party is coming up soon (Sat 20th September)
Less than two weeks to go now to our next mapping party at Forest Lake! Please let me know if you plan on attending, as it would make me sad to have to cancel another event, and you don't want that do you? Details on the event are below if you hadn't noticed them last time. - David On 2 November 2010 20:54, David Dean dd...@ieee.org wrote: Hi everyone, OSM mapping party propaganda follows. Please pass onto anyone you think might be interested. - David Calling all map-lovers, amateur cartographers, surveyors and cartophiles! Local OpenStreetMappers are having a mapping party soon, and we want your help. When: Saturday 20th November 2010 Agenda: 09:00 - 09:30 Breakfast at Elvis Grill Cafe 09:30 - 13:00 Mapping 13:00 - 14:00 Lunch at Forest Lake Tavern Details: http://wiki.openstreetmap.org/wiki/Forest_Lake_Mapping_Party_November_2010 OpenStreetMap is a collaboratively built free map of the world, with simple wiki-like editing; think ‘Wikipedia’, but for maps. The result is highly detailed digital maps, created and edited by local communities, that are free to reproduce without the normal commercial restrictions. It's a fun project to get involved with; you'll discover how maps are made and uncover the geographical secrets of your neighbourhood. Volunteers from all around Brisbane have already begun mapping the roads, footpaths and cycleways across the city, but now we need your help to improve our map by adding street details and amenities such as restaurants, parks, playgrounds and shops. For July, we will be mapping around Forest Lake. After beginning with a delicious breakfast, we will split up and spread out over the area to collect information for inclusion in OpenStreetMap. You are welcome to map however and wherever you want, but here are a few suggestions for things that other mappers like to collect: * Missing streets, footpaths and cycleways * Missing street names * Missing street facilities (traffic lights, pedestrian crossings, speed bumps, etc.) * Missing reserves, parks, schools and child-care centres * Missing amenities (water fountains, toilets, playgrounds, seats, shelters, etc.) * Details of shops/restaurants/pubs However, if you aren't sure what you can do, we'll be happy to provide ideas and help get you started. If you have a GPS device, including a GPS-enabled phone, bring it along, but you don’t need anything special to map - just a pen and paper will do. Blank maps for note-taking can easily be made available if prior notice is provided. After spending a couple of hours surveying we will rejoin at 13:00 for lunch and to debrief. If you have a laptop, bring it along and we'll show you how easy it is to use OpenStreetMap on your own computer. Internet access will be made available through shared mobile broadband (or bring your own). If you can’t or don’t feel like helping in the physical survey, or you just want to be social, please feel free to turn up for lunch anyway. We’ll be there between 13:00 and 14:00 and we’ll be happy to introduce you to OpenStreetMap, and maybe get you set up to map your local area. If you can come, please let David Dean know by Wednesday the 17th of September, so we can have some idea of how will be turning up on the day. Contact David Dean on 0407 151 912 to RSVP or for more information. (please let me know if you don't want these emails in future) -- David Dean Post-Doctoral Fellow, RP-SAIVT, QUT (me) http://www.davidbdean.com (saivt) http://www.bee.qut.edu.au/projects/saivt/ (post) Room S1101, GPO Box 2434, Brisbane, Australia 4001 (p) +61 7 3138 9329 (m) 0407 151 912 (CRICOS) 00213J -- David Dean Post-Doctoral Fellow, RP-SAIVT, QUT (me) http://www.davidbdean.com (saivt) http://www.bee.qut.edu.au/projects/saivt/ (post) Room S1101, GPO Box 2434, Brisbane, Australia 4001 (p) +61 7 3138 9329 (m) 0407 151 912 (CRICOS) 00213J ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Locata augmenting GPS in GPS hostile areas
An australian company which can provide gps signals inside buildings, urban canyons, etc., etc. http://www.abc.net.au/rn/scienceshow/stories/2010/3058425.htm See also http://www.locatacorp.com/technology.html ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-de] Behandlung von Waldwegen in Straßenli stenauswertungen
Hallo, Hier haben viele Waldwege Namen die auch ausgeschildert sind. Diese tauchen dann in der Straßenlistenauswertungen auf Florians Website http://osm.gt.owl.de/Strassenliste/ auf. Es handelt sich meistens um highway=track wie zum Beispiel hier in Bönnigheim der Alfred-Amann-Weg: http://osm.gt.owl.de/Strassenliste/output/405782/ Ich habe einige Waldwege mit Kommentar (;Waldweg) in die offizielle Straßenliste aufgenommen z.B. Sumpfweg;Waldweg, um die Fehler zu reduzieren. Das ist natürlich keinesfalls sinnvoll. Es ist viel Arbeit und gehört nicht in die Liste. Bekommt man irgendwann eine neue Liste hat man unnötige Arbeit. Wenn ich die Waldwege nicht aufnehmen habe ich bei der Auswertung ständig das Problem überzählige Straßen zu haben die man nicht zuordnen kann. Eine sinnvolle Auswertung ist nicht möglich. Lösung A: Es wäre gut wenn man diese Problemfälle irgendwie abhaken könnte. Man könnte vielleicht diese Wege als separate Sektion getrennt durch ein Schlüsselwort an die Liste anhängen. Lösung B: Ist es vielleicht sinnvoll alle highway=track aus der Auswertung auszunehmen. Lösung C: Oder ist das Auswertungsgebiet nur zu groß (Gemeindegrenze gegenüber der eigentlichen bebauten Stadtgrenze definiert über landuse=residential,commecial,u.s.w; oder admin_level=???). Dabei würden aber die außerhalb liegenden Aussiedlerhöfe/Weiler unter den Tisch fallen. Lösung D: Hat einer von Euch Ideen dazu? Was könnte man verbessern um dem Problem zu begegnen? MfG Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behandlung von Waldwegen in Straßenliste nauswertungen
Thomas Blumrich ht.blumr...@gmx.de [Sun, Nov 07, 2010 at 07:32:31AM CET]: [...] Lösung B: Ist es vielleicht sinnvoll alle highway=track aus der Auswertung auszunehmen. Highway=path vielleicht auch, aber davor haben die Götter eine Einigung darüber gestellt, wie man path und footpath gegeneinander abgrenzt. Das würde ich aber optional machen. Im Moment sieht der Automatismus ja so aus, dass der Ort in seinen Gemeindegrenzen voll erfasst wird. In vielen Fällen ist es sinnvoller, ein Rechteck nur um die bebauten Flächen zu ziehen. Wenn dann der eine oder andere Waldweg am Rand der Karte mit im Straßenverzeichnis auftaucht, fände ich es gar nicht schlecht. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 6. November 2010 17:24 schrieb Michael Buege mich...@buegehome.de: Zitat M∡rtin Koppenhoefer: Auch ich benutze JOSM auf dem eeePC und auf einem anderen Laptop mit Ubuntu. Leider ist das Edit (oder tools?) -Menu nicht vollständig zugänglich, wenn man mehrere Plugins installiert hat (endet ausserhalb des Bildschirms und scrollt nicht). Da lege ich mir bei Bedarf die Sachen per Werkzeugleistenanpassung oben in die Leiste. was allerdings nur ein workaround für den Bug ist, dass das Menu nicht mehr zugänglich ist, wenn es höher als der Bildschirm wird. Ich habe das Problem nicht nur auf den Netbook sondern auch auf dem Laptop mit 1024 vertikaler Auflösung, so dass es vermutlich einige Nutzer betreffen wird. -- Ticket erstellt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 7. November 2010 10:47 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: -- Ticket erstellt. https://josm.openstreetmap.de/ticket/5612 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 6. November 2010 12:11 schrieb Frederik Ramm frede...@remote.org: McDonald's etc. etc. werden damit hoffentlich reduziert. Wir haben leider viel zu viele wohlmeinende Eigenbroetler, die OSM mit ihrer Weisheit begluecken moechten, *ohne* vorher mit irgendjemandem darueber zu reden... Es gibt leider auch altgediente OSM-Mitglieder, die trotz mehrfacher Aufforderung sowohl in der dt. als auch auf der internationalen (tagging) Liste Ihren von praktisch allen anderen Mappern kritisierten weltweiten Massenedit nicht wieder rückgängig machen wollen, den sie parallel zur Diskussion entgegen aller Beiträge von anderen Mappern gemacht haben: http://www.openstreetmap.org/browse/node/660933760/history Es reicht nicht, darüber zu reden, man muss den anderen auch zuhören. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für innerorts / ausserorts?
am Sonntag, 7. November 2010 um 02:15 schrieb Garry: Gibt es inzwischen einen eigenen Tag für innerorts/ausserorts? Hier wird zone:traffic=DE:urban bzw. zone:traffic=DE:rural benutzt. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behandlung von Waldwegen in Straßenliste nauswertungen
Am 7. November 2010 07:32 schrieb Thomas Blumrich ht.blumr...@gmx.de: Hier haben viele Waldwege Namen die auch ausgeschildert sind. Ich habe einige Waldwege mit Kommentar (;Waldweg) in die offizielle Straßenliste aufgenommen z.B. Sumpfweg;Waldweg, um die Fehler zu reduzieren. Das ist natürlich keinesfalls sinnvoll. verstehe ich nicht. Wenn die Wege Namen haben, sollte man sie doch auch damit in OSM wiederfinden, von daher fände ich es durchaus sinnvoll, sie in die Auswertung einzubeziehen. Lösung B: Ist es vielleicht sinnvoll alle highway=track aus der Auswertung auszunehmen. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Hallo, M∡rtin Koppenhoefer wrote: Es gibt leider auch altgediente OSM-Mitglieder, die trotz mehrfacher Aufforderung sowohl in der dt. als auch auf der internationalen (tagging) Liste Ihren von praktisch allen anderen Mappern kritisierten weltweiten Massenedit nicht wieder rückgängig machen wollen, den sie parallel zur Diskussion entgegen aller Beiträge von anderen Mappern gemacht haben: http://www.openstreetmap.org/browse/node/660933760/history Es reicht nicht, darüber zu reden, man muss den anderen auch zuhören. Ja, mit der Aktion hat Nop sich nicht mit Ruhm bekleckert. Wenn die von mir skizzierten schaerferen Regeln in Kraft treten, wird es in solchen Faellen (wie Du richtig sagst, diskutieren reicht nicht - es muss auch eine weitgehende Zustimmung der Community nachgewiesen werden) eine offizielle Aufforderung zum Rueckgaengigmachen geben, und wenn der Botschreiber der nicht nachkommt, wird der Account gesperrt und der Edit von anderer Seite rueckgaengig gemacht. Aber im Augenblick ist Nop (auch wenn Dir dieser Fall jetzt vielleicht besonders aufgefallen ist) bloss einer von vielen, die sowas machen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 07.11.2010 10:50, schrieb M∡rtin Koppenhoefer: Am 7. November 2010 10:47 schrieb M∡rtin Koppenhoeferdieterdre...@gmail.com: -- Ticket erstellt. https://josm.openstreetmap.de/ticket/5612 some menu-items are not accessible if menu height vertical screen resolution. IMHO the menu should either become scrollable or it should expand to a second column. Als Entwickler denke ich wenn ich sowas lese: Hmmm, ist wohl zu faul mir überhaupt die problematischen Menüs zu nennen, welche Auflösung oder welches System er hat. Und dann erzählt er mir noch, wie ich das Problem für ihn lösen soll, obwohl JAVA das so garnicht kann - zumindest nicht das ich wüßte. Wieder so ein blödes Menuproblem, da gibt es bestimmt noch interessantere Tickets die ich mir mal anschauen kann ... Schon besser wäre: some menu-items are not accessible if menu height vertical screen resolution. I'm using Win XP with a 1024*768 screen where e.g. the last 3 items of the File menu are not accessible (I've attached a screenshot). Would it be possible that the menu becomes scrollable or that it expands to a second column in such a case? Dann kann man sich mal den Screenshot anschauen und ein erstes Interesse an dem Problem ist damit vielleicht geweckt. Immer dran denken: Das ist eine Bitte an einen Entwickler, ein Problem das du hast (und er wahrscheinlich nicht) für dich zu lösen. Gruß, ULFL P.S: Eine Garantie das so ein Ticket gefixt wird gibt es natürlich auch dann nicht, es macht es nur wahrscheinlicher ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 04.11.2010 23:03, schrieb Garry: Am 04.11.2010 22:37, schrieb Chris66: Am 04.11.2010 22:14, schrieb Garry: Man kann service auch als zweckgebundene Strasse betrachten die überwiegend (ich möchte nicht sagen ausschliesslich) eben einem speziellen Zweck dient, dabei aber durchaus auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. Genau. Siehe Zu- und Abfahrten zu Autobahnraststätten, die meist auch als service getaggt sind. Bin zwar kein Routerprogrammierer, aber einen Check ob eine service-Road mit einer route=ferry verbunden ist (um sie für's Routing intern höher zu stufen) stelle ich mir nicht schwierig vor. Wenn Du Dir gezielt dafür einen service-weg herauspickst sicher nicht. Nur musst Du in so einem Fall aber hunderte oder gar tausende von service untersuchen die in einem Korridor zwischen Start und Zielpunkt liegen und eventuell nur mit einer niederwertigeren Strasse an die Hauptadern angeschlossen sind. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Nur eine kleine Zusatzinfo, um diese Aussage noch zu untermauern. Kommt ein bisschen spät und ist jetzt mitten im Thread gelandet, wusste aber nicht, wo es sonst besser passen könnte. Habe mal Deutschland (atkuelle germany.osm) berechnet und die Services dabei berücksichtigt. Access-Tags wie motorcar=no oder private und so sind da bereits mit berücksichtigt - bzw. um diese reduziert. Nach der Segmentierung stoße ich auf folgende Zahl an Service-Weg-Segmenten (bidirektional): 1.191.982 (in Worten: EinsKommaEinsNeun Millionen!!!) Dies ist die Zahl an Wegen, die ein Router zusätzlich untersuchen muss, damit er über die o.g. Sonderlocken routen kann. Zum Vergleich die wenigen Autobahnen (ohne links): 39.636 (in Worten rund : VierzigTausend!!) Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 16
Wie jede Woche haben wir die Neuigkeiten aus dem OSM-Universum in der Wochennotiz zusammengetragen: http://blog.openstreetmap.de/2010/11/osm-wochennotiz-nr-16/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Viele Grüße, aighes -- View this message in context: http://gis.638310.n2.nabble.com/AIO-Routing-uber-Fahren-tp5452303p5714026.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiederbetätigung?
Am 07.11.2010 06:01, schrieb Walter Nordmann: oe fixed -v ? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 7. November 2010 11:15 schrieb Frederik Ramm frede...@remote.org: Hallo, M∡rtin Koppenhoefer wrote: Es gibt leider auch altgediente OSM-Mitglieder, die trotz mehrfacher Aufforderung sowohl in der dt. als auch auf der internationalen (tagging) Liste Ihren von praktisch allen anderen Mappern kritisierten weltweiten Massenedit nicht wieder rückgängig machen wollen, den sie parallel zur Diskussion entgegen aller Beiträge von anderen Mappern gemacht haben: http://www.openstreetmap.org/browse/node/660933760/history Es reicht nicht, darüber zu reden, man muss den anderen auch zuhören. Ja, mit der Aktion hat Nop sich nicht mit Ruhm bekleckert. Wenn die von mir skizzierten schaerferen Regeln in Kraft treten, wird es in solchen Faellen (wie Du richtig sagst, diskutieren reicht nicht - es muss auch eine weitgehende Zustimmung der Community nachgewiesen werden) eine offizielle Aufforderung zum Rueckgaengigmachen geben, und wenn der Botschreiber der nicht nachkommt, wird der Account gesperrt und der Edit von anderer Seite rueckgaengig gemacht. Inhaltlich (nicht bei der Umsetzung) war und bin ich in der Angelegenheit immer noch auf Nops Seite. Mit dem Abstand von einigen Monaten würde ich aber sagen, dass man hier wieder die bessere Einsicht (aus Sicht der Verfechter der Eintragung nur markanter Bäume) hätte handeln sollen, das bisherige Tag sich selbst (bzw. der neuen Mehrheit) überlassen und ein eigenes neues Tag einführen sollen. Es ist extrem schwierig den Punkt zu erkennen, wo man andere noch überzeugen kann und wo man entgegen der eigenen Überzeugung besser das Feld räumt. Automatische Edits können also durchaus auch positiv wirken, indem man den guten Datenbestand rettet und in ein neues Tag überführt. Unter Umständen schafft man dadurch Überschneidungen, aber lieber so, als einen (noch) relativ eindeutigen Datenbestand von der (neuen) Mehrheit entwerten zu lassen. Auch hier muss die Entwicklung natürlich kritisch beobachtet werden, aber ich sehe hier auch eine Möglichkeit Ungereimtheiten und Verkrustungen im Datenschema aufzubrechen und konsitenteren Lösungen zuzuführen. Das kann natürlich nicht heißen, dass jetzt jeden Monat ein anderer Bot irgendwelche Daten retten soll :-) Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 31. Oktober 2010 18:32 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 30. Oktober 2010 22:26 schrieb Martin Simon grenzde...@gmail.com: der es genau wissen will, kommt noch das jeweilige verkehrszeichen hinzu, z.b.: traffic_sign=z241 -- damit ist die sache eindeutig. ... Ich habe nichts gegen das taggen von Verkehrszeichen - aber bitte zusätzlich, als Referenz dafür, woher die international lesbaren Restriction-tags kommen, die auch am selben Weg pappen. ... leider länderspezifisch sind - taggst du eigentlich auch Z260 statt motor_vehicle=no?) DE:z260 oder was für ein Zeichen auch immer sollte man m.E. überhaupt nicht an ways hängen, sondern nur an Nodes. In Deutschland ist das vielleicht noch eher klar, aber prinzipiell ist es immer eine Interpretation, wo bzw. bis wo ein Schild gilt. Wenn man es auf einem Node an der Position taggt, mappt man die Realität (eine Art von Richtung wäre auch nicht schlecht, ist meistens aber überflüssig). Man kann es mit dem Grundsatz wir mappen nur die Wirklichkeit auch etwas übertrieben. Das Verkehrsschild hat meist eine über seine Position hinausgehende Bedeutung, die auch für OSM bedeutsam ist. Genau so wie man seinen Kopf beim Autofahren nicht ausschalten darf sollte man das auch nicht beim Mappen tun. Bei einem Parkplatz tragen wir ja auch nicht das Parkplatzschild ein sondern wenn möglich die Fläche auf der geparkt werden darf. Verkehrsschilder beziehen sich normalerweise auf die Straßen an denen sie stehen und daher gehört die Information auch an die Straße (unter Richtungsangabe für die sie gilt) und nicht (nur) daneben. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
leicht abweichend - die AIO vom 3.11. geht bei mir nicht Die Datei unter http://download.openstreetmap.de/aio/gmapsupp/gps_ready/gmapsupp_europe.img.zip vom 3.11.2010 ist 2.6GB groß Ausgepackt entsteht eine Datei die zwar nur knapp aber trotzdem noch kleiner als 4GB ist: 7Zip packt die zwar aus, ein Nüvi 1390T erkennt die ausgepackte Datei aber nicht - und mit OpenSuse kann ich sie gar nicht erst auspacken - die Basemap (also ohne die Extras) funktioniert aber. Mal sehen, wie die nächste Version in ein paar Tagen funktioniert. Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 11:58, schrieb aighes: Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Ich denke je mehr man da berücksichtigen muss um so weniger lohnt sich der Aufwand des herausrechnens. Und unter Umständen muss man dann auch noch auf Kombinationen achten die sich Gegenseitig aufheben oder nur in Kombination Sinn machen... Ganz schön viel Aufwand für die Vergleichsweise sehr geringe Anzahl an Fähr- und Autozugverbindungen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Schorschi schrieb: leicht abweichend - die AIO vom 3.11. geht bei mir nicht [Quoting repariert] Sven Geggus schrieb: http://download.openstreetmap.de/aio/gmapsupp/gps_ready/gmapsupp_europe.img.zip vom 3.11.2010 ist 2.6GB groß Ausgepackt entsteht eine Datei die zwar nur knapp aber trotzdem noch kleiner als 4GB ist: 7Zip packt die zwar aus, ein Nüvi 1390T erkennt die ausgepackte Datei aber nicht - und mit OpenSuse kann ich sie gar nicht erst auspacken - Das (ent)Packprogramm OpenSuse kannte ich bisher noch nicht. die Basemap (also ohne die Extras) funktioniert aber. Sind die Küstenregionen unter Wasser oder normal? Die Mapsource-basemap Europa vom 03.11. und vorhergehende waren landunter. malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 7. November 2010 12:46 schrieb Falk Zscheile falk.zsche...@googlemail.com: Verkehrsschilder beziehen sich normalerweise auf die Straßen an denen sie stehen und daher gehört die Information auch an die Straße (unter Richtungsangabe für die sie gilt) und nicht (nur) daneben. Ich sehe das genauso: wenn irgendwo ein Maxspeed Schild steht, dann gehört die maxspeed-Information natürlich an den Way (key maxspeed). Genauso, wenn ein Weg gesperrt ist, etc. Aber die Information über ein Verkehrsschild (key:traffic_sign) gehört m.E. eben nicht an den Weg, weil man genau damit den Wert der Aussage oft wieder zerstört (zumindest, wenn man nicht zusätzlich den Node setzt): bei einem Maxspeed, aber auch bei einem gesperrt für Fzg. aller Art, ist es oft nämlich nicht genau klar, bis wo das Schild wirklich gilt, und gerade dort hilft es ungemein, wenn man die einzelnen Schilder (an ihrer Position als Nodes) in die db bringt. Das meinte ich. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiederbetätigung?
Am 06.11.2010 22:24, schrieb Robert Kaiser: Johann H. Addicks schrieb: Hat da jemand Österreich an Deutschland angeschlossen? Umgekehrt, Deutschland an Österreich. :P Aber bitte ohne Ba-Wü, wir haben schon anderes vor: http://www.stuttgarter-nachrichten.de/inhalt.stuttgart-21-bunter-s21-protest-in-berlin.891b5134-f068-4488-93d8-4ace415eac06.html Die erste Aktion führt ein paar der Demonstranten zur Schweizer Botschaft. Vorneweg Funk und der Kabarettist Peter Grohmann. Ich will vorsorglich den Antrag stellen, dass Baden-Württemberg ein Schweizer Kanton wird, erklärt er mit einem Augenzwinkern. !!! Wichtiger jedoch ist für beide der Brief an den Schweizer Bundesrat Moritz Leuenberger. Sie haben uns etwas voraus, sagt Funk dem Sprecher Heinrich Maurer, bei Großprojekten führen sie einen Volksentscheid durch, und sie haben ein Gesamtkonzept im Eisenbahnverkehr. Beide erhoffen sich Hilfe von der Schweiz für ihr Anliegen: Denn kommt Stuttgart 21, dann werden sie abgehängt. Maurer sagt, er werde den offenen Brief der S-21-Gegner entgegennehmen und den zuständigen Stellen zuleiten. Und man empfängt das Ländle offenbar gerne im Helvetischen Bund: http://www.welt.de/politik/ausland/article8001661/SVP-will-Baden-Wuerttemberg-der-Schweiz-angliedern.html ... forderte die Regierung in Bern auf, den verfassungsrechtlichen und gesetzlichen Rahmen dafür zu schaffen, dass „grenznahe Regionen in der Form neuer Kantone in die Schweiz integriert werden können, wenn die Mehrheit der dortigen Bevölkerung ein solches Begehren stellen würde“. Also bitte schon mal die Grenzen in OSM anpassen, ist alles nur noch eine Formsache ... ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 7. November 2010 13:11 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 7. November 2010 12:38 schrieb Falk Zscheile falk.zsche...@googlemail.com: Es ist extrem schwierig den Punkt zu erkennen, wo man andere noch überzeugen kann und wo man entgegen der eigenen Überzeugung besser das Feld räumt. wobei die diversen Beiträge, auch auf tagging einem da durchaus ganz brauchbare Anhaltspunkte geben könnten. Automatische Edits können also durchaus auch positiv wirken, indem man den guten Datenbestand rettet und in ein neues Tag überführt. sicher, aber wohl kaum, indem man das Gegenteil macht, und alles, was einem nicht passt, mit einem neuen Tag versieht. Vor allem, wenn diejenigen, die einen interessieren, anzahlmäßig in der Minderheit sind. Wie gesagt, die Situation war schwer einzuschätzen. Im übrigen wäre ich auch hier vorsichtig mit Begriffen Mehrheit/Minderheit. Das klingt immer toll, weil man der eigenen Meinung damit mehr Gewicht verleihen kann, aber wenn ich mich an den entsprechenden Thread recht erinnere waren die Nodes, um die sich Nop sorgen gemacht hat, nicht eindeutig in der Minderheit bzw. sind es erst durch gewisse Massenedits geworden. Gerade daran hatte sich ja der Streit auch entzündet. Also versuchen wir mal ich hatte damals aber recht außen vor zu lassen und schauen lieber, ob wir ein paar sinnvolle Lehren daraus ziehen können. Unter Umständen schafft man dadurch Überschneidungen, aber lieber so, als einen (noch) relativ eindeutigen Datenbestand von der (neuen) Mehrheit entwerten zu lassen. das halte ich hingegen für ein extrem schwieriges Feld: zu bewerten, inwieweit man automatisch, also ohne die einzelnen Einträge anzusehen, neue Tags vergeben kann. Weil eben gerade das automatische Taggen von Objekten mit falschen Werten eine der ganz verpönten Aktionen ist. Da keiner ein Interesse hat falschen Daten in die Datenbank einzupflegen halte ich einen solchen Vorwurf/Argument für müßig. Über Methodik kann man streiten, wird aber in der Regel zu keinem Ergebnis kommen, weil wir eben keine Instanz haben, die über richtig oder Falsch entscheidet. Wenn, um am Beispiel zu bleiben, Nop der Meinung war, dass er die natural=tree herausfiltern kann, die seinem Verständnis/ seiner Definition entsprechen, warum soll er sie dann nicht unter einem anderen neuen und eindeutig definierten Tag wieder in die Datenbank einspeisen können. Andere Programme werden dadurch nicht beeinträchtigt und er kann seine Karte weiterhin mit der Funktionalität anbieten, die er sich wünscht. Das bisherige Tag kann diese Funktionalität nicht mehr gewährleisten, da sich hier ein Bedeutungswandel bzw. anderes Verständnis in der Diskussion abgezeichnet hat. Sollten Fehler in seinen extrahierten Daten sein, so vertrauen wir auf einfach auf unsere Schwarmintelligenz. Die wird die Fehler früher oder später berichtigen. So betrachtet hat auch die Eigenbrödelei beim Datenschema, die OSeaM manchmal vorgeworfen wird, einen Vorteil. Sie behalten leichter die Deutungshoheit und ersparen sich den Stress, den Nop im Zusammenhang mit seiner Wanderkarte und natural=tree hatte. Ich plädiere damit aber natürlich nicht, für ein zukünftiges nop:wanderkarte:natural=tree als Tag :-) Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
schrieb malenki, am 07.11.10 13:10: Sind die Küstenregionen unter Wasser oder normal? Die Mapsource-basemap Europa vom 03.11. und vorhergehende waren landunter. Da es (noch) keine Deutschlandkartendatei gibt habe ich mir mal die von den Kanaren geschnappt und da sind alle Bereiche, die eine gewisse Landhöhe unterschreiten landunter, also in blau. Es gibt auch keine Küstenlinie. Cheers, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
SteMo schrieb: Da es (noch) keine Deutschlandkartendatei gibt habe ich mir mal die von den Kanaren geschnappt und da sind alle Bereiche, die eine gewisse Landhöhe unterschreiten landunter, also in blau. Es gibt auch keine Küstenlinie. Das befürchtete ich. Danke fürs Nachschauen. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 11:58, schrieb aighes: Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Viele Grüße, aighes Hallo Aighes, nein, nur grob reduziert. Könnte das aber mal testen. Hast du da noch so'n paar von der Sorte auf Ex in Petto? Ich sehe da z.B. noch driveway, emergency_access oder drive-through. Ich sach ma so: Wenn man den ganzen Service-Schlonz, der wirklich nur zur Milchkanne führt so begrenzen könnte, würde das die Menge erheblich reduzieren. Ich bin also noch optimistisch. Gefühlt würde ich jetzt mal sagen, so bis 200.000 könnte das schon wieder einigermaßen erträglich werden. Parallel denke ich gerade über eine Mischform aus menschlicher Mustererkennung und Rohdaten nach. So'ne Art Critical-Region-Editor oder so..., wo dann bestimmte Dinge einfach genauer betrachtet werden. Hätte auch den psychologischen Vorteil, dass sich hier ein Mensch dem Computer überlegen fühlen darf. ;-) Gruß, CM ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Hallo, Carsten Moeller wrote: 1.191.982 (in Worten: EinsKommaEinsNeun Millionen!!!) Dies ist die Zahl an Wegen, die ein Router zusätzlich untersuchen muss, damit er über die o.g. Sonderlocken routen kann. Das ist doch aber nur dann problematisch, wenn man einen mangelhaften (oder sagen wir mal: einen altertuemlichen) Algorithmus verwendet. Ein moderner, optimierter Algorithmus a la Contraction Hierarchies steckt das locker weg - siehe z.B. Monav, das selbst auf einem schwachbruestigen Mobilprozessor in Bruchteilen einer Sekunde quer durch Europa routet. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 13:05, schrieb Garry: Am 07.11.2010 11:58, schrieb aighes: Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Ich denke je mehr man da berücksichtigen muss um so weniger lohnt sich der Aufwand des herausrechnens. Und unter Umständen muss man dann auch noch auf Kombinationen achten die sich Gegenseitig aufheben oder nur in Kombination Sinn machen... Ganz schön viel Aufwand für die Vergleichsweise sehr geringe Anzahl an Fähr- und Autozugverbindungen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Garry, da gibt es so'n tag namens access=destination, was zwar im Deutschen als Anlieger frei übersetzt wird, meines Erachtens im Englischen als auch Allgemeinen durchaus eine andere Interpretation zulassen würde. Was ist Deine Meinung hierzu? Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiederbetätigung?
Hallo, Am Sonntag 07 November 2010 schrieb Andreas Labres: Wie schon im anderen Thread geschrieben, können sich die Mapnik-Style-Hüter offenbar nicht vorstellen, daß man Grenzen als Multipolygone taggt... Also bei den andmin_level=2-Relationen gibt es mit Stand 31.10.2010 25 Relationen, die ein Multipolygon sind: 16239 Österreich 47796 Die Niederlande 51477 Bundesrepublik Deutschland 53293 Mazedonien 80500 Australien 90689 Rumänien 108089 Ecuador 148837 Kanada 174737 Türkei 192307 Griechenland 307866 Papua-Neuguinea 547469 Bahamas 547479 Turks- und Caicosinseln 550725 St. Vincent und die Grenadinen 550727 Grenada 550728 St. Lucia 555017 Jamaika 555717 Trinidad und Tobago 556706 Neuseeland 571178 Kiribati 571747 Fidschi 571771 Marshallinseln 571802 Föderierte Staaten von Mikronesien 571804 Nauru 571805 Palau Ist es denn den Mapnik-Sylte-Hütern schon mitgeteilt worden, daß es doch Grenzen mit type=multipolygon gibt? Denn diese Grenzen jetzt umzustellen auf type=boundary wäre Taggen für Mapnik was ja nicht Sinn der Übung sein kann. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 14:59, schrieb Frederik Ramm: Hallo, Carsten Moeller wrote: 1.191.982 (in Worten: EinsKommaEinsNeun Millionen!!!) Dies ist die Zahl an Wegen, die ein Router zusätzlich untersuchen muss, damit er über die o.g. Sonderlocken routen kann. Das ist doch aber nur dann problematisch, wenn man einen mangelhaften (oder sagen wir mal: einen altertuemlichen) Algorithmus verwendet. Ein moderner, optimierter Algorithmus a la Contraction Hierarchies steckt das locker weg - siehe z.B. Monav, das selbst auf einem schwachbruestigen Mobilprozessor in Bruchteilen einer Sekunde quer durch Europa routet. Bye Frederik Hallo Frederik, das klingt auf jeden Fall spannend. Druck mir gerade mal eine Diplomarbeit ausm Netz dazu aus und werde das gleich mal studieren. So weit ich ich das in der Kürze überblicke, beschäftigt sich das Thema sehr viel mit der Thematik der Reduktion von Informationen, bzw. dem Multilevel. Sowas ähnliches habe ich bei mir auch eingebaut. Von Lissabon nach Moskau benötigt meine Kiste derzeit ca. 3 Sekunden. Das allerdings auch nur unter Verwendung bestimmter Annahmen. z.B. Multilevel und so. Aber ich will mich da jetzt nicht zu weit aus dem Fenster lehnen. Erstmal lesen, was da so alles steht. Vielleicht bin ich hinterher ja schlauer, was durchaus kein Nachteil wäre ;-) Weißt Du zufällig, ob das schon mal jemand auf OSM-Daten losgelassen hat? Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiederbetätigung?
On 07.11.10 15:13, Carsten Gerlach wrote: 16239 Österreich 47796 Die Niederlande 51477 Bundesrepublik Deutschland Bei der deutsch-niederl. Grenze habe ich es nicht beobachtet, aber so dem Anschein nach ist das Problem (wohl dort wo neu gerendert wurde) ähnlich. Ist es denn den Mapnik-Sylte-Hütern schon mitgeteilt worden, daß es doch Grenzen mit type=multipolygon gibt? Ich habe ein Mail an Steve Chilton geschrieben, ich hab keinen Durchblick in den Styles, um das wirklich verifizieren zu können... vielleicht hat den wer und kann einen bugreport machen... Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiederbetätigung?
Am 07.11.2010 16:12, schrieb Andreas Labres: Ist es denn den Mapnik-Sylte-Hütern schon mitgeteilt worden, daß es doch Grenzen mit type=multipolygon gibt? Schaut man da überhaupt die Relationen an und wenn ja, warum? Via Relation muss man ja jedes Grenzsegment x-mal anschauen von der Relation Deutschland, Relation Österreich, ... bis runter zur Relation Hintertupfinger Ortsteil Kleinkleckersweiler ... Zum rendern wäre doch das Wegstück besser, Relation nur für ist in-Fragen. Ich habe ein Mail an Steve Chilton geschrieben, ich hab keinen Durchblick in den Styles, um das wirklich verifizieren zu können... vielleicht hat den wer und kann einen bugreport machen... Nicht wirklich großen Durchblick. Ich sehe da drin zwar die Abfragen nach admin_level = ... und boundary = administrative Und das haben alle Grenzsegmente und auch Relationen korrekt gesetzt. Wie Mapnik Relationen verarbeitet und wie die zu Grenzen speziell, wenn überhaupt, finde ich darin nicht ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiederbetätigung?
Am 07.11.2010 16:30, schrieb Heiko Jacobs: Schaut man da überhaupt die Relationen an und wenn ja, warum? Via Relation muss man ja jedes Grenzsegment x-mal anschauen von der Relation Deutschland, Relation Österreich, ... bis runter zur Relation Hintertupfinger Ortsteil Kleinkleckersweiler ... Zum rendern wäre doch das Wegstück besser, Relation nur für ist in-Fragen. Du kannst ja Flüsse in das Boundary-MP packen, ohne ein boundary-Tag am waterway. Deshalb muss Mapnik natürlich die Relationen berücksichtigen. Und so wie ich das sehe werden die Grenzen umso fetter gemalt in je mehr Relations sie Member sind Beispiel: http://www.openstreetmap.org/?lat=56.44lon=16.33zoom=7layers=M die beiden Inseln Bornholm (mitte unten) und Gotland (mitte oben) sind identisch am Way getaggt. admin_level: 2 border_type: territorial boundary: administrative maritime: yes Gotland ist allerdings Member von 4 Relationen, Bornholm nur von einer. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Hallo, Carsten Moeller wrote: Weißt Du zufällig, ob das schon mal jemand auf OSM-Daten losgelassen hat? Ja, klar, beim Monav ist das doch alles schon dabei, inkl. Datenaufbereitung und so (schau mal auf die routing-Liste). Die standalone-Version des Algorithmus gibt es auch als Open Source, und eine Demo ist auf routingdemo.geofabrik.de zu sehen (derzeit mit einem aelteren Daten-Ausschnitt fuer Westeuropa - das ist eine VM mit 2 GB RAM, da geht ganz Europa nicht drauf). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 07.11.2010 13:16, schrieb M∡rtin Koppenhoefer: setzt): bei einem Maxspeed, aber auch bei einem gesperrt für Fzg. aller Art, ist es oft nämlich nicht genau klar, bis wo das Schild wirklich gilt, dann hilft ein Blick in die StVO :-) sollte jeder der einen Führererschein besitzt ja mal gemacht haben Eine Geschwindigkeitsbegrenzung gilt bis an die nächste Kreuzung oder explizite Aufhebung der Begrenzung je nach Typ der angezeigten Begrenzung. Bei Tragfähigkeitsbegrenzungen ist es ähnlich. Eine vergessene oder fehlendes Schild für die Aufhebung einer 7,5t sehe ich persönlich nicht besonders kritisch, hier ist dann etwas Köpfchen gefragt. und gerade dort hilft es ungemein, wenn man die einzelnen Schilder (an ihrer Position als Nodes) in die db bringt. Das Schild ergibt sich von selbst wenn ein Router die Nodes mit der Start- und der Endposition findet. Dann wäre eine weitere Info wegen dem Schild einfach nur unnötige Daten. Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 7. November 2010 11:41 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Am 07.11.2010 10:50, schrieb M∡rtin Koppenhoefer: Hmmm, ist wohl zu faul mir überhaupt die problematischen Menüs zu nennen, welche Auflösung oder welches System er hat. Ich hatte gedacht, dass es a) keine Rolle spielt, welche Auflösung es ist, da ich das Problem sowohl bei 1024x600 als auch bei 1376x1024 habe. Ich habe versucht, das Thema so kurz wie möglich zu beschreiben, weil ich dann den Entwicklern am wenigsten Zeit raube, aber nach Deinem Hinweis habe ich nochmal ein paar Angaben ergänzt. Das ganze passiert unter JAVA, Sun auf Ubuntu 10.04. Wieder so ein blödes Menuproblem, da gibt es bestimmt noch interessantere Tickets die ich mir mal anschauen kann ... klar, ist nur ein Hinweis, dass da was nicht funktioniert, und dass man daher die Software nur eingeschränkt nutzen kann, vor allem als Anfänger, wo man die shortcuts nicht kennt. Keine Forderung, das schnell zu beheben, erst recht nicht an Entwickler, die das Thema Menus nicht interessiert. Schon besser wäre: some menu-items are not accessible if menu height vertical screen resolution. I'm using Win XP with a 1024*768 screen where e.g. the last 3 items of the File menu are not accessible (I've attached a screenshot). ich weiss nicht, wie viele Items mir fehlen, weil ich sie nicht sehe. Die Screenauflösungen habe ich ergänzt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behandlung von Waldwegen in Straßenlis tenauswertungen
2010/11/7 Thomas Blumrich ht.blumr...@gmx.de Hallo, Hier haben viele Waldwege Namen die auch ausgeschildert sind. Diese tauchen dann in der Straßenlistenauswertungen auf Florians Website http://osm.gt.owl.de/Strassenliste/ auf. Es handelt sich meistens um highway=track wie zum Beispiel hier in Bönnigheim der Alfred-Amann-Weg: http://osm.gt.owl.de/Strassenliste/output/405782/ Ich habe einige Waldwege mit Kommentar (;Waldweg) in die offizielle Straßenliste aufgenommen z.B. Sumpfweg;Waldweg, um die Fehler zu reduzieren. Das ist natürlich keinesfalls sinnvoll. Es ist viel Arbeit und gehört nicht in die Liste. Bekommt man irgendwann eine neue Liste hat man unnötige Arbeit. Wenn ich die Waldwege nicht aufnehmen habe ich bei der Auswertung ständig das Problem überzählige Straßen zu haben die man nicht zuordnen kann. Eine sinnvolle Auswertung ist nicht möglich. Ich verstehe das Problem nicht. Das Ziel bei diesen Auswertungen ist es, die Straßen in der Liste alle in OSM zu haben und nicht die Straßen in OSM alle in der Liste zu habe. Mehr Straßen in OSM als in der Liste wird man sehr häufig haben; es ist ja auch sinnvoll inoffizielle aber ausgeschilderte Straßen- und Wegnamen auch mit name=* zu erfassen. Lösung B: Ist es vielleicht sinnvoll alle highway=track aus der Auswertung auszunehmen. Ganz schlechte Idee! Dann wird man in ganz vielen Orten plötzlich fehlende Wege haben. Ich kenne sogar Fälle, da haben die Zuwege zu ein paar Hauseingängen (highway=path) eigene, von der Stadt vergebene Straßennamen - mit eigenen Hausnummern! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Schachbrettwälder in Mapnikkarte
Hallo! Mir ist gerade die kreative Waldgestältung auf der Mapnikkarte in diesem Bereich aufgefallen: http://www.openstreetmap.org/?lat=50.928lon=8.104zoom=10layers=O Weiß jemand was da kaputt ist? bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Schachbrettwalder-in-Mapnikkarte-tp5714568p5714568.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schachbrettwälder in Mapnikkarte
Am 07.11.2010 17:52, schrieb NopMap: Mir ist gerade die kreative Waldgestältung auf der Mapnikkarte in diesem Bereich aufgefallen: http://www.openstreetmap.org/?lat=50.928lon=8.104zoom=10layers=O Weiß jemand was da kaputt ist? Mapnik jedenfalls nicht, allenfalls der Osmarender LowZoom Algorithmus. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schachbrettwälder in Mapnikkarte
mapnik auf jeden fall nicht. ist die karte von unserm freund osmar ;) - Der Usus von Xenologismen ist auf ein Minimum zu reduzieren. -- View this message in context: http://gis.638310.n2.nabble.com/Schachbrettwalder-in-Mapnikkarte-tp5714568p5714580.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 07.11.2010 17:47, schrieb M∡rtin Koppenhoefer: ich weiss nicht, wie viele Items mir fehlen, weil ich sie nicht sehe. Die Screenauflösungen habe ich ergänzt. Mir ging es nicht primär um diesen speziellen Eintrag, sondern darum wie sowas auf der anderen Seite ankommen kann (auch ein Entwickler hat mal nen schlechten Tag ;-), wie man es besser machen kann - und warum das auch für den Eintragenden sinnvoll ist. Wenn du einen Eintrag schreibst der aus deiner Sicht sinnvoll ist, beim Entwickler aber trotzdem nichts passendes ankommt und er den deswegen zumacht ist ja nur auf beiden Seiten Arbeit entstanden die beiden nicht wirklich was bringt (und sogar eher Frust erzeugt). Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Moin, leicht abweichend - die AIO vom 3.11. geht bei mir nicht 7Zip packt die zwar aus, ein Nüvi 1390T erkennt die ausgepackte Datei aber nicht - und mit OpenSuse kann ich sie gar nicht erst auspacken - Das (ent)Packprogramm OpenSuse kannte ich bisher noch nicht. du hast hoffentlich den Smilie vergessen, hab halt das Standard-Programm, das in der Opensuse 11.3 für KDE eingestellt ist benutzt und weiß nicht, wie es heißt - ich glaube ARK; mit unzip auf der Kommandozeile geht's übrigens auch nicht. die Basemap (also ohne die Extras) funktioniert aber. Sind die Küstenregionen unter Wasser oder normal? Die Mapsource-basemap Europa vom 03.11. und vorhergehende waren landunter. hab gerade nachgeschaut: meine aktuelle Basemap ist vom 3.11. und hat auch Landunter - z. B. bis knapp vor Diepholz, Hamburg liegt komplett im Wasser ... und, gerade gemerkt: wenn ich versuche, bei der Basemap rauszuzoomen - auf dem Maßstab unten rechts steht z. B. 30 km - dann stürzt der nüvi 1390 nach ein paar Minuten (ohne dass ich irgendetwas mache), während er versucht, die Kacheln zu laden, ab - vermutlich ist er überfordert, weil ich für Details das Maximum eingestellt habe ... Gruß, Schusch PS zum Thema zitieren: [Quoting repariert] war wohl nur der zu lange Link - dein Quoting ist übrigens ganz schlecht zu lesen bei mir, da du vor jeder von dir geschriebenen Zeile auch ein Quotingzeichen hast ... und du zitierst ja nicht, sondern schreibst was neues ... da muss ich dann immer suchen, wo jetzt der neue Text steht. Zur Verdeutlichung hier ein Vollzitat (schau's dir mal als unformatierten Text an, dann siehst du, was ich sehe): Schorschi schrieb: leicht abweichend - die AIO vom 3.11. geht bei mir nicht [Quoting repariert] Sven Geggus schrieb: http://download.openstreetmap.de/aio/gmapsupp/gps_ready/gmapsupp_europe.img.zip vom 3.11.2010 ist 2.6GB groß Ausgepackt entsteht eine Datei die zwar nur knapp aber trotzdem noch kleiner als 4GB ist: 7Zip packt die zwar aus, ein Nüvi 1390T erkennt die ausgepackte Datei aber nicht - und mit OpenSuse kann ich sie gar nicht erst auspacken - Das (ent)Packprogramm OpenSuse kannte ich bisher noch nicht. die Basemap (also ohne die Extras) funktioniert aber. Sind die Küstenregionen unter Wasser oder normal? Die Mapsource-basemap Europa vom 03.11. und vorhergehende waren landunter. malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 11:58, schrieb aighes: Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Viele Grüße, aighes Hab jetzt mal 'n bisschen mehr ausgeklammert. Komme jetzt auf: 754.631 Gefühlt: Immer noch zu viele! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 7. November 2010 18:46 schrieb Carsten Moeller cmindivid...@gmx.de: Am 07.11.2010 11:58, schrieb aighes: Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Viele Grüße, aighes Hab jetzt mal 'n bisschen mehr ausgeklammert. Komme jetzt auf: 754.631 parking_aisle und driveway sind ziemlich sicher OK, alley ist ja aber gerade eine Straße, von daher würde ich die gar nicht unbedingt rausnehmen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 17:04, schrieb Frederik Ramm: Hallo, Carsten Moeller wrote: Weißt Du zufällig, ob das schon mal jemand auf OSM-Daten losgelassen hat? Ja, klar, beim Monav ist das doch alles schon dabei, inkl. Datenaufbereitung und so (schau mal auf die routing-Liste). Die standalone-Version des Algorithmus gibt es auch als Open Source, und eine Demo ist auf routingdemo.geofabrik.de zu sehen (derzeit mit einem aelteren Daten-Ausschnitt fuer Westeuropa - das ist eine VM mit 2 GB RAM, da geht ganz Europa nicht drauf). Bye Frederik Hmmm... ich hab jetzt in der Kürze der Zeit noch nicht viel darüber gelesen... Hätte da aber mal ein paar Kernfragen, da du ja an der Quelle sitzt. (Die Fragen beziehen sich auf einen herkömmlichen, etwas älteren Rechner mit sagen wir mal 2 Gig RAM, und ein paar Herz Taktgeschwindigkeit OHNE VM) a) Ist ein Preprocessing über europe.osm möglich - Wie lange dauert sowas? b) Werden OneWays berücksichtigt? c) Sind die Turning-Restrictions mit drin? d) Bevor ich jetzt lange suche: Gibt's einen Link zu der OpenSource-Bibliothek? Gruß und vorab schon mal -Danke für die Infos- Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schachbrettwälder in Mapnikkarte
Chris66 schrieb: Am 07.11.2010 17:52, schrieb NopMap: Weiß jemand was da kaputt ist? Mapnik jedenfalls nicht, allenfalls der Osmarender LowZoom Algorithmus. Ab wann ist Zoom low? Herausgezoomt sieht es auch interessant aus. Man beachte die Löcher in London und Prag sowie das großenteils blasse Deutschland: http://osm.org/go/0Bvbm?layers=O ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 18:59, schrieb Carsten Moeller: Ja, klar, beim Monav ist das doch alles schon dabei, inkl. Datenaufbereitung und so (schau mal auf die routing-Liste). Die standalone-Version des Algorithmus gibt es auch als Open Source, und eine Demo ist auf routingdemo.geofabrik.de zu sehen (derzeit mit einem aelteren Daten-Ausschnitt fuer Westeuropa - das ist eine VM mit 2 GB RAM, da geht ganz Europa nicht drauf). Hmmm... ich hab jetzt in der Kürze der Zeit noch nicht viel darüber gelesen... Hier noch eine weitere OSM Routingsoftware (gepostet im Forum) die angeblich sehr performant ist: http://www.routino.org/ Ist in der Übersicht auf http://wiki.openstreetmap.org/wiki/Routing/offline_routers noch nicht drin. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] barrier=Leitplanke
Hallo zusammen, Situation: way von einer NATO-Rampe (dient zur Gewässerquerung fürs Militär) zu einer öffentlichen Straße. Der way ist mit einer leicht ab zu montierender Leitplanke abgesperrt. Welcher Wert für barrier wäre angemessen? Folgende Werte habe ich schon gesehen: crash_barrier (Englische Bezeichnung in UK) guard_rail (Englische Bezeichnung in den USA) Leitplanke Es gibt sicher noch mehr. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 7. November 2010 18:30 schrieb Carsten Schönert c.schoen...@t-online.de: Am 07.11.2010 13:16, schrieb M∡rtin Koppenhoefer: setzt): bei einem Maxspeed, aber auch bei einem gesperrt für Fzg. aller Art, ist es oft nämlich nicht genau klar, bis wo das Schild wirklich gilt, dann hilft ein Blick in die StVO :-) das stimmt nicht. Wenn beispielsweise ein Z250 oder 260 (gesperrt für alle od. Kfz) nur auf einer Seite einer Straße steht, auf der anderen aber nicht, ist es keineswegs klar, ob man den kompletten Way damit taggen sollte. Das Schild zu taggen ist dagegen eindeutig und hilft den nachkommenden Mappern ungemein bei der Beurteilung der Situation, vor allem wenn sie aus der anderen Richtung die Straße genommen haben und das Schild evlt. gar nicht bemerkt haben. Hast Du mal die genaue Stelle in der StVO zu den Tempolimits? M.E. steht das da nicht so drin. Das Schild ergibt sich von selbst wenn ein Router die Nodes mit der Start- und der Endposition findet. Dann wäre eine weitere Info wegen dem Schild einfach nur unnötige Daten. jaja, so habe ich früher auch gedacht. Je mehr Tempolimits Du erfasst, um so mehr wirst Du es schätzen, wenn da solche Hinweise zu aufgestellten Zeichen in den Daten sind, erst recht an Stellen, wo die Limits assymetrisch sind. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=Leitplanke
Am 7. November 2010 19:11 schrieb René Falk li...@falconaerie.de: Folgende Werte habe ich schon gesehen: crash_barrier (Englische Bezeichnung in UK) guard_rail (Englische Bezeichnung in den USA) Leitplanke taginfo: guard_rail 201 guardrail 10 crash_barrier 8 ich nutze bisher auch guard_rail, allerdings in Unkenntnis, dass es ein amerikanisches Wort ist. Sind wir uns da sicher, dass man in GB nur crash_barrier verwendet? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=Leitplanke
Am 07.11.2010 19:16, schrieb M∡rtin Koppenhoefer: ich nutze bisher auch guard_rail, allerdings in Unkenntnis, dass es ein amerikanisches Wort ist. Sind wir uns da sicher, dass man in GB nur crash_barrier verwendet? In meinem alten Langenscheidt steht jeweils UK und USA hinter den Bezeichnungen und auch LEO scheint das so für den Straßenbau zu sehen. Leo gibt für Leitplanke im Straßenbau auch noch beam barrier, guide board und safety fence aus. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 18:59, schrieb Carsten Moeller: Am 07.11.2010 17:04, schrieb Frederik Ramm: Hallo, Carsten Moeller wrote: Weißt Du zufällig, ob das schon mal jemand auf OSM-Daten losgelassen hat? Ja, klar, beim Monav ist das doch alles schon dabei, inkl. Datenaufbereitung und so (schau mal auf die routing-Liste). Die standalone-Version des Algorithmus gibt es auch als Open Source, und eine Demo ist auf routingdemo.geofabrik.de zu sehen (derzeit mit einem aelteren Daten-Ausschnitt fuer Westeuropa - das ist eine VM mit 2 GB RAM, da geht ganz Europa nicht drauf). Bye Frederik Hmmm... ich hab jetzt in der Kürze der Zeit noch nicht viel darüber gelesen... Hätte da aber mal ein paar Kernfragen, da du ja an der Quelle sitzt. (Die Fragen beziehen sich auf einen herkömmlichen, etwas älteren Rechner mit sagen wir mal 2 Gig RAM, und ein paar Herz Taktgeschwindigkeit OHNE VM) a) Ist ein Preprocessing über europe.osm möglich - Wie lange dauert sowas? b) Werden OneWays berücksichtigt? c) Sind die Turning-Restrictions mit drin? d) Bevor ich jetzt lange suche: Gibt's einen Link zu der OpenSource-Bibliothek? Gruß und vorab schon mal -Danke für die Infos- Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hmmm... Oben: Dijkstra, Unten: Monav. Kann natürlich auch an der Bewertung der Straßen liegen. http://osm2po.de/download.php?dl=cmp.jpg Ich hoffe, es ist zu erkennen, wo das ist. Ansonsten: Hölle schnell das Teil!!! Gruß, CM. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Grenz-Relationen mit type=boundary oder mit type=multipolygon?
Hallo! An der Grenze zwischen Deutschland und Österreich ist aufgefallen, dass diese Grenze anders gerendert wird, als andere Grenzen. Am Dreiländereck im Bodensee kann man das ganz gut sehen: http://www.openstreetmap.org/browse/node/45072653 Über die Ursache dafür wurde hier bisher kaum ein Wort verloren (man macht lieber seine Späßchen). Am nächsten dran war bisher Andreas Labres: http://lists.openstreetmap.org/pipermail/talk-de/2010-October/078441.html http://lists.openstreetmap.org/pipermail/talk-de/2010-November/078935.html Seine Vermutung ist, dass der Mapnik-Style die Relationen type=multipolygon und type=boundary unterschiedlich behandelt. Schauen wir doch einfach mal nach. Der folgende Text ist ein wenig ausführlicher und erklärender als zur Beschreibung der Ursache notwendig, damit auch Leute, die sich noch nicht mit dem Rendering mit Mapnik beschäftigt haben, auch noch etwas verstehen. Der Mapnik-Style liegt in http://trac.openstreetmap.org/browser/applications/rendering/mapnik Unter 'Revision Log' oben rechts gibt es eine Versionsgeschichte. Der eigentliche Style ist die Datei http://svn.openstreetmap.org/applications/rendering/mapnik/osm.xml Das Rendern der Grenzen ist eine Include-Datei ausgegliedert http://svn.openstreetmap.org/applications/rendering/mapnik/inc/layer-admin.xml.inc Hier stellen wir folgendes fest: ++ Das alles ist ziemlich übersichtlich. ++ Von type=multipolygon oder type=boundary sieht man hier nichts. Hier kann der Unterschied nicht liegen. Er muss von woanders kommen. ++ Die Geometrie stammt aus der PostGIS-Tabelle prefix_roads. Dies ist eine Teilmenge der Tabelle prefix_line. Diese beiden Tabellen enthalten nur Linien. Die Tabelle prefix_polygon, die alle Flächen enthält, wird nicht erwähnt. Ebenso nicht die Tabelle prefix_point mit allen Punkten. - Alle Grenzen werden mit sehr geringer Deckkraft (opacity) zwischen 0.1 und 0.3 gezeichnet. - Die Grenzen werden als lila Linien unterschiedlicher Breite gezeichnet. Sie sehen wie folgt aus: - admin_level=2 (Staat) wird durchgezogen, sehr breit - admin_level=4 (Land, Kanton) wird gleichmäßig gestichelt, breit - admin_level=5 (Regierungsbezirk) wird gestrichelt (lang, kurz, kurz) - admin_level=6 (Kreis, Bezirk) wird gestrichelt (lang, kurz) - admin_level=8 (Gemeinde) wird gleichmäßig gestrichelt, schmal - Die SQL-Anfragen, Layer und Rules sind so angelegt, dass jeder Weg in prefix_roads höchstens einmal gezeichnet wird. Eine erste Vermutung ist, dass ausschließlich Wege mit boundary=administrative und admin_level=* gerendert werden. Relationen spielen also keine Rolle. Dafür spricht z. B. die folgende Stelle: http://www.openstreetmap.org/?lat=50.74158lon=7.24558zoom=15layers=M Besser sieht man es hier: http://toolserver.org/~osm/styles/?lat=50.74158lon=7.24558zoom=15layers=000BF0FFF0FF00 Der Bach (Pleisbach) bildet die Grenzen zwischen Hennef (im Nord-Osten, Relation 36042) und Königswinter (im Süden, Relation 173113). In den beiden Grenzrelationen (type=multipolygon, beide vollständig) ist nur der waterway=river als outer eingetragen. Ein Weg mit boundary=administrative und admin_level=8 fehlt hier. Überall sonst im Rhein-Sieg-Kreis sind Wege mit diesen Tags an den anderen Grenzen vorhanden. Wir sehen also: Eine Multipolygon-Relation alleine reicht nicht aus, damit sie als Grenze gerendert wird. Ein Blick auf die gerenderten Karten (Beispiel Bodensee) zeigt, dass die letzten beiden Punkte obiger Liste sich irgendwie widersprechen: Im Bodensee entspricht die Grenze Schweiz-Deutschland keinem der oben beschriebenen Aussehen. Vielmehr scheint hier das Aussehen von admin_level=2 und admin_level=4 übereinander gelegt worden zu sein. Tatsächlich liegen hier zwei Relationen mit type=boundary und dem passendem admin_level (2=Schweiß, 4=Thurgau) übereinander. An der Grenze Österreich-Deutschland ist das genau so – nur werden hier Relationen mit type=multipolygon benutzt. Die Vermutung ist also, dass irgendwie übereinander liegende Linien mit unterschiedlichem admin_level in die Tabelle prefix=roads eingetragen werden, die aus Relationen mit type=boundary stammen. Die genannten Tabellen werden vom Programm osm2psql erzeugt. Der Quelltext liegt hier: http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql Das Programm nimmt OSM-Dateien bzw. Differenzen von OSM-Dateien und trägt diese in eine Postgres-Datenbank mit PostGIS-Erweiterung ein. Nodes kommen in die Tabelle prefix_point; Wege, die Linien und kleine Flächen sind, nach Tabelle prefix_line und ggf. als Kopie nach Tabelle prefix_roads und Wege, die Flächen sind, nach Tabelle prefix_polygon. Bei diesen Schritten werden die OSM-Daten so gut wie gar nicht bearbeitet, sondern Geometrie und Tags unverändert übernommen. In die Tabelle prefix_roads kommen Wege mit boundary=adminstrative, railway=* oder highway=(motoway|trunk|primary|secondary|)(_link)?. Die Tabelle
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
schrieb Schorschi, am 07.11.10 18:26: war wohl nur der zu lange Link - dein Quoting ist übrigens ganz schlecht zu lesen bei mir, da du vor jeder von dir geschriebenen Zeile auch ein Quotingzeichen hast ... und du zitierst ja nicht, sondern schreibst was neues ... da muss ich dann immer suchen, wo jetzt der neue Text steht. Zur Verdeutlichung hier ein Vollzitat (schau's dir mal als unformatierten Text an, dann siehst du, was ich sehe): Hi Schorsch, unter TB sieht es tuto bene aus, aber wer Pine zum Mailen verwendet ... ;) Cheers, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Hallo, Carsten Moeller wrote: Oben: Dijkstra, Unten: Monav. Kann natürlich auch an der Bewertung der Straßen liegen. Monav kann noch keine Turn Restrictions (Einbahn aber schon). Ansonsten fuehrt das CH-Verfahren nach allem, was ich verstanden habe, beweisbar zum besten Ergebnis - es ist also keine wird im allgemeinen schon so klappen-Heuristik, sondern ein exaktes Verfahren. Ich bin auch kein Experte fuer Routingverfahren, aber Dijkstra ist m.E. von den altertuemlichen Verfahren am wenigsten fuer die statische Routenplanung geeignet. Dijkstra wuerde man hoechstens fuer eine dynamische Planung (Ziel konstant, Quelle beweglich) nehmen oder fuer eine Planung mit nicht-konkretem Ziel (naechstgelegene Tankstelle). Ansonsten nimmt man klassisch meistens A*, der hat die gleiche Komplexitaet wie Dijkstra, kommt aber meistens schneller zum Ziel. Doch zwischen diesen Verfahren, die sich ein schlauer Bastler noch mehr oder weniger selbst herleiten kann, und den modernen Alogrithmen wie CH liegen Welten, besonders dann, wenn es um den Serverbetrieb geht (wo u.U. tausende von Anfragen in der Sekunde beantwortet werden wollen, weil man vielen parallelen Nutzern live neue Routen praesentieren will, wenn sie die Maus bewegen). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
schrieb Schorschi, am 07.11.10 18:26: und, gerade gemerkt: wenn ich versuche, bei der Basemap rauszuzoomen - auf dem Maßstab unten rechts steht z. B. 30 km - dann stürzt der nüvi 1390 nach ein paar Minuten (ohne dass ich irgendetwas mache), während er versucht, die Kacheln zu laden, ab - vermutlich ist er überfordert, weil ich für Details das Maximum eingestellt habe ... Ich Schlafmütze, wollte doch eigentlich hierauf antworten. ;) Auf meinem eTrex HCx wird AIO Euro jetzt auch schon nicht mehr verarbeitet und Carstens Euro-Karte vom 31.10. tut's leider auch nicht. Gibt es irgendeinen anderen Stand, den ich ausprobieren könnte? Ich mußte jetzt erst einmal auf meinen letzten Stand von Ende September zurück. :/ Cheers, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Am Sonntag 07 November 2010, um 20:22:11 schrieb SteMo: Gibt es irgendeinen anderen Stand, den ich ausprobieren könnte? Ich mußte jetzt erst einmal auf meinen letzten Stand von Ende September zurück. :/ Das wäre die vom 29.09.2010. Die spiele ich mir jetzt auch wieder auf. Aber auf dem Server scheint die nicht mehr zu sein. Cheers, Stefan Chris.. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für innerorts / ausserorts?
Am 07.11.2010 02:15, schrieb Garry: Gibt es inzwischen einen eigenen Tag für innerorts/ausserorts? warum nicht einfach ein maxspeed=100 taggen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Schorschi schrieb: leicht abweichend - die AIO vom 3.11. geht bei mir nicht 7Zip packt die zwar aus, ein Nüvi 1390T erkennt die ausgepackte Datei aber nicht - und mit OpenSuse kann ich sie gar nicht erst auspacken - Das (ent)Packprogramm OpenSuse kannte ich bisher noch nicht. du hast hoffentlich den Smilie vergessen, Nein. Aber die unsichtbaren Ironie-Tags. mea culpa hab halt das Standard-Programm, das in der Opensuse 11.3 für KDE eingestellt ist benutzt und weiß nicht, wie es heißt - ich glaube ARK; mit unzip auf der Kommandozeile geht's übrigens auch nicht. Mit meinen Linuxen hab ich kein Problem beim Entpacken (unzip bzw gunzip) die Basemap (also ohne die Extras) funktioniert aber. Sind die Küstenregionen unter Wasser oder normal? Die Mapsource-basemap Europa vom 03.11. und vorhergehende waren landunter. hab gerade nachgeschaut: meine aktuelle Basemap ist vom 3.11. und hat auch Landunter - z. B. bis knapp vor Diepholz, Hamburg liegt komplett im Wasser ... Danke fürs Nachschauen. PS zum Thema zitieren: [Quoting repariert] Das stand da, weil du vergaßest zu schreiben, von wem außer dir der Inhalt deiner Mail stammte - wie in dieser Mail übrigens auch. Das Reparieren für zwei Ebenen sparte ich mir dieses Mal. Es ist üblich, am Anfang der NAchricht für jede zitierte Ebene deren Autor zu benennen. war wohl nur der zu lange Link - dein Quoting ist übrigens ganz schlecht zu lesen bei mir, da du vor jeder von dir geschriebenen Zeile auch ein Quotingzeichen hast ... und du zitierst ja nicht, sondern schreibst was neues ... da muss ich dann immer suchen, wo jetzt der neue Text steht. Zur Verdeutlichung hier ein Vollzitat (schau's dir mal als unformatierten Text an, dann siehst du, was ich sehe): Im Klartext wurden diese Daten versandt: http://ompldr.org/vNjMxMw Im Mailer sieht es so aus: http://ompldr.org/vNjMxMQ Da du der Erste überhaupt bist, der sich über komisches Quoting meinerseits beklagt und in diesem Thread bereits von einem Dritten nichtkomisches Quoting in meinen Mails bei der Betrachtung durch Thunderbird bestätigt wurde, gehe ich stark davon aus, dass es nicht an mir liegt. Ich lasse mich gern eines Besseren belehren. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiederbetätigung?
On 07.11.10 16:30, Heiko Jacobs wrote: Schaut man da überhaupt die Relationen an und wenn ja, warum? Das Grenzstück wird unterschiedlich gerendert, IMO: je nachdem, welche Relationen (mit welchen levels) drauf sind. Je höhere Levels drauf sind, umso wichtiger (und eben jene Logik scheint bei Multipolygonen nicht gleichwertig zu wirken). Und es soll ja auch Leute geben, die boundary und admin_level auf dem Way vergessen, da reagiert der Mapnik (neuerdings?) auch verzeihlich. Und das Grenzstück wird beschriftet, wenn eine Relation nicht geschlossen ist. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiederbetätigung?
On 07.11.10 16:44, Chris66 wrote: Du kannst ja Flüsse in das Boundary-MP packen, ohne ein boundary-Tag am waterway. Naja, auch das Flußstück sollte boundary und level Tag haben... /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschätekuddelmuddel und anderes
Am 05.11.2010 17:21, schrieb Steffen Heinz: Am 05.11.2010 13:00, schrieb Steffen Heinz: Hallo Ich habe hier eine Geschäft da ist drin: Bäcker, Post, Computer mehr oder wenig ein Raum, nicht allzugroß. ich hab ne Lösung gefunden im Netz und hoffe das das recht ist: einen Rahmen ziehen, diesen mit der Hausnummer versehen und alles reinpacken was unter dieser Hausnummer angeboten wird, was getan wird. Hat ne ganze Weile gedauert bis ich die Lösung endlich hatte - es ist halt die Kunst die richtigen Wörter zum Suchen zu haben Grüße aus der Eifel Steffen Genau das wollte ich vorschlagen. Bei Geschäften in Geschäften (Postschalter im Reisebüro oder Fleischereitheke im Supermarkt) solltest du das Haupt-Geschäft als Fläche mappen und das Zusatzgeschäft als Node einfügen. MfG Andreas -- Diese Nachricht wurde maschinell erstellt und ist daher ohne Unterschrift gültig. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Am 06.11.10 09:51, schrieb qbert biker: Original-Nachricht Datum: Sat, 06 Nov 2010 08:54:16 +0100 Von: Carsten Moellercmindivid...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] AIO Europe nun zu groß für 4GB SD ich hab keine Ahnung (das ist ja eine tolle Einleitung ...;), was da alles in die Karte aufgenommen wird. Anscheinend ja fast alles! Ich sehe mich mit ähnlichen Dingen konfrontiert und will nur ein paar Zahlen für Deutschland liefern. Als ich mich vor einem Jahr mit dem OSM-Routing (hardcore) begann zu beschäftigen, da lieferte mir OSM in etwa 40Mio Knoten. Heute sind's bereits annähernd 60Mio. Und dies eigentlich nur, weil OSM ja nicht zwischen z.B. Gebäuden und Wegen und so trennt. Da ist ein Knoten erstmal ein Knoten. Wenn also der Speicher zu gering ist, egal ob Kiste oder Navi, dann kann man eigentlich nur noch Dinge weglassen, um die Mengen zu reduzieren. Ein weiteres Problem wird es gefühlt in ca. 3 Jahren geben. Dann nämlich wird OSM mit seinen IDs an die 32-Bit-Grenze stoßen - schöpfen heute bereits 31 Bits aus - und sämtliche IDs auf 64-Bit umstellen. Wenn da vorher seitens der Garmins, Router, usw. keine Umschlüsselung stattfindet, dann wird der Speicherbedarf sogar ohne Mehrinformation von heut auf morgen aufgepumpt. Gruß, Carsten Korrektur: Meinte natürlich 30 / 31 Bits (32 wären ja negativ;-) Nö, das mit den 32 Bit passt schon, denn ein Knoten hat in der Anwendung keine negativen Werte. Die Beschneidung auf 31 Bit, bzw. negative Werte ist nur ein Trick, um noch ein Flag zu übrig zu haben. Das kann bei Editoren sein, ob jetzt ein Datum schon übertragen wurde oder auch nicht. Das OSM-XML-Format ist komplett aussen vor, da die Zahlen in Textform gespeichert werden, die keine Begrenzung kennen. Wer allerdings mobil Daten eintragen will, braucht das original OSM-Datenmodell mit seinen Unzulänglichkeiten und da wird man wohl in den sauren 64-Bit Apfel beissen müssen. Nun, dann sollen die Editoren (ob mobil oder nicht) die OSM-IDs eben auch als Text behandeln, und -wenn nötig- intern eine eigene numerische Indizierung verwenden. Den gesamten planet.osm bekommt ja sowieso keiner in den Speicher. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Drucken von einer gpx Datei über eine r Hill-Shading Karte?
Hallo! Gibt es eigentlich inzwischen eine einfache Möglichkeit, eine gpx Datei auf eine OSM-Karte mit Schummerung zu legen und diese dann brauchbar hochauflösend auf Papier auszudrucken? Wenn man das auf eine der Online-Karten legt ist das Druckergebnis ja meist wegen der Auflösung nicht so richtig befriedigend. Das ganze für einen unbedarften Windows Nutzer der sich etwas mit Garmin auskennt. Also irgendwie Online-Service, Garminkarte auf BaseCamp oder sowas. Jemand ne gute Idee? Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Tabaccherie
Ho avuto qualche perplessità cercando di indicare sulla mappa una tabaccheria. Ciò che ho trovato su OSM è l'accoppiata shop::tobacco, senza altre specificazioni. C'è un motivo pratico per questo? Visto il ruolo che attualmente le tabaccherie svolgono nel nostro paese, occupandosi di giochi, riscossioni e quant'altro, ho l'impressione che forse si dovrebbe scendere più nel dettaglio. Mi è sfuggito forse qualcosa? Grazie i1BPF-Giuliano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tabaccherie
2010/11/7 Giuliano italia1...@alice.it: Ho avuto qualche perplessità cercando di indicare sulla mappa una tabaccheria. Ciò che ho trovato su OSM è l'accoppiata shop::tobacco, senza altre specificazioni. C'è un motivo pratico per questo? perché è ancora nuovo come tag Visto il ruolo che attualmente le tabaccherie svolgono nel nostro paese, occupandosi di giochi, riscossioni e quant'altro, ho l'impressione che forse si dovrebbe scendere più nel dettaglio. benissimo. Più dettagli metti meglio è. Mi è sfuggito forse qualcosa? Forse che si possa usare qualsiasi tag in OSM, tale si ritiene necessario e utile? ;-) Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tabaccherie
In data domenica 7 novembre 2010 12:15:24, Giuliano ha scritto: : Ho avuto qualche perplessità cercando di indicare sulla mappa una tabaccheria. Ciò che ho trovato su OSM è l'accoppiata shop::tobacco, senza altre specificazioni. C'è un motivo pratico per questo? Visto il ruolo che attualmente le tabaccherie svolgono nel nostro paese, occupandosi di giochi, riscossioni e quant'altro, ho l'impressione che forse si dovrebbe scendere più nel dettaglio. Mi è sfuggito forse qualcosa? Grazie i1BPF-Giuliano Se cerchi negli archivi se ne è discusso recentemente. Comunque acvevo anche preparato una paginetta [¹] che sarebbe pronta da pubblicare e il cui unico dubbio riguarda l'accettazione, quantomeno dalla community italiana, del TAG authorization. Per il resto dovrebbe essere a posto. Ciao Alessio [¹] http://wiki.openstreetmap.org/wiki/User:Al3xius/Sandbox/tobacco ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Segnalazione tracce GPS
Su questo sito sono disponibili un sacco di tracce GPS scaricabili: http://www.paolaegino.it/MTB/gps.htm -- Art.156 del Codice della strada. Nei centri abitati, l'utilizzo dei dispositivi di segnalazione acustica (clacson) è vietato. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Segnalazione tracce GPS
Alle 17:59 di domenica 07 novembre 2010 Fabri ha scritto: Su questo sito sono disponibili un sacco di tracce GPS scaricabili: http://www.paolaegino.it/MTB/gps.htm In fondo alla pagina c'è un bel All Rights Reserved © 2003 - 2010 - by Paola e Gino - Testi, foto e mappe sono realizzate in proprio. Non si possono usare. Alessio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Segnalazione tracce GPS
2010/11/7 Alessio Zanol nar...@infinito.it: Su questo sito sono disponibili un sacco di tracce GPS scaricabili: http://www.paolaegino.it/MTB/gps.htm In fondo alla pagina c'è un bel All Rights Reserved Tempo fa anch'io andavo alla ricerca di tracce (MTB, sentieri ecc.) per importare il più possibile, ma poi mi sono accorto che una traccia GPS prodotta da un altro (soprattutto se in MTB) è poco utile: non si capisce se è path, track, unclassified ecc. Siccome abbiamo a disposizione le ortofoto, potresti caricare sia le tracce che le ortofoto, e poi ricalcare *dalle sole ortofoto*. Le ortofoto sono spesso più precise delle tracce GPS e a volte si riesce a capire il tipo di highway. Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mapping Party Comune Venezia
Il 04 novembre 2010 14:23, Luca Delucchi ha scritto: gianluca puoi creare una pagina sul wiki... scusate ma delle consegne sul lavoro mi hanno prosciugato il tempo libero a disposizione negli ultimi giorni :| Domani creerò la pagina sul wiki ;) intanto contatterò personalmente chi si è proposto per fare da relatore/tutor perchè per avere degli aiuti economici abbiamo dovuto accettare degli obblighi burocratici (no, non c'è niente di ancora in forse, è già stato tutto deciso e stanziato) :D A presto news :) -- Bigshot - Gianluca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-dk] Gadenavne efter adresseimport
Findvej-botten ser nu ud til at være ved at falde til ro efter OSAK data importen. Jeg kan konstatere at: 1) En række fejl i gadenavne er blevet korrigeret og en række nye adresser er dukket op. Fint. 2) Den gamle problematik med afvigende stavning af gadenavne i adresse dataerne og gadenavnsskiltene er igen aktuel. Det drejer sig især om navne der ender på -alle/-allé, men også forkortelser som Ndr (Nordre) og Gl (Gammel). Ifølge normal praksis (wiki) bør navnetagget altid benytte det fulde navn uden forkortelser og den stavning som er angivet på skiltet. Jeg havde korrigeret et antal adresser efter KMS importen, men de adresser er nu igen blevet røde på GeoFabriks OSM Inspector. Hvad er bedst? Acceptere uoverensstemmelsen mellem OSAK navnene og de skiltede navne, opdatere navnene på OSAK adresserne eller opdatere navnene på gaderne? Ole ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Gadenavne efter adresseimport
Jeg anbefaler kraftigt at vi følger Bekendtgørelse om vejnavne og addresser slavisk [1]. Jeg mener det relevante indlæg af bekendtgørelsen med hensyn til dit spørgsmål bevares herunder med henvisning eller direkte citat fra loven: - Kommunerne fastsætter i dag addresser [§1 stk. 1.] for næsten alle veje, pånær særtilfælde hvor det er i samarbejde med vejdirektoratet eller dikteres fra ministerierne. - Kommunerne videresender vejdata til CPR's vej- og boligregister som er da bliver den øverste rettesnor [§23, §23 stk. 1.] - Et vejnavn er på maksimalt 40 karakterer [§6] - Vejnavnet fastsættes i overensstemmelse med Dansk Sprognævns Vejledning i retskrivning af vejnavne [2] [§6 stk. 2.] - Til ethvert vejnavn fastsættes tillige et forkortet vejnavn, kaldet et vejadresseringsnavn, på indtil 20 tegn. For vejnavne på 20 tegn eller derunder, er vejnavnet også vejadresseringsnavn. [§6 stk. 3.]. Som jeg forstår det, skyldes det en oldgammel teknisk problemstilling i CPR-vejregistret hvor deres system kun kan logge maksimalt 20 karakterer. - For vejnavne over 20 tegn fastsættes vejadresseringsnavnet ved forkortelse af vejnavnet. Ved forkortelsen skal flest mulige af de 20 tegn anvendes, og alle ord i vejnavnet bør være repræsenteret. Forkortelser i vejnavnets begyndelse skal undgås af hensyn til maskinel, alfabetisk sortering. [§6 stk. 4.] Så først og fremmest er det værd at notere sig den importerede osak data ikke er helt god fordi der kun opereres med ét vejnavn når der ikke er nogen teknisk god grund til data'en ikke indholder begge to. Så får at svare direkte på dit indlæg. Det drejer sig især om navne der ender på -alle/-allé Her følger vi [2] hvad Dansk Sprognævn siger: ***Alle eller allé og andre dobbeltformer* *Der findes i Retskrivningsordbogen en del dobbeltformer, fx alle og allé, med og uden accenttegn (accent aigu). De to former er lige korrekte, og det er valgfrit om man bruger den ene eller den anden form. Det anbefales dog at den enkelte kommune er konsekvent, så enten alle eller allé bruges i alle de vejnavne i kommunen hvor ordet optræder.*** * * -Vi bruger den udgave af alle/allé som aws-dataen nu har på det pågældende sted. Jeg rettede en del af problemerne mellem osak og kms dataen og det virker på mig somom alle kommuner har besluttet sig for at fjerne allé som stavemåde, så det er nok kun få steder du finder den. men også forkortelser som Ndr (Nordre) og Gl (Gammel) Her følger vi igen hvad DSN siger: ***Forkortelser, forkortelsespunktum og mellemrum* *Vejnavne som udtales uforkortet, skrives som hovedregel helt ud, fx Søndre Boulevard, Gammel Kongevej, Vilhelm Thomsens Plads, Christian Svendsens Gade.* *Visse vejnavne som udtales uforkortet, skrives dog traditionelt med standardiserede forkortel- ser. Sådanne forkortelser kan bl.a. stå for adjektiver (tillægsord) eller for personnavne, fx Sdr. Boulevard, Gl. Kongevej, Vilh. Thomsens Plads, Chr. Svendsens Gade. De standardiserede forkortelser for adjektiver er:* *Gl. for Gammel og Gamle Ll. for Lille Ndr. for Nordre Nr. for Nørre* *Sdr. for Sønder og Søndre Skt. for Sankt St. for Store V. for Vester og Vestre* *Ø. for Øster og Østre* *Andre hyppigt forekommende standardforkortelser: Dr. for Doktor Hf. for Haveforening(en)* *Vejnavne som er forkortet i udtalen, skrives også forkortet, fx H.C. Andersens Boulevard, Carl Th. Dreyers Vej. Hvis det er en flerordsforbindelse der er forkortet, fx H.C. for Hans Christian, laver man ikke mellemrum mellem bogstaverne i forkortelsen:* *A.F. Beyers Vej, J.P.E. Hartmanns Allé, B.S. Ingemanns Vej, H.C. Andersens Vej.*** * * - Vi bruger den forlængede udgave som name=* (og bruger det tag som en placeholder for vejnavn) for dine eksempler, Nordre og Gamle/Gammel, men ikke på f.eks. H.C. Andersens Boulevard. Samtigt anbefaler jeg man flytter aws måden ned på alt_name=*,som alternativ for forkortet vejnavn, hvor det nu giver mening. Acceptere uoverensstemmelsen mellem OSAK navnene og de skiltede navne Som jeg forstår BBR-loven og bekendtgørelse om vejnavne og addresser så burde den data vi (pbro) har hentet ud af aws være ens med den der står på skiltene medmindre skiltene bruger den vejnavn i stedet for forkortet vejnavn- se ovenfor. Hvis den ikke er det højst sandsynligt din kommune der er sløv i betrækket (og vejskilte koster sikkert mange mange knaster) så prøv at kontakte dem og forhør om sagen. opdatere navnene på OSAK adresserne Nej! Det kan godt være det er den pragmatiske metode, men hvis der er fejl i aws-registret skal det fortælles til din kommune som så skal give data videre, så vi kan trække opdateringen den vej. Jeg har allerede set et par hundrede fejl i data (f.eks. en firkant og en streg i jylland, og noget overskydende data oven i en ny motorvej), men har ikke fundet tid til at finde en i min kommune man kan have en meningsfyldt samtale med om at rette sådan noget. opdatere navnene på gaderne? Ja jf. [2]. Cirkulæret virker rimeligt ligetil at læse og anbefales for
Re: [Talk-dk] Gadenavne efter adresseimport
Lidt sjov information fra samme bekendtgørelse om hvordan addresse-poisne er placeret og som samtidigt kan bruges til at placere bygninger uden at have hverkens gps-data eller orthofotoer. *§ 13. *Til hver adgangsadresse tilknyttes et punkt (adressepunktet), som skal være beliggende inden for omridset af det jordstykke, henholdsvis den bygning, som adressen, jf. § 11 hører til. *Stk. 2. *Hører adgangsadressen til en bygning, jf. § 11, stk. 1 eller 2, bør adressepunktet fastsættes tre meter inde i denne, regnet fra midten af den længste side af bygningen nærmest den navngivne vej som adressen er knyttet til. For bygninger, hvortil der hører mere end én adgangsadresse, bør adressepunkterne fastsættes således, at de bedst muligt svarer til beliggenheden af de tilhørende indgangsdøre. Med venlig hilsen Rasmus Vendelboe 2010/11/7 Rasmus Vendelboe r.vendelboe+...@gmail.comr.vendelboe%2b...@gmail.com Jeg anbefaler kraftigt at vi følger Bekendtgørelse om vejnavne og addresser slavisk [1]. Jeg mener det relevante indlæg af bekendtgørelsen med hensyn til dit spørgsmål bevares herunder med henvisning eller direkte citat fra loven: - Kommunerne fastsætter i dag addresser [§1 stk. 1.] for næsten alle veje, pånær særtilfælde hvor det er i samarbejde med vejdirektoratet eller dikteres fra ministerierne. - Kommunerne videresender vejdata til CPR's vej- og boligregister som er da bliver den øverste rettesnor [§23, §23 stk. 1.] - Et vejnavn er på maksimalt 40 karakterer [§6] - Vejnavnet fastsættes i overensstemmelse med Dansk Sprognævns Vejledning i retskrivning af vejnavne [2] [§6 stk. 2.] - Til ethvert vejnavn fastsættes tillige et forkortet vejnavn, kaldet et vejadresseringsnavn, på indtil 20 tegn. For vejnavne på 20 tegn eller derunder, er vejnavnet også vejadresseringsnavn. [§6 stk. 3.]. Som jeg forstår det, skyldes det en oldgammel teknisk problemstilling i CPR-vejregistret hvor deres system kun kan logge maksimalt 20 karakterer. - For vejnavne over 20 tegn fastsættes vejadresseringsnavnet ved forkortelse af vejnavnet. Ved forkortelsen skal flest mulige af de 20 tegn anvendes, og alle ord i vejnavnet bør være repræsenteret. Forkortelser i vejnavnets begyndelse skal undgås af hensyn til maskinel, alfabetisk sortering. [§6 stk. 4.] Så først og fremmest er det værd at notere sig den importerede osak data ikke er helt god fordi der kun opereres med ét vejnavn når der ikke er nogen teknisk god grund til data'en ikke indholder begge to. Så får at svare direkte på dit indlæg. Det drejer sig især om navne der ender på -alle/-allé Her følger vi [2] hvad Dansk Sprognævn siger: ***Alle eller allé og andre dobbeltformer* *Der findes i Retskrivningsordbogen en del dobbeltformer, fx alle og allé, med og uden accenttegn (accent aigu). De to former er lige korrekte, og det er valgfrit om man bruger den ene eller den anden form. Det anbefales dog at den enkelte kommune er konsekvent, så enten alle eller allé bruges i alle de vejnavne i kommunen hvor ordet optræder.*** * * -Vi bruger den udgave af alle/allé som aws-dataen nu har på det pågældende sted. Jeg rettede en del af problemerne mellem osak og kms dataen og det virker på mig somom alle kommuner har besluttet sig for at fjerne allé som stavemåde, så det er nok kun få steder du finder den. men også forkortelser som Ndr (Nordre) og Gl (Gammel) Her følger vi igen hvad DSN siger: ***Forkortelser, forkortelsespunktum og mellemrum* *Vejnavne som udtales uforkortet, skrives som hovedregel helt ud, fx Søndre Boulevard, Gammel Kongevej, Vilhelm Thomsens Plads, Christian Svendsens Gade.* *Visse vejnavne som udtales uforkortet, skrives dog traditionelt med standardiserede forkortel- ser. Sådanne forkortelser kan bl.a. stå for adjektiver (tillægsord) eller for personnavne, fx Sdr. Boulevard, Gl. Kongevej, Vilh. Thomsens Plads, Chr. Svendsens Gade. De standardiserede forkortelser for adjektiver er:* *Gl. for Gammel og Gamle Ll. for Lille Ndr. for Nordre Nr. for Nørre* *Sdr. for Sønder og Søndre Skt. for Sankt St. for Store V. for Vester og Vestre* *Ø. for Øster og Østre* *Andre hyppigt forekommende standardforkortelser: Dr. for Doktor Hf. for Haveforening(en)* *Vejnavne som er forkortet i udtalen, skrives også forkortet, fx H.C. Andersens Boulevard, Carl Th. Dreyers Vej. Hvis det er en flerordsforbindelse der er forkortet, fx H.C. for Hans Christian, laver man ikke mellemrum mellem bogstaverne i forkortelsen:* *A.F. Beyers Vej, J.P.E. Hartmanns Allé, B.S. Ingemanns Vej, H.C. Andersens Vej.*** * * - Vi bruger den forlængede udgave som name=* (og bruger det tag som en placeholder for vejnavn) for dine eksempler, Nordre og Gamle/Gammel, men ikke på f.eks. H.C. Andersens Boulevard. Samtigt anbefaler jeg man flytter aws måden ned på alt_name=*,som alternativ for forkortet vejnavn, hvor det nu giver mening. Acceptere uoverensstemmelsen mellem OSAK navnene og de skiltede navne Som jeg forstår
Re: [Talk-dk] Gadenavne efter adresseimport
On 07-11-2010 15:52, Rasmus Vendelboe wrote: opdatere navnene på OSAK adresserne Nej! Det kan godt være det er den pragmatiske metode, men hvis der er fejl i aws-registret skal det fortælles til din kommune som så skal give data videre, så vi kan trække opdateringen den vej. Jeg har allerede set et par hundrede fejl i data (f.eks. en firkant og en streg i jylland, og noget overskydende data oven i en ny motorvej), men har ikke fundet tid til at finde en i min kommune man kan have en meningsfyldt samtale med om at rette sådan noget. Jeg er i store træk enig med dine kommentarer. Dog har vi det problem at data fra OSAK ifølge Peter vist ikke er helt opdaterede (højeste værdi af osak:revision er 2009-10-05T00:00:00), så vi kan nemt rende ind i at fejl vi finder allerede er fixet. Når det så er sagt så mener jeg at det er den rigtige vej at gå. Hvis det betyder at osm inspector viser røde nodes i en længere periode, så er det vel heller ikke jordens undergang? Målet er vel at få de rigtige data - ikke at få grønne pletter i osm inspector? -- Jonas Häggqvist rasher(at)rasher(dot)dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Gadenavne efter adresseimport
Cirkulæret bruges dog langt fra af kommunerne. I den gamle Græsted-Gilleleje Kommune har der siddet en person der holdt utroligt meget af at bruge bindestreg i en del af kommunen (sikkert i forbindelse med en udstykning). http://bit.ly/aep2kp On 07-11-2010 15:52, Rasmus Vendelboe wrote: Jeg anbefaler kraftigt at vi følger Bekendtgørelse om vejnavne og addresser slavisk [1]. Jeg mener det relevante indlæg af bekendtgørelsen med hensyn til dit spørgsmål bevares herunder med henvisning eller direkte citat fra loven: - Kommunerne fastsætter i dag addresser [§1 stk. 1.] for næsten alle veje, pånær særtilfælde hvor det er i samarbejde med vejdirektoratet eller dikteres fra ministerierne. - Kommunerne videresender vejdata til CPR's vej- og boligregister som er da bliver den øverste rettesnor [§23, §23 stk. 1.] - Et vejnavn er på maksimalt 40 karakterer [§6] - Vejnavnet fastsættes i overensstemmelse med Dansk Sprognævns Vejledning i retskrivning af vejnavne [2] [§6 stk. 2.] - Til ethvert vejnavn fastsættes tillige et forkortet vejnavn, kaldet et vejadresseringsnavn, på indtil 20 tegn. For vejnavne på 20 tegn eller derunder, er vejnavnet også vejadresseringsnavn. [§6 stk. 3.]. Som jeg forstår det, skyldes det en oldgammel teknisk problemstilling i CPR-vejregistret hvor deres system kun kan logge maksimalt 20 karakterer. - For vejnavne over 20 tegn fastsættes vejadresseringsnavnet ved forkortelse af vejnavnet. Ved forkortelsen skal flest mulige af de 20 tegn anvendes, og alle ord i vejnavnet bør være repræsenteret. Forkortelser i vejnavnets begyndelse skal undgås af hensyn til maskinel, alfabetisk sortering. [§6 stk. 4.] Så først og fremmest er det værd at notere sig den importerede osak data ikke er helt god fordi der kun opereres med ét vejnavn når der ikke er nogen teknisk god grund til data'en ikke indholder begge to. Så får at svare direkte på dit indlæg. Det drejer sig især om navne der ender på -alle/-allé Her følger vi [2] hvad Dansk Sprognævn siger: ///Alle eller allé og andre dobbeltformer/ /Der findes i Retskrivningsordbogen en del dobbeltformer, fx alle og allé, med og uden accenttegn (accent aigu). De to former er lige korrekte, og det er valgfrit om man bruger den ene eller den anden form. Det anbefales dog at den enkelte kommune er konsekvent, så enten alle eller allé bruges i alle de vejnavne i kommunen hvor ordet optræder./// / / -Vi bruger den udgave af alle/allé som aws-dataen nu har på det pågældende sted. Jeg rettede en del af problemerne mellem osak og kms dataen og det virker på mig somom alle kommuner har besluttet sig for at fjerne allé som stavemåde, så det er nok kun få steder du finder den. men også forkortelser som Ndr (Nordre) og Gl (Gammel) Her følger vi igen hvad DSN siger: ///Forkortelser, forkortelsespunktum og mellemrum/ /Vejnavne som udtales uforkortet, skrives som hovedregel helt ud, fx Søndre Boulevard, Gammel Kongevej, Vilhelm Thomsens Plads, Christian Svendsens Gade./ /Visse vejnavne som udtales uforkortet, skrives dog traditionelt med standardiserede forkortel- ser. Sådanne forkortelser kan bl.a. stå for adjektiver (tillægsord) eller for personnavne, fx Sdr. Boulevard, Gl. Kongevej, Vilh. Thomsens Plads, Chr. Svendsens Gade. De standardiserede forkortelser for adjektiver er:/ /Gl. for Gammel og Gamle Ll. for Lille Ndr. for Nordre Nr. for Nørre/ /Sdr. for Sønder og Søndre Skt. for Sankt St. for Store V. for Vester og Vestre/ /Ø. for Øster og Østre/ /Andre hyppigt forekommende standardforkortelser: Dr. for Doktor Hf. for Haveforening(en)/ /Vejnavne som er forkortet i udtalen, skrives også forkortet, fx H.C. Andersens Boulevard, Carl Th. Dreyers Vej. Hvis det er en flerordsforbindelse der er forkortet, fx H.C. for Hans Christian, laver man ikke mellemrum mellem bogstaverne i forkortelsen:/ /A.F. Beyers Vej, J.P.E. Hartmanns Allé, B.S. Ingemanns Vej, H.C. Andersens Vej./// / / - Vi bruger den forlængede udgave som name=* (og bruger det tag som en placeholder for vejnavn) for dine eksempler, Nordre og Gamle/Gammel, men ikke på f.eks. H.C. Andersens Boulevard. Samtigt anbefaler jeg man flytter aws måden ned på alt_name=*,som alternativ for forkortet vejnavn, hvor det nu giver mening. Acceptere uoverensstemmelsen mellem OSAK navnene og de skiltede navne Som jeg forstår BBR-loven og bekendtgørelse om vejnavne og addresser så burde den data vi (pbro) har hentet ud af aws være ens med den der står på skiltene medmindre skiltene bruger den vejnavn i stedet for forkortet vejnavn- se ovenfor. Hvis den ikke er det højst sandsynligt din kommune der er sløv i betrækket (og vejskilte koster sikkert mange mange knaster) så prøv at kontakte dem og forhør om sagen. opdatere navnene på OSAK adresserne Nej! Det kan godt være det er den pragmatiske metode, men hvis der er fejl i aws-registret skal det fortælles til din kommune som så skal give data videre, så vi kan trække opdateringen den vej. Jeg har
[Talk-ar] Convención de limites administrativos
http://wiki.openstreetmap.org/wiki/WikiProject_Argentina#Limites_politico-administrativos De todas las pruebas que hice se me hace lo más aceptable Se aceptan sugerencias, recuerden que el foro no muerde ja ja ja salu2 ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar
Re: [Talk-at] Kirchturmmapping in Sbg
On Sun, Nov 07, 2010 at 01:20:43PM +0100, Norbert Wenzel wrote: Gibt's ein fertiges Tool (das auch verwendet wird) mit dem ich POI suchen kann in der Gegend und mir alle Kirchen anzeigen lassen kann? Ich kann natürlich selbst eine Abfrage auf die Daten schreiben, aber dann kann ichs auch gleich richtig programmieren, die Frage ist aber ob bestehende Tools mit den Daten so wie sie jetzt sind umgehen können. PS: Bei Openstreetbrowser[1] bin ich mir nicht sicher, ob die Daten aktuell genug sind. Es schaut die Markuskirche gleich zerstört aus wie der Salzburger Dom, ich tippe also, dass der noch mit alten Daten rendert. Probier mal die zukuenftige Version http://dev.openstreetbrowser.org, die hat ganz aktuelle Daten (dauert derzeit ca. 2 Minuten bis sie in der Datenbank sind), aber noch nicht ganz alle Features von der Hauptversion. Dafuer ist es dort auch moeglich eigene Kategorien zu definieren. Das Hintergrund-Rendering kommt allerdings von der alten Version, das heisst, besser auf Mapnik o.ae. umschalten. gruesse, Stephan -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Plepelits, | | Technische Universität Wien -Studien Informatik Raumplanung | | Projects: | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | Contacts: | | Mail: sk...@xover.mud.at Jabber: sk...@jabber.at| | Blog: plepe.at Twitter: twitter.com/plepe | `-' ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Kirchturmmapping in Sbg
On Sun, Nov 07, 2010 at 07:22:01PM +0100, Norbert Wenzel wrote: Du findest hier nur eine Kirche, wie es sich gehört. Das ist aber auch bei den anderen Kirchen in der Gegend (bspw. Kollegienkirche etwas südwestlich) so, und dort sind die einzelnen Türme noch als eigene place_of_worship eingetragen und nicht die Relation. Ist doch schön :) Du erkennst übrigens den Unterschied, wenn Du über den Link in der Liste hoverst, wenn der Link #rel_1234 ist, im Gegensatz zu #way_1234. Ich hab jetzt auch gefixt, dass die Fläche des Multipolygons gehighlighted wird, wenn Du drueber hoverst. Dafuer hab ich nen anderen Fehler gefunden (wenn Du auf den Link klickst, passieren ein paar ungeplante Dinge ...) Wenn Du uebrigens den No Basemap Layer einschaltest, dann hast Du nur das Rendering der Kirchen. Ich weiß nicht ob du das irgendwie erkennst oder ob du einfach keine place_of_worships ohne Namen anzeigst, wenn ich deinen vordefinierten Religion-Layer verwend. place_of_worship werden alle angezeigt, auch ohne Namen. gruesse, Stephan -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Plepelits, | | Technische Universität Wien -Studien Informatik Raumplanung | | Projects: | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | Contacts: | | Mail: sk...@xover.mud.at Jabber: sk...@jabber.at| | Blog: plepe.at Twitter: twitter.com/plepe | `-' ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Kirchturmmapping in Sbg
On 11/07/2010 08:15 PM, Stephan Plepelits wrote: On Sun, Nov 07, 2010 at 07:22:01PM +0100, Norbert Wenzel wrote: Ich weiß nicht ob du das irgendwie erkennst oder ob du einfach keine place_of_worships ohne Namen anzeigst, wenn ich deinen vordefinierten Religion-Layer verwend. place_of_worship werden alle angezeigt, auch ohne Namen. Also die Türme von Kollegienkirche und Dom fehlen sowohl in der No Basemap-Ansicht, als auch in der Auswahlliste am linken Rand. Was ich gut find, denn das heißt ja dann, dass die Eintragung der Kirchen als Multipolygon wenigstens für den Openstreetbrowser was bringt, denn die zuvor erwähnte Markuskirche hat ihre Türme ordentlich dabei. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-cz] Filtr gpx
Monza trochu OT, ale to nize uvedene neni vyraz regulerni, ale vyraz regularni. K Dne 7.11.2010 13:40, Pavel Zbytovský napsal(a): Tak tohle jsem už taky jednou řešil, dá se to udělat docela jednoduše - prohledáním všech GPXek nějakým regulérním výrazem. Řekněme, že máme bod 14.235, 50.124 - tak se dá snadno nalézt soubor obsahující souřadnice 14.23???, 50.12??? - to sice bude čtverec a ani se nedá nastavit triviálně jeho velikost, ale na obecné vyfiltrování by to mohlo stačit. Tohohle se dá dosáhnout na unixu grepem, nebo na win pomocí Total Commanderu. Nabídka Hledání souborů soubory: *.gpx Hledat text: trkpt lat=50.124[0-9]+ lon=14.23 Regulární výraz: ano Potom se Výsledek do panelu a nalezené GPXky zkopírovat do jiné složky, odkud už půjdou do JOSMU.. Pavel / zby-cz 2010/11/7 f.remenstech f.remenst...@gmail.com mailto:f.remenst...@gmail.com GPSBabel umí v .gpx souboru nechat body v zadaném kruhu. Já bych potřeboval nechat celou cestu, která prochází zadaným kruhem. Zkoušel jsem alespoň vyfiltroval body v kruhu, ale na výsledný soubor mi Josm píše Error occured while parsing gpx file. Only part of the file will be available a načte pouze první bod trasy. ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Filtr gpx
To by mohlo fungovat, jako nouzovku vyzkouším a pak si na to asi napíšu program... Díky. 2010/11/7 Pavel Zbytovský m...@zby.cz: Tak tohle jsem už taky jednou řešil, dá se to udělat docela jednoduše - prohledáním všech GPXek nějakým regulérním výrazem. Řekněme, že máme bod 14.235, 50.124 - tak se dá snadno nalézt soubor obsahující souřadnice 14.23???, 50.12??? - to sice bude čtverec a ani se nedá nastavit triviálně jeho velikost, ale na obecné vyfiltrování by to mohlo stačit. Tohohle se dá dosáhnout na unixu grepem, nebo na win pomocí Total Commanderu. Nabídka Hledání souborů soubory: *.gpx Hledat text: trkpt lat=50.124[0-9]+ lon=14.23 Regulární výraz: ano Potom se Výsledek do panelu a nalezené GPXky zkopírovat do jiné složky, odkud už půjdou do JOSMU.. Pavel / zby-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Filtr gpx
Tak tohle jsem už taky jednou řešil, dá se to udělat docela jednoduše - prohledáním všech GPXek nějakým regulérním výrazem. Řekněme, že máme bod 14.235, 50.124 - tak se dá snadno nalézt soubor obsahující souřadnice 14.23???, 50.12??? - to sice bude čtverec a ani se nedá nastavit triviálně jeho velikost, ale na obecné vyfiltrování by to mohlo stačit. *** priblizne na tomto principu funguje plugin open visible. Pri otvirani sebere informace o BBOX z gpx a srovna s aktualnim zoomem v JOSM, ty GPX co jsou mimo nej nakonec nenacte. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] La Région Bretagne libère ses do nnées
2010/11/6 Denis dhel...@free.fr: Pour info : libération de données à l'échelle de la région Bretagne ! Je vais chercher à en savoir plus concrètement sur les couches ainsi publiées. C'est génial, c'est encore à l'Ouest On sait quelle sera la licence utilisée ? Nope. Mais si on en croit la phrase un cadre juridique permettant leur libre accès, libre usage, et libre exploitation, y compris dans des services commerciaux, gracieusement et sans contrepartie, on a le choix entre CC zero / by / by-sa / ODbL / PDDL ... J'en profite pour pointer vers cette journée sur les bonnes pratiques d’ouverture ou de réutilisation des données publiques, à Rennes le 29 novembre 2010 : cf http://www.a-brest.net/article6721.html Je ne pourrai être présent, mais si certains d'entre vous peuvent se déplacer ... A+ F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] La révolution opendata dans la revue acteurspublics
Revue dédiée aux institutions publiques. Pas de mention directe à openstreetmap mais comme souvent quand on parle d'applications concrètes des opendata on évoque la cartographie. http://www.acteurspublics.com/article/28-09-10/la-revolution-open-data ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Avis aux parisiens
Très bonne idée ! Besoin d'un coup de main pour organiser ça ? Le 5 novembre 2010 16:02, Emilie Laffray emilie.laff...@gmail.com a écrit : Bonjour, Je serais sur Paris début décembre pour les Rencontres Wikimedia 2010. http://rencontres.wikimedia.fr/index.php?title=Accueil Ça pourrait être sympa d'organiser un resto le jeudi soir ou le samedi soir sur Paris et de discuter OSM! Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Avis aux parisiens
Pour ma part je serais au même colloque Samedi soir. Je pense que je pourrais rester un peu le soir :) Florian Farge aka Otourly Sur lesprojets wikimédiens et l'Association française,sur OxyRadio, OSM, et sur MOVIM Socio di Wikimedia Italia De : Christian Quest christian.qu...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Dim 7 novembre 2010, 11h 00min 42s Objet : Re: [OSM-talk-fr] Avis aux parisiens Très bonne idée ! Besoin d'un coup de main pour organiser ça ? Le 5 novembre 2010 16:02, Emilie Laffray emilie.laff...@gmail.com a écrit : Bonjour, Je serais sur Paris début décembre pour les Rencontres Wikimedia 2010. http://rencontres.wikimedia.fr/index.php?title=Accueil Ça pourrait être sympa d'organiser un resto le jeudi soir ou le samedi soir sur Paris et de discuter OSM! Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] La révolution opendata dans la revue acteurspublics
Complètement d'accord avec la conclusion de cet article ... Notamment quand je lis : Dans le cadre de sa mission de mise en valeur du patrimoine numérique public, l’APIE a par ailleurs proposé deux modèles de licences de réutilisation des données publiques. Elles ont été pensées avant tout dans l’optique de percevoir une redevance, sauf en ce qui concerne les réutilisations non commerciales. “La tarification éventuelle permet à l'administration de financer l'adaptation des données publiques aux besoins des réutilisateurs. Sans pour autant établir de barrière à l’entrée, la tarification sera fonction de l’activité économique engendrée. Nous restons pragmatiques”, détaille Claude Rubinowicz. ... Je dirais : Raw Data Now ! Merci du lien, F. 2010/11/7 Christophe x...@ecum3ne.net: Revue dédiée aux institutions publiques. Pas de mention directe à openstreetmap mais comme souvent quand on parle d'applications concrètes des opendata on évoque la cartographie. http://www.acteurspublics.com/article/28-09-10/la-revolution-open-data ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cadget mis à jour
Le 04/11/2010 23:10, sylvain letuffe a écrit : Le jeudi 4 novembre 2010 22:32:41, Denis a écrit : scroneugneu, moi qui pensais avoir une distrib uptodate. Ca sent la compil à plein nez. Tente une plus vielle version sinon, mon vieux imagemagick de la guerre Version: ImageMagick 6.3.7 08/09/09 s'en sort cf ci joint (Un test à l'instant avec le koala montre que ça crash presque pareil : convert a retourné une erreur at cadget line 273) troll de réponse Ubuntu, c'est une debian dans laquelle on a rajouté des bugs pour que les utilisateurs venant d'ailleurs ne se sentent pas trop perdu. et qui se fiche bien de imagemagick tant que le clic clicodrome qui va vendre des applications ne crash pas /troll -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Depuis Ubuntu 10.04 (Lynx Lucide), cela fonctionne si l'on rajoute à la main le paquet ImageMagick v6.6.2 fournit avec Ubuntu 10.10. Mettre à jours d'abord les bibliothèques : http://launchpadlibrarian.net/55838699/libmagickcore3_6.6.2.6-1ubuntu1_i386.deb http://launchpadlibrarian.net/55838702/libmagickwand3_6.6.2.6-1ubuntu1_i386.deb puis le paquet imagemagick http://launchpadlibrarian.net/55838696/imagemagick_6.6.2.6-1ubuntu1_i386.deb Un message d'avertissement peut apparaitre, insister pour installer le paquet. $ convert -version == Version: ImageMagick 6.6.2-6 2010-09-17 -- osmitheo http://wiki.openstreetmap.org/wiki/User:Osmitheo ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr