Re: [talk-ph] looking GPS POI/icons for OSM-PH garmin gps map
Hi maning, I'll help you create the icons. What format should they be in? Eugene On Tue, Jul 7, 2009 at 4:24 PM, maning sambale emmanuel.samb...@gmail.comwrote: Hi, Sorry for the appeal (not entirely osm related) The next phase for my osm sub-project OSM-PH GPS map, is to create custom icons and other styles for the map. I am currently compiling and creating several icons for this. What I want is to create custom icons for Philippine POIs with the following this basic guide: - very simple and easily recognizable on small screens - size 16 by 16 pixels - for commonly used icons (i.e. Parking), it should conform to international conventions - brand neutral (shell, petron and caltex will use the same icon) Several icons in my wishlist are: - bank with a Peso sign - toll booths - gate - cave_entrance - different icons for grocery, supermarket, shopping mall, convenience - vulcanizing :) - various public buildings If anyone is interested to contribute (any Illustrator/Inkscape expert here?), I (desparately) need your help. If you intend to donate your own icons, I would like to request you to explicitly allow a Public Domain license. This way, we can release the full icon set and allow others to use it. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] SteveC; C = Cool
At 00:06 08/07/2009, Russ Nelson wrote: On Jul 7, 2009, at 5:53 PM, SteveC wrote: On 7 Jul 2009, at 23:26, Stefan de Konink ste...@konink.de wrote: After the years of iterations don't you think it sucks that your simple easy REST-based model is now made so difficult in 0.6? Mozart had Salieri, I get you guys. Mozart got the better deal. Ah, I get it now. OSM has ... too many nodes. [1] Mike [1] Amadeus - the movie. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC; C = Cool
and it's far too noisy... On Wed, Jul 8, 2009 at 7:45 AM, Mike Collinson m...@ayeltd.biz wrote: At 00:06 08/07/2009, Russ Nelson wrote: On Jul 7, 2009, at 5:53 PM, SteveC wrote: On 7 Jul 2009, at 23:26, Stefan de Konink ste...@konink.de wrote: After the years of iterations don't you think it sucks that your simple easy REST-based model is now made so difficult in 0.6? Mozart had Salieri, I get you guys. Mozart got the better deal. Ah, I get it now. OSM has ... too many nodes. [1] Mike [1] Amadeus - the movie. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- http://short.ie/savenenaghhospital/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC; C = Cool
Ken Guest wrote: Sent: 08 July 2009 8:50 AM To: Mike Collinson Cc: Talk Openstreetmap Subject: Re: [OSM-talk] SteveC; C = Cool and it's far too noisy... Following a storm there is always too much flotsam. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - Tag:leisure=petting_zoo
Hi folks, I've moved the Tag:leisure=petting_zoo proposal page[1] from Draft to Proposed status. In short, it's a proposal for a petting zoo tag value, such that those can be tagged differently from regular zoos. A more extensive description, motivation and more can be found on the wiki page. [1] http://wiki.openstreetmap.org/wiki/Proposed_features/petting_zoo Cheers, -- Sybren Stüvel http://stuvel.eu/ http://www.flickr.com/photos/sybrenstuvel signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - Tag:shop=massage
Hi folks, I've proposed a tag shop=massage along with a massage=* specification of the massage that can be received. The proposal can be found at http://wiki.openstreetmap.org/wiki/Proposed_features/Massage Cheers, -- Sybren Stüvel http://stuvel.eu/ http://www.flickr.com/photos/sybrenstuvel signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC; C = Cool
On Tue, Jul 7, 2009 at 10:26 PM, Stefan de Koninkste...@konink.de wrote: SteveC wrote: inventing nodes, ways, segments (remember them?) You *did not* invent the spaghetti model, please give credit to the original inventor Stan Aronoff, in Geographic information systems: A management perspective (1989). actually, OSM doesn't use the spaghetti model. according to [1,2], Aronoff's spaghetti model treats points as coordinates and lines as lists of coordinates - basically what the OGC's simple features architecture [3] uses - and there's no explicit connectivity. OSM, on the other hand, uses a topological model which comes from a graph theory background, so really we should be crediting Leonhard Euler. cheers, matt 1: http://www.unescap.org/stat/pop-it/pop-guide/gis_ch04.pdf 2: http://eprints.utm.my/6685/1/78062.pdf 3: http://www.opengeospatial.org/standards/sfa ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC; C = Cool
On Wed, 8 Jul 2009, Matt Amos wrote: On Tue, Jul 7, 2009 at 10:26 PM, Stefan de Koninkste...@konink.de wrote: SteveC wrote: inventing nodes, ways, segments (remember them?) You *did not* invent the spaghetti model, please give credit to the original inventor Stan Aronoff, in Geographic information systems: A management perspective (1989). actually, OSM doesn't use the spaghetti model. according to [1,2], Aronoff's spaghetti model treats points as coordinates and lines as lists of coordinates Isn't this exactly how segments and ways are stored within OSM? An XML subtree referencing to points (thus lower diminensional objects)? While multipolygons are now stored as relation of two polygons? - basically what the OGC's simple features architecture [3] uses - and there's no explicit connectivity. OSM, on the other hand, uses a topological model which comes from a graph theory background, so really we should be crediting Leonhard Euler. Always good to credit him :) Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC; C = Cool
On Wed, Jul 8, 2009 at 12:05 PM, Stefan de Koninkste...@konink.de wrote: On Wed, 8 Jul 2009, Matt Amos wrote: On Tue, Jul 7, 2009 at 10:26 PM, Stefan de Koninkste...@konink.de wrote: SteveC wrote: inventing nodes, ways, segments (remember them?) You *did not* invent the spaghetti model, please give credit to the original inventor Stan Aronoff, in Geographic information systems: A management perspective (1989). actually, OSM doesn't use the spaghetti model. according to [1,2], Aronoff's spaghetti model treats points as coordinates and lines as lists of coordinates Isn't this exactly how segments and ways are stored within OSM? An XML subtree referencing to points (thus lower diminensional objects)? from those references, it seems that the spaghetti model includes coordinates directly, rather than referencing a lower dimensional object by ID. apparently it's called the spaghetti model because each way is independent, like spaghetti strands (presumably as opposed to potato waffles or something joined). spaghetti model - coordinates are directly included, topology is implicit. node lat=y lon=x/ waynode lat=y1 lon=x1/node lat=y2 lon=x2/node lat=y3 lon=y3//way graph theory model - coordinates are logically referenced, topology is explicit. node id=1 lat=y lon=x/ way id=1node ref=1/node ref=2/node ref=3//way OSM uses the latter. - basically what the OGC's simple features architecture [3] uses - and there's no explicit connectivity. OSM, on the other hand, uses a topological model which comes from a graph theory background, so really we should be crediting Leonhard Euler. Always good to credit him :) yep. he was a total genius - invented a whole new branch of mathematics without which we wouldn't have amazon/netflix recommendations ;-) cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] planet.o.o - no hourly diffs since 20090708 0:00
Hi, planet.openstreetmap.org does not have any hourly diffs since 0:00 this morning. Known bug? Havent seen any mention so far ... Flo PS: Minute diffs stop at 200907080153.osc.gz ... -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making an offline OpenStreetMap CD/DVD ?
On Friday 03 July 2009 12:47:42 maning sambale wrote: Is it possible for Marble to cache the data for offline viewing? Yes and no. Yes, in the sense that if you browse a certain area, the tiles that are downloaded are cached in the disk cache. No, in the sense that only the tiles that are actually visited will be cached. There is no way to say, for instance, download and cache all tiles in the current area for all zoomlevels and then have them downloaded automatically. In other words, yes it's possible but no, there is no really convenient way to do it. Patches are welcome, though . :-) Note also that the marble team is working on an OSM editing plugin that will allow the user to directly edit the OSM data. -Inge On Fri, Jul 3, 2009 at 5:24 PM, Rory McCannr...@technomancy.org wrote: On 02/07/09 17:40, Mikel Maron wrote: - Offline map editing. ... It hadn't occured to me to have offline editing. It would be cool to have that, since lots of the areas that have low bandwidth aren't mapped very well. However trying to write all the custom code and syncronise all that up is not an easy task, so I'm going to leave that for the moment. :) ___ 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] Species names (was: Potted plants vs. garden beds)
2009/7/7 Ed Avis e...@waniasset.com:
Ed Avis eda at waniasset.com writes:
Rather than plant_type=orange_tree or similar, I think it would make more
sense
to tag plants and trees with the scientific (Latin) name of their species or
hybrid. These are already standardized and the local language translations
('citrus x sinensis' = 'en:orange', 'es:naranja') are also standard, and can
be
looked up by the map renderer rather than duplicated for every orange tree on
the map.
I don't expect individual plants will be tagged very often (even the Germans
have not added the 'unter den' linden trees) but for managed forests and
perhaps
farmland it might be useful.
I thought of mentioning zoo animals but I thought it too silly. But look:
http://www.openstreetmap.org/?lat=52.50826lon=13.33929zoom=17layers=B000FTF
I think this would be better tagged with scientific names for the animals
rather
than 'name' holding the local-language names. Then the mapnik rendering rules
can be extended with little icons for penguins, polar bears and so on. We
could
even have little fish swimming in the oceans like the maps in olden days.
on the ground rule applies... name should be the local language.
If you want to add a species_taxonomy (or similar) tag then feel free. :-)
Dave
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Species names
Dave Stubbs osm.list at randomjunk.co.uk writes: Rather than plant_type=orange_tree or similar, I think it would make more sense to tag plants and trees with the scientific (Latin) name of their species or hybrid. [zoos] I think this would be better tagged with scientific names for the animals rather than 'name' holding the local-language names. on the ground rule applies... name should be the local language. That rule applies in the case of disputes that can't otherwise be resolved. The on the ground rule particularly applies to names, but not to classifications; the photographic museum in Berlin has name=Museum für Fotografie, following the rule you mention, but it is classified as amenity=arts_centre, not amenity=Kunstzentrum. Arguably name=Knut would be more appropriate than name=Eisbären... If you want to add a species_taxonomy (or similar) tag then feel free. Yes, I'm not proposing that the 'name' tag should change to Latin, but rather the introduction of a different tag, and that in some cases 'name' should disappear. (A particular enclosure at the zoo might not have a name.) I am not sure whether this or flowerbeds is of greater importance to the project, however ;-p. -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Species names
My rule of thumb would of be label it in english rather that local name. But that's because I am english. Using latin would put some people off from tagging Zoos. Jack On Jul 8, 2009 5:17 PM, Ed Avis e...@waniasset.com wrote: Dave Stubbs osm.list at randomjunk.co.uk writes: Rather than plant_type=orange_tree or similar, I think it would make more sense to tag plants and trees with the scientific (Latin) name of their species or hybrid. [zoos] I think this would be better tagged with scientific names for the animals rather than 'name' holding the local-language names. on the ground rule applies... name should be the local language. That rule applies in the case of disputes that can't otherwise be resolved. The on the ground rule particularly applies to names, but not to classifications; the photographic museum in Berlin has name=Museum für Fotografie, following the rule you mention, but it is classified as amenity=arts_centre, not amenity=Kunstzentrum. Arguably name=Knut would be more appropriate than name=Eisbären... If you want to add a species_taxonomy (or similar) tag then feel free. Yes, I'm not proposing that the 'name' tag should change to Latin, but rather the introduction of a different tag, and that in some cases 'name' should disappear. (A particular enclosure at the zoo might not have a name.) I am not sure whether this or flowerbeds is of greater importance to the project, however ;-p. -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] upload error using bulk_upload.py
On Wed, Jul 1, 2009 at 17:36, maning sambaleemmanuel.samb...@gmail.com wrote: I get this error using bulk_upload.py: $ python bulk_upload.py --input=pas_osm.osm --user= --password= --comment=* bulk_upload.py:42: DeprecationWarning: the sets module is deprecated import sets Uploading change set:1701375 Error uploading changeset:404 Any advice? Hi maning, that is just a warning, not an error, it says that the sets module of Python has been deprecated from the release you are actually using. It is something written toward developers and not users. You can sefely ignore it, or make it disappear using this -Wignore just after invoking python. -- -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Workshop Crowd Sourcing for Updating National Databases
Right now I was pointed to this event http://www.swisstopo.admin.ch/internet/swisstopo/de/home/current/events.html English invitation (from the same site): http://tinyurl.com/n7em9m Among others Google participates, OSM not. Didn't OSM know about this event or is participation undesirable? If the ladder is not the case, could OSM still take part this year (not as attendand, but as tutor or such)? If not this year, then in the coming or at the next event? More details: No participation fee, the language of the workshop is English. Translation of the page: | From 20. to 21. August 2009 swisstopo with EuroSDR organizes | the first EuroSDR Workshop to the subject Crowd Sourcing for | Updating National Databases in Wabern. With the background of new | technologies at the web, especially collaboration via Internet, | current aspects of user generated mapcontent and datasets and its | usage for datatracing will be discussed. | Workshop topics: | - Web 2.0 technologies and communities | - User acceptance | - Data management | - Quality issues | - Legal tasks | - Advantages and Challenges for NMCA's Regards malenki, hoping the translation isn't too bad :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Launching bestofosm.org
Martijn van Exel wrote: Great! Very useful for presentations and workshops as well. Love it. How about zoos? * Antwerp http://osm.org/go/0EpZNzMEN- * Berlin http://osm.org/go/0MZu8WGXg- * Amsterdam http://osm.org/go/0...@61hts- There's bound to be more micromapped zoos! At the two dutch zoos several buildings were created with WGS84 projection it seems. The grade of details is nice to see, but there is still place for enhancements: which cuisine at restaurants? ;) regards malenki ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Mapping party suggestion for SOTM
A few months ago in some local news media a talking head claimed that Amsterdam's Red Light District wasn't in central Amsterdam and moreover that it didn't contain any Coffee shops, i.e. ones of the type that'll sell you more than just beverages. So of course I headed over to OSM to prove both of these to be incorrect. Only to find to my disappointment that not only did the map of Amsterdam not have an area (or even a POI!) for the Red Light district, it also didn't have any sort of tagging schema for aforementioned Coffee shops. (Incidental after some searching around this is the best map I can find showing those two features: http://www.coffeeshop.freeuk.com/Map.html) So here's hoping that SOTM visitors to Amsterdam will be able to rectify this situation. The problem of coming up with a tagging schema for POIs applicable to these two categories I leave to you. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping party suggestion for SOTM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ævar Arnfjörð Bjarmason wrote: So here's hoping that SOTM visitors to Amsterdam will be able to rectify this situation. Sadly(?) the city of Amsterdam is about to close virtually the entire redlight district... so I guess it would be a historic effort ;) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkpVSBAACgkQYH1+F2Rqwn2xugCeMuNwYiWX5QwcQfn0veVwvtRn u0AAoIoivuLuU4+VJuVIgq6uq2NjtmAi =mZs7 -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping party suggestion for SOTM
On Thursday 09 July 2009 02:52:04 Ævar Arnfjörð Bjarmason wrote: Only to find to my disappointment that not only did the map of Amsterdam not have an area (or even a POI!) for the Red Light district I was looking for the shortest walking route from Amsterdam Central Station to the SOTM venue this morning and I saw it goes right through the red light district (with POI): http://www.openstreetmap.org/?lat=52.37475lon=4.90011zoom=16layers=B000FTF I can't help you with coffeeshops as I don't smoke. ;) -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] A possible way to promote OSM
Tracing rivers and such on OSM gave me an idea for a possible way to promote OSM, geography students. I mean what better way to teach kids about geography than doing a little cartography :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
++ 08/07/09 10:51 +0200 - ce-test, qualified testing bv - Gert Gremmen: Er moet een programma komen dat systematisch de database controleert op route-onmogelijkheden. Wegen die niet aansluiten op zijwegen, kapotte rotondes, breuken in wegen, tegenstrijdige access rules, rare eenrichtingswegen, kruisingen die elkaar niet echt raken. [...] Dat is er al en dat heet Keep Right. Ik gebruik dat al regelmatig en een van mijn targets op dit moment is het wegwerken van alle fouten in mijn regio die door de verschillende validators worden genoemd. Fixen op basis van ik ken de omgeving is natuurlijk nooit voldoende om alle data op te poetsen, vooral omdat je de fouten vaak niet ziet. Nee, maar wel een begin. :) -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] OpenStreetMap and Geolocation
Hallo, Kwam het volgende tegen. Misschien een idee voor openstreetmap.nl? http://weblogs.mozillazine.org/gerv/archives/2009/07/openstreetmap_and_geolocation.html Gegroet, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
keepright hoort eigenlijk in de editor te zitten. In een electronica printplaat teken programma zit bv een rulebase die zorgt dat je geen illegale dingen doet of tenminste erop geattendeerd wordt. Zoiets dergelijks zou je ook in onze editors moeten hebben. Rob Op 8 juli 2009 10:55 schreef Rejo Zenger osm-talk...@subs.krikkit.nl het volgende: ++ 08/07/09 10:51 +0200 - ce-test, qualified testing bv - Gert Gremmen: Er moet een programma komen dat systematisch de database controleert op route-onmogelijkheden. Wegen die niet aansluiten op zijwegen, kapotte rotondes, breuken in wegen, tegenstrijdige access rules, rare eenrichtingswegen, kruisingen die elkaar niet echt raken. [...] Dat is er al en dat heet Keep Right. Ik gebruik dat al regelmatig en een van mijn targets op dit moment is het wegwerken van alle fouten in mijn regio die door de verschillende validators worden genoemd. Fixen op basis van ik ken de omgeving is natuurlijk nooit voldoende om alle data op te poetsen, vooral omdat je de fouten vaak niet ziet. Nee, maar wel een begin. :) -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUBSlRfDwmUCUYh2+/UAQiYzg/+MHsOm0aoQ8hU99lDNqAqfwkzR38rvgFP 1PcueJJ3walydgiqKsCaAFKWESY5hPvDe7+5Xsagm1OzUPKqFFv4a/Iy6zXS/0nm PONRfCpayBv8B/cTCWgH3BGaw/Q5wVSrwosP2kIkkECCEW/cQeD4XzjvGY83LplW btHeGlYzFIehBGq6zY1B0RGJQykzxrxgdM5bswp5hVYsIJpTD21zlTSwlxcFDGl1 +KeKJox9TB7M5jIL0s84YO6odlFx9D8VlC5CWHYPihkwVr3skZSgi8wjzmQVLC3v 6vN2eYScD8CEfOrkSNg3NfNc0D4yJ/21aHq6vZLYBJ6n4bDf5RhWxMeQqpemTJri tpPkr0AGcaezkud9K77TmAsSbltQZ/rsbkCL7IkFtfx/i0P0i7czlIAUzVWr0AQt FspDUrhpl3Zl+So5WyjHLA+BGvp1lCbyovrYZ9dXQgfnEe3c9BGip+TAyKmywYPe YF2pjLbr48RkKb/hgwXBURg2sttpFXznvfI3BL+AiX8JCMO3nOxqrNc+xH0VWmPF /40hj+ECGTW10H3rotnW+ZW069MwfC5Lc+OM8ld3aPyHw8KSBy58dLobydXH60hX tTI+av7LXbsWWHTkpuZpzajlEXkF/EZtzFyglxCjq3M0tO5o0NT/ewbSlIhbO8aC jtvc5JDYI+Q= =X6EA -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Ook in de data zitten veel fouten maar op route gebied is het model dan ook verre van compleet. Kun je eens wat voorbeelden noemen? Een paar voorbeelden: - Ik heb gisteren bij mij in de buurt een paar oneway tags weggehaald. Op een of andere manier is de AND data daar erg verouderd. - De tagging standaards zijn gewoon fout. Voor een verboden in te rijden voor motorvoertuigen op meer dan twee wielen staat (op http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging): motor_vehicle=no motorcycle=yes moped=yes mofa=yes Dat klopt niet want dan is de weg in beide richting afgesloten. In de praktijk wordt een oneway tag gebruikt, maar wat doe je dan weer met fietsen? - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Kijk, ik kan niet zoveel doen aan het de code van die route planner, dus als daarmee iets verkeerd is houd het op. Maar, als er dingen verkeerd gerouteerd worden omdat de tagging van de straten niet correct is, dan kan ik daar wel iets mee doen. Zeker als in het in een omgeving is die ik ken. Ik fix wat ik tegenkom. Maar ik moet eigenlijk zorgen dat ik altijd GPS logger bij me heb. Want soms kom ik wegen tegen die niet in OSM zitten, en dan is het toch wel handig om een trace te hebben. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Tue, 7 Jul 2009, Philip Homburg wrote: Dat ligt niet aan de routeplanners maar aan de data. Werk aan de winkel dus! Dat klopt niet. Ik heb redelijk veel met http://yournavigation.org/ gespeeld (die natuurlijk gosmore als backend heeft) en recenter met ANDNAV2. En in beide gevallen zie je dat de navigatie software heel veel steken laat vallen. Heb je ook de andere 2 webrouteplanners bekeken? http://www.openrouteservice.org/ Deze is (voor zover ik weet) nog steeds niet helemaal open source ook al is ooit beloofd dat dit binnenkort zou gebeuren, op http://www.freeopenls.org/ De andere is http://www.cloudmade.com/ maar die doet het niet in mijn webbrowser. Met ORS ben ik tot nu toe eigenlijk alleen data fouten tegengekomen voor fietsrouting. Ook in de data zitten veel fouten maar op route gebied is het model dan ook verre van compleet. [zie volgende mail] Misschien is fiets/voetganger/etc. routing een goede applicatie is als niemand anders dat zo compleet aanbiedt als de osm/web-based routers. Met compleet bedoel ik zowel detail (fietsbruggen etc. die niet in google maps zitten) als geografische dekking (Europa of de hele wereld, terwijl de fietsersbond applicatie hoogstens heel nederland doet). Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Philip Homburg wrote: Ook in de data zitten veel fouten maar op route gebied is het model dan ook verre van compleet. Kun je eens wat voorbeelden noemen? Een paar voorbeelden: - De tagging standaards zijn gewoon fout. Voor een verboden in te rijden voor motorvoertuigen op meer dan twee wielen staat (op http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging): motor_vehicle=no motorcycle=yes moped=yes mofa=yes Dat klopt niet want dan is de weg in beide richting afgesloten. In de praktijk wordt een oneway tag gebruikt, maar wat doe je dan weer met fietsen? Dat doe ik met een generieke access tag. Die moet iemand wel een keer gaan beschrijven op de wiki: access:motor_vehicle:backward=no access:motorcycle:backward=yes access:moped:backward=yes access:mofa:backward=yes Deze tags zijn dus de eenrichtingsversie van de algemene tags die bij dat bord horen, waarbij ik even aanneem dat het bord aan het 'eind' van de way staat. Het access: voorvoegsel kan eventueel weggelaten worden. Problematischer om te taggen vind ik een combinatie die ik op dezelfde rit tegenkwam: een onverplicht fietspad bord met daaronder 'uitgezonderd X' (aanwonenden ofzo). Dat is eigenlijk geen access tag maar een conditionele highway tag. - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Sommige dingen zitten al in Validator, maar daar wordt niet vanuit een autorouter oogpunt naar gekeken. Mijn ervaring is dat op dat punt de data gemiddeld genomen behoorlijk goed is. Er zitten wel foutjes in die een validator kan vinden maar het is een relatief laag percentage. Fixen op basis van ik ken de omgeving is natuurlijk nooit voldoende om alle data op te poetsen, vooral omdat je de fouten vaak niet ziet. Bij de fouten die ik tegen komt bij het gebruik van route software is juist wel lokale kennis vereist. Om een voorbeeld te geven, het stukje fietspad waarmee je de Holterbergweg kan oversteken ontbrak voor een deel (zie http://tile.openstreetmap.nl/?zoom=18lat=52.3135lon=4.9351layers=B0FF). Dat kom je pas tegen als je daar langkomt. Eigenlijk zou het stuk fietspad aan de noordoostzijde van de Holterbergweg tijdelijk weggehaald moeten worden omdat het op dit moment ontoegankelijk is. Ik vraag me af hoeveel fietspaden die langs andere wegen lopen netjes met oneway getagd zijn. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart wrote: Dat doe ik met een generieke access tag. Die moet iemand wel een keer gaan beschrijven op de wiki: access:motor_vehicle:backward=no access:motorcycle:backward=yes access:moped:backward=yes access:mofa:backward=yes Deze tags zijn dus de eenrichtingsversie van de algemene tags die bij dat bord horen, waarbij ik even aanneem dat het bord aan het 'eind' van de way staat. Het access: voorvoegsel kan eventueel weggelaten worden. Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd fietsers wordt dan: oneway=yes + bicycle:oneway=no Die backward/forward syntax zal ook wel eens ingevoerd worden, maar is wat minder leesbaar wat mij betreft, en kan volgens mij meer gebruikt worden moest de straat ook echt verbodsborden hebben langs één zijde en geen gewone enkelrichtingsborden. - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Oh, wat een verschrikkelijk slecht idee om dat te doen :-) Temeer omdat die wegen in bepaalde situaties die categorieën juist wel toelaten. Ken de exacte regels van Nederland niet, maar hier mogen bij gebrek aan begaanbare bermen of voetpad voetgangers de rijbaan gebruiken, ook al is er een verplicht fietspad (ze mogen ook het fietspad gebruiken, wat meeste mensen dan wel normaal doen). Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien. Maar dan is het natuurlijk belangrijk om verplichte fietspaden als dusdanig te mappen, en al wat niet als een verplicht fietspad aangeduid wordt ook niet zo te mappen, zodat dat bospaadje vijftien meter parallel naast de weg niet aanzien wordt als verplicht fietspad door de routeplanner. Een tag als highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd is is dan een goed idee. Maar ja, ik ga er ook van uit dat routeplanners slim genoeg worden om verkeersregels van elk land te kunnen begrijpen. Als een weg motorcar=no is (vertaling van het verbodsbord met auto-icoon naar tag) dan moet die bv. weten dat brommobielen of motorfietsen met zijspan ook niet op de weg mogen. Want het expliciet taggen voor elk mogelijk voertuig voor zo'n bord zoals http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging op het eerste zicht schijnt te doen is geen goed idee, want zoiets krijg je al met moeite foutloos opgesteld in zo'n tabel en regelmatig denk iemand aan een ander regeltje waardoor voor een verkeersbord ineens een nieuwe extra tag nodig is (voor het verbodsbord met een auto: zie brommobielen, quads, motorfietsen met zijspan etc, die volgens de wikipagina zijn toegelaten als je geen impliciete regels invoert), en je maakt het mappers ook niet makkelijk als je hen alles expliciet laat taggen. Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
2009/7/8 Christiaan Welvaart c...@daneel.dyndns.org: - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Vergeet dan niet een foot=yes op het fietspad, want in elk geval yournavigation.org gaat er default van uit dat je op een fietspad niet mag lopen... -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Ben Laenen schreef: Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd fietsers wordt dan: oneway=yes + bicycle:oneway=no Volgens de wiki is in dit geval oneway=yes cycleway=opposite ook een oplossing. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Oh, wat een verschrikkelijk slecht idee om dat te doen :-) Temeer omdat die wegen in bepaalde situaties die categorieën juist wel toelaten. Ken de exacte regels van Nederland niet, maar hier mogen bij gebrek aan begaanbare bermen of voetpad voetgangers de rijbaan gebruiken, ook al is er een verplicht fietspad (ze mogen ook het fietspad gebruiken, wat meeste mensen dan wel normaal doen). In dat geval is foot=no natuurlijk een slecht idee: als voetgangers de weg (of de berm) mogen gebruiken, kan je foot=no weglaten. Maar bicycle=no op de hoofdweg is in dit geval wel de goede tag, volgens mij. Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien. Een routeplanner kan niet raden of een fietspad verplicht (rond blauw bord met fiets) of onverplicht (rechthoekig zwart bord met FIETSPAD) is. Een tag als highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd is is dan een goed idee. Slecht idee. Fietpaden die aangegeven worden door het bord onverplicht fietspad zijn ook fietspaden. Eugene ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Andre Engels wrote: 2009/7/8 Christiaan Welvaart c...@daneel.dyndns.org: - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Vergeet dan niet een foot=yes op het fietspad, want in elk geval yournavigation.org gaat er default van uit dat je op een fietspad niet mag lopen... Met http://yournavigation.org probeer ik de algemene routing regels te volgen totdat Gosmore afwijkende regels per land om kan gaan: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Default ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Eugene van der Pijll wrote: Ben Laenen schreef: Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd fietsers wordt dan: oneway=yes + bicycle:oneway=no Volgens de wiki is in dit geval oneway=yes cycleway=opposite ook een oplossing. Maar dan zit je met problemen als ook andere voertuigen tegen de richting mogen (in België bromfietsers klasse A, ofwel moped_A:oneway=no) In dat geval is foot=no natuurlijk een slecht idee: als voetgangers de weg (of de berm) mogen gebruiken, kan je foot=no weglaten. Maar bicycle=no op de hoofdweg is in dit geval wel de goede tag, volgens mij. Alleen mogen die ook de weg op: fietspad onderbroken bijvoorbeeld, of als je moet afslaan. Ook als het verplicht fietspad links ligt hoef je die niet te volgen als je daar een reden voor hebt (wederom Belgische regels, weet niet in hoeverre alles naar Nederland kan gebracht worden). Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien. Een routeplanner kan niet raden of een fietspad verplicht (rond blauw bord met fiets) of onverplicht (rechthoekig zwart bord met FIETSPAD) is. Dan zorg je ervoor dat die het kán raden door ze anders te taggen. Me dunkt dat er ook nog andere regels zijn die verschillen tussen verplicht en onverplicht fietspad, dus het is sowieso zinvol van dat te doen. Een tag als highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd is is dan een goed idee. Slecht idee. Fietpaden die aangegeven worden door het bord onverplicht fietspad zijn ook fietspaden. Ik doel vooral op het feit dat een pad vaak als cycleway wordt ingegeven terwijl het geen fietspad is (verplicht of onverplicht). Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Ben Laenen wrote: Christiaan Welvaart wrote: Dat doe ik met een generieke access tag. Die moet iemand wel een keer gaan beschrijven op de wiki: access:motor_vehicle:backward=no access:motorcycle:backward=yes access:moped:backward=yes access:mofa:backward=yes Deze tags zijn dus de eenrichtingsversie van de algemene tags die bij dat bord horen, waarbij ik even aanneem dat het bord aan het 'eind' van de way staat. Het access: voorvoegsel kan eventueel weggelaten worden. Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd fietsers wordt dan: oneway=yes + bicycle:oneway=no Die backward/forward syntax zal ook wel eens ingevoerd worden, maar is wat minder leesbaar wat mij betreft, en kan volgens mij meer gebruikt worden moest de straat ook echt verbodsborden hebben langs ??n zijde en geen gewone enkelrichtingsborden. Daar ging het hier over, het eerste verbodsbord op http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging . Nu maak je de discussie nodeloos ingewikkelder ): - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Oh, wat een verschrikkelijk slecht idee om dat te doen :-) Temeer omdat die wegen in bepaalde situaties die categorie?n juist wel toelaten. Ken de exacte regels van Nederland niet, maar hier mogen bij gebrek aan begaanbare bermen of voetpad voetgangers de rijbaan gebruiken, ook al is er een verplicht fietspad (ze mogen ook het fietspad gebruiken, wat meeste mensen dan wel normaal doen). In NL moeten voetgangers het verplichte fietspad gebruiken! Dit staat ook op die wiki pagina. Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien. Dat vind ik te veel werk voor een routeplanner om uit te zoeken. Maar dan is het natuurlijk belangrijk om verplichte fietspaden als dusdanig te mappen, en al wat niet als een verplicht fietspad aangeduid wordt ook niet zo te mappen, zodat dat bospaadje vijftien meter parallel naast de weg niet aanzien wordt als verplicht fietspad door de routeplanner. Een tag als highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd is is dan een goed idee. Dat kan je met 'designated' doen, d.w.z. als bicycle=designated op een pad staat (door de highway tag of anders) dan is het een verplicht fietspad, als er bicycle=yes op staat dan niet. Dit heb ik op de wiki pagina http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging ook zo aangegeven voor het onverplichte fietspadbord. Maar met de goede bicycle=no etc. tags op de hoofdrijbaan hoeft een routing app dit verschil niet te maken. Maar ja, ik ga er ook van uit dat routeplanners slim genoeg worden om verkeersregels van elk land te kunnen begrijpen. Als een weg motorcar=no is (vertaling van het verbodsbord met auto-icoon naar tag) dan moet die bv. weten dat brommobielen of motorfietsen met zijspan ook niet op de weg mogen. Want het expliciet taggen voor elk mogelijk voertuig voor zo'n bord zoals http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging op het eerste zicht schijnt te doen is geen goed idee, want zoiets krijg je al met moeite foutloos opgesteld in zo'n tabel en regelmatig denk iemand aan een ander regeltje waardoor voor een verkeersbord ineens een nieuwe extra tag nodig is (voor het verbodsbord met een auto: zie brommobielen, quads, motorfietsen met zijspan etc, die volgens de wikipagina zijn toegelaten als je geen impliciete regels invoert), en je maakt het mappers ook niet makkelijk als je hen alles expliciet laat taggen. Een routing app moet dan intern een lijst van transportmiddelen gaan aanleggen en voor elk land een andere mapping maken. Alles kan natuurlijk, dus schrijf maar een voorstel en zet het op de wiki (country specific access tag semantics for routing?), dan kunnen we kijken of mensen dit een goed idee vinden. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart wrote: Een routing app moet dan intern een lijst van transportmiddelen gaan aanleggen en voor elk land een andere mapping maken. Alles kan natuurlijk, dus schrijf maar een voorstel en zet het op de wiki (country specific access tag semantics for routing?), dan kunnen we kijken of mensen dit een goed idee vinden. country specific access tag semantics for routing, dat bestaat al hoor. Zoiets moet niet worden voorgesteld want ieder land doet het al. In land X bevat vehicle ruiters, in land Y niet. In land X mogen voetgangers op highway=cycleway, in land Y niet. access=destination is van toepassing op fietsers in land X, en niet in land Y. In België is moped zowel voor bromfietsers klasse A (snorfietsen) en B, en in NL willen jullie het Duitse mofa invoeren voor snorfietsen, en moped voor enkel onze klasse B, enzovoort. En aangezien het al bestaat en routers al een lijst hebben van regels voor elk land, kan je er beter ook maar deftig gebruik van maken om tagging regels in je land niet nodeloos moeilijk te maken om het te proberen in te passen in een internationale omgeving, een utopie die niet mogelijk is omdat het al anders is in elk land. Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Ben Laenen wrote: Christiaan Welvaart wrote: Een routing app moet dan intern een lijst van transportmiddelen gaan aanleggen en voor elk land een andere mapping maken. Alles kan natuurlijk, dus schrijf maar een voorstel en zet het op de wiki (country specific access tag semantics for routing?), dan kunnen we kijken of mensen dit een goed idee vinden. country specific access tag semantics for routing, dat bestaat al hoor. Zoiets moet niet worden voorgesteld want ieder land doet het al. In land X bevat vehicle ruiters, in land Y niet. In land X mogen voetgangers op highway=cycleway, in land Y niet. access=destination is van toepassing op fietsers in land X, en niet in land Y. In België is moped zowel voor bromfietsers klasse A (snorfietsen) en B, en in NL willen jullie het Duitse mofa invoeren voor snorfietsen, en moped voor enkel onze klasse B, enzovoort. Je zegt hier nu wel dat 'het al bestaat', maar waar kan ik dit op de wiki teruglezen? En dan heb ik het niet over verschillende beschrijvingen voor elk land-project want dat noem ik eerder chaos. En aangezien het al bestaat en routers al een lijst hebben van regels voor elk land, kan je er beter ook maar deftig gebruik van maken om tagging regels in Welke router heeft dat dan? Gosmore doet niets land specifieks volgens mij en traveling salesman alleen maxspeed de laatste keer dat ik ernaar keek. je land niet nodeloos moeilijk te maken om het te proberen in te passen in een internationale omgeving, een utopie die niet mogelijk is omdat het al anders is in elk land. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
In your letter dated Wed, 8 Jul 2009 13:35:28 +0200 (CEST) you wrote: Heb je ook de andere 2 webrouteplanners bekeken? http://www.openrouteservice.org/ Deze is (voor zover ik weet) nog steeds niet helemaal open source ook al is ooit beloofd dat dit binnenkort zou gebeuren, op http://www.freeopenls.org/ De andere is http://www.cloudmade.com/ maar die doet het niet in mijn webbrowser. Met ORS ben ik tot nu toe eigenlijk alleen data fouten tegengekomen voor fietsrouting. Nee, ik probeer zoveel mogelijk opensource te gebruiken. Maar ik zou ze vaker moeten proberen om te kijken of er interessante verschillen zijn. Ik probeerde voor de grap even Amsterdam-Stadskanaal, en ORS gaat via de Afsluitdijk, dus dat is niet optimaal. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Dat zou kunnen, maar persoonlijk zou ik liever zien dat daar een relatie voor komt en dat de routing software het dan uitzoekt. Dat zou ook bij een ventweg de extra naam schelen. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart wrote: On Wed, 8 Jul 2009, Ben Laenen wrote: En aangezien het al bestaat en routers al een lijst hebben van regels voor elk land, kan je er beter ook maar deftig gebruik van maken om tagging regels in Welke router heeft dat dan? Gosmore doet niets land specifieks volgens mij en traveling salesman alleen maxspeed de laatste keer dat ik ernaar keek. Gosmore heeft dat idd niet en volgens mij de meeste niet. Voor zover ik de applicaties bekeken heb zijn er nauwelijks routers die internationaal georienteerd zijn, laat staan de data van meerdere landen kunnen behappen. Maar mijn ervaring is dat dit soort functies ontstaan zodra een grote hoeveelheid data in OSM er klaar voor is wat dus nu ongeveer is. Kijk dus niet verbaasd als land specifieke routing over een half jaar wel redelijk kan. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart schreef: Dat kan je met 'designated' doen, d.w.z. als bicycle=designated op een pad staat (door de highway tag of anders) dan is het een verplicht fietspad, als er bicycle=yes op staat dan niet. Dat is volgens mij niet wat designated betekent. Het betekent bedoeld voor, aangewezen voor; in OSM-termen: wat er op het bordje staat. Bijv. een fietspad in NL is designated voor fietsers, en ook te gebruiken voor voetgangers. Heeft niets te maken met het onderscheid verplicht/onverplicht voor fietsers, volgens mij. Maar met de goede bicycle=no etc. tags op de hoofdrijbaan hoeft een routing app dit verschil niet te maken. +1. Zelfs als er een andere manier is om hetzelfde te taggen: een bicycle=no tag op de hoofdrijbaan is nooit verkeerd; er mag namelijk niet gefietst worden. Eugene ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart wrote: Je zegt hier nu wel dat 'het al bestaat', maar waar kan ik dit op de wiki teruglezen? En dan heb ik het niet over verschillende beschrijvingen voor elk land-project want dat noem ik eerder chaos. Welja, elk land heeft zijn eigen verschillende regels en dus bestaat het de facto. Of dat nu ergens expliciet in de wiki staat geschreven of niet, impliciet staat het er alleszins op alle landenpagina's. Maar als je het wil proberen veranderen, ik hou je niet tegen. Maar ik denk dat je een utopie probeert te bereiken daarmee. Voertuigtypes ga je nooit kunnen gelijk trekken over de hele wereld. Wat hier onder motorfiets is, is ergens anders een auto, of een bromfiets die een motorfiets is in een bepaald land. Dat is probleem 1 dus. Probleem 2 is dat de verkeersborden net iets andere betekenissen hebben in sommige landen. Neem nu bijvoorbeeld access=destination: in België betekent het dat voetgangers, fietsers en ruiters onverminderd toegang hebben tot die weg. Moeten we dan steeds expliciet foot=yes, bicycle=yes en horse=yes toevoegen enkel omdat die in land X niet de weg inmogen bij access=destination, terwijl zo'n situatie hier niet eens kán voorkomen? En terwijl veel mensen hier niet eens weten dat fietsers en ruiters daar altijd inmogen, en die die extra tags zo zouden vergeten. En aangezien het al bestaat en routers al een lijst hebben van regels voor elk land, kan je er beter ook maar deftig gebruik van maken om tagging regels in Welke router heeft dat dan? Gosmore doet niets land specifieks volgens mij en traveling salesman alleen maxspeed de laatste keer dat ik ernaar keek. Sorry, ik wou zeggen ... en routers al een lijst *zouden moeten* hebben van regels voor elk land Maar ik zie liever een OSM-library die routers en wat weet ik nog allemaal kunnen gebruiken zodat al die regels op één plaats zijn samengebracht. Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Philip Homburg wrote: Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Dat zou kunnen, maar persoonlijk zou ik liever zien dat daar een relatie voor komt en dat de routing software het dan uitzoekt. Dat zou ook bij een ventweg de extra naam schelen. Er zijn natuurlijk ook heel veel situaties waar wel een verbodsbord bij de hoofdrijbaan staat, soms overbodig. Hiervoor zal je meestal toch access tags op de weg moeten zetten, wat betekent dat de toegankelijkheid van een weg voor een bepaald voortbewegingsmiddel op minstens 2 manieren beschreven kan zijn. Dit lijkt een voorstel in deze richting te zijn: http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Eugene van der Pijll wrote: Christiaan Welvaart schreef: Dat kan je met 'designated' doen, d.w.z. als bicycle=designated op een pad staat (door de highway tag of anders) dan is het een verplicht fietspad, als er bicycle=yes op staat dan niet. Dat is volgens mij niet wat designated betekent. Het betekent bedoeld voor, aangewezen voor; in OSM-termen: wat er op het bordje staat. Wel, niemand weet het echt wat access=designated betekent. In Duitsland wisten ze het ook niet meer omdat iedereen het anders toepaste en maken ze het nu nog wat moeilijker met een access=official tag in te voeren. Maar met de goede bicycle=no etc. tags op de hoofdrijbaan hoeft een routing app dit verschil niet te maken. +1. Zelfs als er een andere manier is om hetzelfde te taggen: een bicycle=no tag op de hoofdrijbaan is nooit verkeerd; er mag namelijk niet gefietst worden. Kijk, als het fietspad verplicht is, dan is dat een eigenschap van dat fietspad, en moet je dat oplossen met tags op dat fietspad. Voor België is highway=cycleway genoeg om te zeggen dat er een verplicht fietspad is zodat als een router zo'n weg parallel ziet aan een andere weg, die kan weten dat fietsers niet via de weg kunnen (maar ook nog kan weten dat die fietser in bepaalde gevallen ook nog wel de rijbaan opmag moest de situatie daarom vragen -- tenzij er een verbodsbord staat om een of andere reden, waarbij je dus bicycle=no nodig hebt). Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Philip Homburg wrote: Ik probeerde voor de grap even Amsterdam-Stadskanaal, en ORS gaat via de Afsluitdijk, dus dat is niet optimaal. Lijkt idd een fout in de routing app want door waypoints toe te voegen kan ik de reistijd korter maken. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Check deze: http://www.routeware.dk/topology/topologychecker.php Dit zijn functies die je nodig hebt om een netwerk sane te maken. Rob wrote: keepright hoort eigenlijk in de editor te zitten. In een electronica printplaat teken programma zit bv een rulebase die zorgt dat je geen illegale dingen doet of tenminste erop geattendeerd wordt. Zoiets dergelijks zou je ook in onze editors moeten hebben. Rob Op 8 juli 2009 10:55 schreef Rejo Zenger osm-talk...@subs.krikkit.nl mailto:osm-talk...@subs.krikkit.nl het volgende: ++ 08/07/09 10:51 +0200 - ce-test, qualified testing bv - Gert Gremmen: Er moet een programma komen dat systematisch de database controleert op route-onmogelijkheden. Wegen die niet aansluiten op zijwegen, kapotte rotondes, breuken in wegen, tegenstrijdige access rules, rare eenrichtingswegen, kruisingen die elkaar niet echt raken. [...] Dat is er al en dat heet Keep Right. Ik gebruik dat al regelmatig en een van mijn targets op dit moment is het wegwerken van alle fouten in mijn regio die door de verschillende validators worden genoemd. Fixen op basis van ik ken de omgeving is natuurlijk nooit voldoende om alle data op te poetsen, vooral omdat je de fouten vaak niet ziet. Nee, maar wel een begin. :) -- Rejo Zenger . r...@zenger.nl mailto:r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUBSlRfDwmUCUYh2+/UAQiYzg/+MHsOm0aoQ8hU99lDNqAqfwkzR38rvgFP 1PcueJJ3walydgiqKsCaAFKWESY5hPvDe7+5Xsagm1OzUPKqFFv4a/Iy6zXS/0nm PONRfCpayBv8B/cTCWgH3BGaw/Q5wVSrwosP2kIkkECCEW/cQeD4XzjvGY83LplW btHeGlYzFIehBGq6zY1B0RGJQykzxrxgdM5bswp5hVYsIJpTD21zlTSwlxcFDGl1 +KeKJox9TB7M5jIL0s84YO6odlFx9D8VlC5CWHYPihkwVr3skZSgi8wjzmQVLC3v 6vN2eYScD8CEfOrkSNg3NfNc0D4yJ/21aHq6vZLYBJ6n4bDf5RhWxMeQqpemTJri tpPkr0AGcaezkud9K77TmAsSbltQZ/rsbkCL7IkFtfx/i0P0i7czlIAUzVWr0AQt FspDUrhpl3Zl+So5WyjHLA+BGvp1lCbyovrYZ9dXQgfnEe3c9BGip+TAyKmywYPe YF2pjLbr48RkKb/hgwXBURg2sttpFXznvfI3BL+AiX8JCMO3nOxqrNc+xH0VWmPF /40hj+ECGTW10H3rotnW+ZW069MwfC5Lc+OM8ld3aPyHw8KSBy58dLobydXH60hX tTI+av7LXbsWWHTkpuZpzajlEXkF/EZtzFyglxCjq3M0tO5o0NT/ewbSlIhbO8aC jtvc5JDYI+Q= =X6EA -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Street Abbv. patch for validator plugin
--- On Tue, 7/7/09, Rick Peterson ausr...@iinet.net.au wrote: I usually err on caution's side and run with the tested version of this kind of fast developing software, however I'm keen to make use of all the new features and work everyone has been putting in. I was hoping some more of my patches would be accepted by now and be filtering through however the devs of JOSM seem to be preoccupied with other things so if you want to try some of the new code I've written here is a quick how to on getting up running. Ok, I'm still using JOSM r1741 and this seems to be pretty stable, there is one release after this but I haven't upgraded to try it yet. http://josm.openstreetmap.de/download/josm-snapshot-1741.jar Also the copy of the validator.jar plugin that I built myself has a few more changes than has been applied against the trunk. http://sharebee.com/5e493b0f I'm not sure if my current plugin will work against 1669 or not, depends what other patches have been applied and I should try it I suppose. There is also the issue of the new wmsplugin not showing low res sat imagery from yahoo, if you want this you'll need to install the current plugin, exist from josm and then install the older copy: http://trac.openstreetmap.org/browser/applications/editors/josm/dist/wmsplugin.jar?rev=15962 From there you need to edit josm preferences to update mirror_tagchecker.cfg to look something like this: http://maps.bigtincan.com/tagchecker.cfg And mirror_ignoretags.cfg to look something like this: http://maps.bigtincan.com/ignoretags.cfg And you'll be bleeding edge OSM'ing :) ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Copyright and maps produced by states
Can anyone tell me when it comes to things like maps produced by various states, what ending year should I be looking at? For example a quick search of nla.gov.au brings up maps for various years for the King State Forest near Gympie in QLD. http://catalogue.nla.gov.au/Search/Home?lookfor=author:%22Queensland.%20Dept.%20of%20Forestry%22iknowwhatimean=1 If I put in a request to have maps transferred to the local library, which ones would be legal to copy from? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Copyright and maps produced by states
Can anyone tell me when it comes to things like maps produced by various states, what ending year should I be looking at? To answer my own question: http://en.wikipedia.org/wiki/Australian_copyright_law#Government-owned_copyright 50 years from the end of the first year published. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Street Abbv. patch for validator plugin
John Smith delta_foxt...@yahoo.com wrote: Java flavoured, and I'm not talking about tasting coffee here :) Java regexes are almost Perl-compatible regexes (PCRE). You are probably correct, it's taken me a number of years to get my head round regex for the amount I dabble in at present, and I have no idea which would be more efficient for the parser... Some people, when confronted with a problem, think I know, I'll use regular expressions. Now they have two problems. -- Jamie Zawinski in comp.emacs.xemacs The quote isn't quite true, but it's witty and something to keep in mind: regexes are hard to write right and even harder to read. I believe the \.? expression is more efficient than (|.), and I also think it's easier to read. -- Sam Couter | mailto:s...@couter.id.au OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Street Abbv. patch for validator plugin
--- On Wed, 8/7/09, Sam Couter s...@couter.id.au wrote: Some people, when confronted with a problem, think I know, I'll use regular expressions. Now they have two problems. -- Jamie Zawinski in comp.emacs.xemacs The regex functionality was already in place, all I was trying to do was come up with additional rules to make the functionality more useful :) ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] A possible way to promote OSM
Tracing rivers and such on OSM gave me an idea for a possible way to promote OSM, geography students. I mean what better way to teach kids about geography than doing a little cartography :) ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-br] State of the Map
Senhores, eu e Claudomiro estamos indo hoje para o State of the Map [1], evento da comunidade do OpenStreetMap. Eu pretendo twitar do evento o tempo sempre que possível contando o que está rolando. É possível acompanhar tudo que for twitado em [2]. Não sei se vai rolar streaming do evento, mas vai rolar filmagem. Assim que sair o link eu posto no twitter e aqui. Abraço. 1: http://www.stateofthemap.org/ 2: http://twitter.com/#search?q=%23sotm09 -- Arlindo Saraiva Pereira Jr. Bacharelando em Sistemas de Informação - UNIRIO - uniriotec.br Consultor de Software Livre da Uniriotec Consultoria - uniriotec.com Acadêmico: arlindo.pere...@uniriotec.br Profissional: arlindo.pere...@uniriotec.com Geral: cont...@arlindopereira.com Tel.: +5521 92504072 Jabber/Google Talk: nig...@nighto.net Skype: nighto_sumomo Chave pública: BD065DEC ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Announce: Bookmarklet für load into josm
Hi! Claudius schrieb: - Pluginordner von JOSM händisch aufräumen. Wo finde ich den? - Neueste JOSM-Version installieren Klar, hab mir natürlich als erstes die neuste Version gezogen. Was genau meinst du mit Konsolenfenster? Sprichst du vom Einstellungsdialog von JOSM? JOSM öffnet bei mir zwei Fenster, die eigentliche GUI und ein Textfenster mit dem Konsolenoutput ( Downloadmeldungen, Laden von Plugins, Exceptions). bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eierlegende Wollmilchkarte
Original-Nachricht Datum: Tue, 7 Jul 2009 08:29:28 +0200 Von: Sven Sommerkamp s_sommerk...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Eierlegende Wollmilchkarte Ich eigentlich nicht, mir wäre das zu wenig. Meiner Ansicht nach orientiert sich OSM eh schon viel zu stark an Google Maps, weil viele ein klares Ziel vor Augen haben wollen. Das mit dem klaren Ziel ist etwas sehr Wünschenswertes! Dadurch bekommt ein Projekt Struktur und es wird nicht Moral und Arbeit vergeudet. Auch bei meinem Opensuse Projekt gibt es Ziele (Meilensteine) auf die hingearbeitet wird. Und es ist mir daher eine Freude mit Opensuse zu arbeiten! Klar sind klare Ziele etwas gutes, aber man sollte sich nicht eine mittelmaessige Interpretation eines kaufbaren Datensatzes zum Vorbild nehmen, wenn man besser sein will. Google Maps ist eine vereinfachende Abbildung eines komplexen Gebildes, das immer mehr dazulernt. Wer sich an klaren Zielen ausrichten will, sollte sich vielleicht auch mal die Datenmodelle dahinter ansehen. Mal am konkreten Beispiel: Die Klassifizierungen der Strassen bei Google Maps sind zum davonlaufen und die administrative Einteilung dominiert vor Ausbauzustand und verkehrlicher Bedeutung. In den Daten, die in die Visualisierung einfliessen, sind diese Dinge aber getrennt aufgelistet, so dass man herausheben kann was man will. Richtet man sich an Google Maps aus, verliert man diese Variationen. Gruesse Hubert -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import in Österreich (war: Eierleg ende Wollmilchkarte)
Original-Nachricht Datum: Tue, 07 Jul 2009 10:41:37 +0200 Von: Claudius claudiu...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Import in Österreich (war: Eierlegende Wollmilchkarte) Am 05.07.2009 21:12, qbert biker: In der Gegend gibts auch eine astreine Datenqualität, die auf einen Datenimport aus professioneller Quelle hinweist. http://www.informationfreeway.org/?lat=48.77468565338101lon=16.503716155140424zoom=13layers=BF000F Da bist du schon nach Österreich gerutscht und der dortige Detailgrad kommt vom Plan.at-Import: http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_plan.at Stimmt natuerlich, sorry! Und danke fuer die Info. Dem von Frederick angedeuteten Gemotze zum Trotz und auch wenns wirklich mal 100m daneben sein sollte, macht was her! Gruesse Hubert -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eierlegende Wollmilchkarte
Hallo Hubert, Klar sind klare Ziele etwas gutes Unbedingt! Die Seeleute sagen: Wer nicht weiss wo er hin will, braucht sich nicht wundern, wenn er ganz woanders ankommt ;-) [1] Google Maps ist eine vereinfachende Abbildung eines komplexen Gebildes, das immer mehr dazulernt. Wenn wir wüssten was Google weiss würde manchem Angst und Bange werden. Allerdings sind wir beim akribischen Datensammeln zumindest im Geo-Daten-Bereich ein ernstzunehmender Mitbewerber :-) Da wo wir aktiv am Sammeln sind, sind unsere Karten schon seeehr gut. Gruss, Markus [1] Wobei das auch spannend sein kann (Kolumbus und so). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WG: www.freietonne.de - Upload unsererSeekartendatennach OSM gestartet
Guenther Meyer wrote: wenn als irgendwas den sektor von norden bis osten beleuchtet, dann ist das fuer mich 0°-90°. Nochamal, Markus hatte es ja schon erklärt: in der Admiralty List Of Lights And Fog Signals sind für Sektoren immer Peilungsrichtungen angegeben. Machts daraus doch bitte kein Drama, sondern nehmt es zur Kenntnis. Z.B.: Rt Vnetak auf Unje 44° 37.2' N, 014° 14.4' E hat W270°-158°(248°), R158°-176°(18°). (http://www.openstreetmap.org/?lat=44.6208lon=14.2516zoom=13 an der SW-Spitze von Unje) (http://www.plovput.hr/eng/tabid/212/Default.aspx) Wenn Du also aus Unje mit Kurs etwa 300° rausfährst, weißt Du, daß Du im Süden das Rt Vnetak suchen mußt, und wenn das dann die Farbe von Rot auf Weiß ändert, darfst Du nach S (max. 158°) drehen, ohne an Unje anzuschrammen. Und das funktioniert bei stockdunkler Nacht und dabei ist Dir schnurzpiep egal, daß das Licht in die entgegengesetzte Richtung leuchten muß, damit Du es siehst. Und wenn Du einen Renderer baust, der das aufzeichnet, dann mußt Du halt die 180° dazurechnen. Nicht wirklich ein Drama... :) Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten
Hallo Wolfgang, dieser Thread ist ja nun schon ziemlich lang. Aber irgendwie fehlt mir der zusammengefasste Konsens. Was also ist best practice für: - Kindergarten-Gebäude - Kindergarten-Gelände Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eierlegende Wollmilchkarte
Original-Nachricht Datum: Wed, 08 Jul 2009 09:06:22 +0200 Von: Markus liste12a4...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Eierlegende Wollmilchkarte Hallo, Die Seeleute sagen: Wer nicht weiss wo er hin will, braucht sich nicht wundern, wenn er ganz woanders ankommt ;-) [1] Wird spannend, wo OSM mal ankommt ;) Google Maps ist eine vereinfachende Abbildung eines komplexen Gebildes, das immer mehr dazulernt. Wenn wir wüssten was Google weiss würde manchem Angst und Bange werden. Man muss hier schon aufschluesseln, was sie einkaufen und was sie selber erheben. Im Falle der eingekauften Daten muss man sich ja eher Navtech und Teleatlas ansehen. Die haben schon mal die amtlichen Strassenlisten und dazu noch sehr gute Eigenerhebungen. Die Technik mit der sie unterwegs sind, wurde ja auch mal in der c't gut beschrieben, z.B. das Beste was (Differential-)GPS zu bieten hat, zusammen mit unterstuetzender Technik des KFZ. Dazu noch Kameratechnik, die die exakte Erfassung von Strassenquerschnitten, Schildern, Spuren, etc. erlaubt. Daraus kann man dann die Dinge bauen, an die bei OSM noch gar nicht zu denken ist, wie Spurwechselassistenten oder 3D- Spielereinen mit Heauserfronten. Google selber hat dann noch einiges an eigenen Daten. Das alles schmeissen sie natuerlich nicht dem Kostenlosanwender von Google Maps hinterher. Allerdings sind wir beim akribischen Datensammeln zumindest im Geo-Daten-Bereich ein ernstzunehmender Mitbewerber :-) Da wo wir aktiv am Sammeln sind, sind unsere Karten schon seeehr gut. Freilich, nur wirds mal Zeit, das mit eigenen Kriterien und eigenem Qualitaetsmanagement herauszuarbeiten. Freilich passiert schon einiges in diese Richtung, aber viele geben sich der truegerischen Sicherheit hin, dass der kleine Seitenblick auf Google Maps ausreicht. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WG: www.freietonne.de - Upload unsererSeekartendatennach OSM gestartet
Hallo Andreas, Jan Jesse wrote: Das muß ich glauben, die Angaben in den Verzeichnissen sind ja so seltsam. Aber verstehen verstehe ich das nicht. Heißt vom Schiff aus gepeilt immer, daß die Küste im Süden liegt? Oder geht es tatsächlich um das berühmte Banditen in 09.00 Uhr, was technisch dann kaum zu bewältigen wäre? Bitte denke mal kurz nach: - wenn ich ein Leuchtfeuer in 0° (im N) anpeile, so sehe ich den Strahl, der nach S zeigt - wenn ich ein Leuchtfeuer in 90° (im O) anpeile, so sehe ich den Strahl, der nach W zeigt - wenn ich ein Leuchtfeuer in 180° (im S) anpeile, so sehe ich den Strahl, der nach N zeigt - wenn ich ein Leuchtfeuer in 270° (im W) anpeile, so sehe ich den Strahl, der nach O zeigt und dazwischen analog. Oder anders gesagt: wenn wir aufeinander zufahren, wie groß ist dann die Richtungsdifferenz unserer Kurse? ;) Servus, Andreas Das war eine schöne Erklärung. Aber wenn ich ihn tagge, BIN ICH DER LEUCHTTURM :-) Ich denke, wir sind dabei, unsere Daten in OpenStreetMap zu integrieren. Und da weiß ich nicht, ob wir tatsächlich unsere eigene Sicht der Welt gleich mit exportieren müssen. Die Darstellung eines Nodes sollte aus der Position des Nodes erfolgen. Der ist immer da. Der Skipper hingegen ist immer unterwegs. Was die Segelanweisung sagt, ist der Tonne glaub ich egal. mappen wir also die Daten für die Karte, oder für die Segelanweisung? Beste Grüße aus Berlin JJ www.freietonne.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Format für Datenimport?
Hallo, ich habe die Möglichkeit Geodaten von der Stadt zu bekommen (Stadtteilgrenzen). Welches Datenformat wäre dafür am besten, womit hat man am wenigsten Arbeit? Wer bei OSM ist Ansprechparner für sowas? Danke Jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Bookmarklet für load into josm
Nop ekkeh...@gmx.de wrote: Klingt sehr interessant. Leider habe ich Schwierigkeiten mit JOSM und dem remote-Plugin, das man dafür braucht. Das Plugin läßt sich nicht installieren. Der Download des Plugins wird von JOSM zwar als erfolgreich bestätigt, aber es taucht dann nicht auf dem Konsolenfenster auf. Version 1729 von JOSM. Ich benutze immer http://josm.openstreetmap.de/download/josm-latest.jar Das ist gerade 1746 und damit läuft das remote plugin. Wenn das Plugin Aktiv ist gibts in den Settings ein Fernbedienungssymbol, bei dem man das konfigurieren kann. Gruss Sven -- Every time you use Google, you're using a Linux machine (Chris DiBona, a programs manager for Google) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Bookmarklet für load into josm
Nop ekkeh...@gmx.de wrote: JOSM öffnet bei mir zwei Fenster, die eigentliche GUI und ein Textfenster mit dem Konsolenoutput ( Downloadmeldungen, Laden von Plugins, Exceptions). Jo, auf der Konsole sollte loading remotecontrol auftauchen. Sven -- All bugs added by David S. Miller da...@redhat.com Linux Kernel boot message from /usr/src/linux/net/8021q/vlan.c /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WG: www.freietonne.de - Upload unsererSeekartendatennach OSM gestartet
Hallo Andreas, Guenther Meyer wrote: wenn als irgendwas den sektor von norden bis osten beleuchtet, dann ist das fuer mich 0°-90°. Nochamal, Markus hatte es ja schon erklärt: in der Admiralty List Of Lights And Fog Signals sind für Sektoren immer Peilungsrichtungen angegeben. Machts daraus doch bitte kein Drama, sondern nehmt es zur Kenntnis. Z.B.: Rt Vnetak auf Unje 44° 37.2' N, 014° 14.4' E hat W270°-158°(248°), R158°-176°(18°). (http://www.openstreetmap.org/?lat=44.6208lon=14.2516zoom=13 an der SW-Spitze von Unje) (http://www.plovput.hr/eng/tabid/212/Default.aspx) Wenn Du also aus Unje mit Kurs etwa 300° rausfährst, weißt Du, daß Du im Süden das Rt Vnetak suchen mußt, und wenn das dann die Farbe von Rot auf Weiß ändert, darfst Du nach S (max. 158°) drehen, ohne an Unje anzuschrammen. Und das funktioniert bei stockdunkler Nacht und dabei ist Dir schnurzpiep egal, daß das Licht in die entgegengesetzte Richtung leuchten muß, damit Du es siehst. Und wenn Du einen Renderer baust, der das aufzeichnet, dann mußt Du halt die 180° dazurechnen. Nicht wirklich ein Drama... :) Servus, Andreas ist kein Drama, sagt auch keiner. Nur ist es dann halt für den Laien (mich) auch nicht schlüssig. Aus meiner Sicht, bevor sich hier wieder sonstwas entwickelt, kann doch jeder dranschreiben, wie es gemeint ist (z.B. from_lighthouse und to_lighthouse). Wir werden mal drüber nachdenken und für die von uns erfaßten Nodes irgendwas eindeutiges verzapfen. Das dürfen wir doch, oder? ;-) Und wenn die Diskussion ein Resultat hat, bauen wir um. Oder zeichnet sich ein schneller Konsens ab? ;-) JJ www.freietonne.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WG: www.freietonne.de - Upload unsererSeekartendatennach OSM gestartet
Vielleicht noch ein leichter verständliches Beispiel: An der Mole von Unje ist ein Fl R 3s mit einer Vis 093°-146°(53°). Das heißt, mit einem Ansteuerkurs 093° bis 146° kannst Du auf das Feuer zusteuern und kommst in die Bucht hinein. Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Format für Datenimport?
Jens Herrmann o...@bikelab.org wrote: ich habe die Möglichkeit Geodaten von der Stadt zu bekommen (Stadtteilgrenzen). Welches Datenformat wäre dafür am besten, womit hat man am wenigsten Arbeit? Am besten wäre OSM Format :) Spass beiseite, normalerweise kriegt man alles irgendwie gelesen. Die GIS Leute haben meist shapefiles, die sind soweit OK. Wer bei OSM ist Ansprechparner für sowas? AFAIK gibts da leider keinen, aber für sowas einfaches wie Stadtteilgrenzen darfst Du dich gerne per Mail an mich wenden, das kriegen wir schon rein. Gruss Sven -- Threading is a performance hack. (The Art of Unix Programming by Eric S. Raymond) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eierlegende Wollmilchkarte
Hallo Hubert, Wenn wir wüssten was Google weiss würde manchem Angst und Bange werden. Navtech und Teleatlas ansehen: amtlichen Strassenlisten das Beste was (Differential-)GPS zu bieten hat, unterstuetzende Technik des KFZ Kameratechnik, exakte Erfassung von Strassenquerschnitten, Schildern, Spuren, etc. Für Google zählt das Ergebnis (egal ob eingekauft, von Benutzern gespendet oder selbst erhoben). Daraus kann man dann die Dinge bauen, an die bei OSM noch gar nicht zu denken ist, wie Spurwechselassistenten oder 3D- Spielereinen mit Heauserfronten. Google selber hat dann noch einiges an eigenen Daten. Ja. Ich hatte letzten Monat ein Date mit Google-Europa - das ist höchst beeindruckend, was die in der Pipeline haben! Das alles schmeissen sie natuerlich nicht dem Kostenlosanwender von Google Maps hinterher. :-) Allerdings sind wir beim akribischen Datensammeln zumindest im Geo-Daten-Bereich ein ernstzunehmender Mitbewerber :-) Da wo wir aktiv am Sammeln sind, sind unsere Karten schon seeehr gut. Freilich, nur wirds mal Zeit, das mit eigenen Kriterien und eigenem Qualitaetsmanagement herauszuarbeiten. Ja. Und da geschieht ja bereits sehr viel an den unterschiedlichsten Stellen von OSM. Jochen hatte auf der Fossgis auch über QM referiert.Jochen's neuester Beitrag www.bestofosm.org ist ein weiterer Schritt. Und Gerhard hat eine Vielzahl potenter Tools zum Thema Qualität entwickelt. Und die Strassentools von Sven und Florian, und das Q-Tool von Monty, und viele mehr. Gibt es eigentlich eine QM-Seite im Wiki, wo solche Aktivitäten übersichtlich zusammengefasst beschrieben sind? (ich habe nichts gefunden) viele geben sich der truegerischen Sicherheit hin, dass der kleine Seitenblick auf Google Maps ausreicht. Noch besorgniserregender finde ich unsere wirklich gute Leistung, und die Anerkennung die wir weltweit geniessen, und die uns manchmal dazu verleitet, uns erst mal zufrieden auszuruhen (was wir zusteht!), und dabei zu übersehen, was noch alles offen ist - und in der Folge manchmal einfach so weitermachen wie bisher (denn das hat sich ja bewährt) - und so eben verpassen uns lohnenden Ziele zu stecken. So eine multifunktionale Karte (Eierlegende Wollmilchkarte) auf unserer Hauptseite wäre schon ein Hit! Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WG: www.freietonne.de - Upload unsererSeekartendatennach OSM gestartet
ist kein Drama, sagt auch keiner. Nur ist es dann halt für den Laien (mich) auch nicht schlüssig. Aus meiner Sicht, bevor sich hier wieder sonstwas entwickelt, kann doch jeder dranschreiben, wie es gemeint ist (z.B. from_lighthouse und to_lighthouse). Wir werden mal drüber nachdenken und für die von uns erfaßten Nodes irgendwas eindeutiges verzapfen. Disclaimer: ich bin auch Segler. Ich dachte eigentlich das man in OSM etablierte Standards (die zudem Sinn machen) respektieren würde. Außerdem sehe ich hier überhaupt keine Problematik. Es wird niemand die Sektoren eines Leuchtturms selbst erfassen (dazu müsste er ja einmal 360° um das Ding rumlaufen und das dürfte ziemlich nass werden). Ergo werden auch nicht-Segler (wenn sie sich damit überhaupt beschäftigen) die Daten aus freien Verzeichnissen abschreiben - und da stehts nun mal meist als 0° = S drin. Also ist diese Lösung auch intuitiver. Die Lösung mit from_lighthouse und to_lighthouse würde voraussetzen, dass sich der Mapper vorher im Wiki kundig macht. Wenn er das tut, kann er dort auch lesen, dass Sektoren immer von Süden aus getaggt werden. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WG: www.freietonne.de - Upload unsererSeekartendatennach OSM gestartet
Hallo Jan! Darf ich's mal so sagen: sollen eher die umdenken, die taggen (und die ALL abschreiben oder sowas), oder die, die die Renderer bauen? Ich hielte es schon für sinnvoll, beim Tagging die gängige Nomenklatur zu verwenden. Schon bei einem Leuchtfeuer mit zwei Sektoren hast Du 3-4 Möglichkeiten, Dich zu irren. Dann müssen die zwei Leute, die Renderer dafür bauen, halt +180 rechnen. Das müssen sie genau einmal richtig machen. Das ist ihnen zuzumuten, denke ich... ;) Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten
Am Mittwoch, 8. Juli 2009DE 09:27:23DE schrieb Markus: Hallo Wolfgang, dieser Thread ist ja nun schon ziemlich lang. Aber irgendwie fehlt mir der zusammengefasste Konsens. Was also ist best practice für: - Kindergarten-Gebäude - Kindergarten-Gelände Konsens? Kicher. Der Link zeigt dir ein Gebiet mit 4 verschiedenen Schulen, die unterschiedlich gemappt worden sind. Schau es dir an, und dann mach es so, wie Du es für richtig hälst. http://www.informationfreeway.org/?lat=53.59928226809326lon=10.047908675483637zoom=16layers=BF000F -- Mit freundlichen Grüßen René Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WG: www.freietonne.de - Upload unsererSeekartendatennach OSM gestartet
Hallo, Darf ich's mal so sagen: sollen eher die umdenken, die taggen (und die ALL abschreiben oder sowas), oder die, die die Renderer bauen? Ich hielte es schon für sinnvoll, beim Tagging die gängige Nomenklatur zu verwenden. Schon bei einem Leuchtfeuer mit zwei Sektoren hast Du 3-4 Möglichkeiten, Dich zu irren. Dann müssen die zwei Leute, die Renderer dafür bauen, halt +180 rechnen. Das müssen sie genau einmal richtig machen. Das ist ihnen zuzumuten, denke ich... ;) Ich möchte jetzt nicht falsch verstanden werden. Mir persönlich ist es ziemlich egal. Ich hatte nur geschrieben Wenn ich mir was wünschen darf. Ich selbst benutze die OSM Daten für die elktronische Navigation auf dem Laptop bei Tagfahrten, sehe also wo ich bin. Leuchttürme sind als Bauwerke und Landmarken für mich wichtig, die Lichter sehe ich nur im Hafen :-) Ich gehe davon aus, das die Eintragungen auch für den normalen Mapper eindeutlig lesbar sein sollten. Wenn sie das so sind, dann ist alles gut. Den Nachweis überlasse ich gern der Zukunft. In der FreieTonne haben wir uns um das Problem noch nicht gekümmert, können aber die 180 durchaus einfach addieren :-) Und wenns dann jemand anders taggen will, schaffen wir das auch. Beste Grüße aus Berlin JJ www.freietonne.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenqualität von OSM
Danke, ja, die Aussage der Karte ist lediglich ein Vergleich von Datensatz A in Bezug auf B. Wie viel A oder B mit der Realität zu tun haben kann hieraus nicht wirklich abgelesen werden. Eine Überpüfung vor Ort ist im gegebenen Rahmen kaum möglich... Dennoch könnten die Ergebnisse für einige User interessant sein. beste Grüße az Latze schrieb: ... Vom Prinzip her eine gute Idee. Ich frage mich nur, wie einige andere hier auch, ob und vor allem wie die Fehler (und da gibt es einige; nicht nur kleine) von TeleAtlas kompensiert werden? Ich stelle es mir sehr schwer vor, da zu unterscheiden, ob nun TeleAtlas oder OpenStreetMap falsche Daten hat. Ich kenne auch einige Beispiel, wo man nach TeleAtlas zwar eine Straße haben soll, in der Realität aber vor Bäumen und Büschen steht, die nicht erst seit 5 Jahren dort wachsen. Auch Siedlungen wo die Straßen, nach TeleAtlas, quer durch Häuser und Gärten gehen. Gruß Latze ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenqualität von OSM
Danke auf jeden Fall für die Nachricht. Ich persönlich finde deine Arbeit sehr interessant und würde mich freuen, wenn du uns darüber auf dem laufenden hältst. Wenn du die Zeit dazu hast: mich würden die verschiedenen Möglichkeiten zur Datenauswertung sehr interessieren. Grüße, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eierlegende Wollmilchkarte
Moin 2009/7/8 Markus liste12a4...@gmx.de Für Google zählt das Ergebnis (egal ob eingekauft, von Benutzern gespendet oder selbst erhoben). Ich glaube Google würde auch sofort auf OSM Daten umsteigen, wenn sie dadurch die Qualität ihrer Dienste verbessern können. Google ist ja kein Anbieter von GeoDaten sondern mehr ein Dienstleiser aller Tools drumherum und daher keine Konkurrenz zu OSM sondern eher ein Potentieller Kunde. Deswegen finde ich die Vergleiche mit Googl Maps etc auch etwas unpassend. Vergleichen tun wir auf diesem Wege ja nur die Daten von Navtec etc. Gibt es eigentlich eine QM-Seite im Wiki, wo solche Aktivitäten übersichtlich zusammengefasst beschrieben sind? (ich habe nichts gefunden) Es gäbe da http://wiki.openstreetmap.org/wiki/Qualit%C3%A4tssicherung So eine multifunktionale Karte (Eierlegende Wollmilchkarte) auf unserer Hauptseite wäre schon ein Hit! Mir wäre eine Übersicht der schon vorhandenen guten Anwendungsmöglichkeiten unserer GeoDaten als Hauptseite lieber. Momentan glauben viele ja leider, dass das Ergebnis der Mapnik Karte auf der osm Seite das Produkt unserer Arbeit ist, dabei wird dort nur ein Bruchteil dessen Visualisiert, was wir an GeoDaten in Wirklichkeit schon zusammengetragen haben. Beeindruckende Ergebnisse wie die 3D Karte, OSR, die ÖPNV Karte oder die andren diversen spezialisierten Karten fallen da leider oftmals unter den Tisch. Gruß Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eierlegende Wollmilchkarte
Beeindruckende Ergebnisse wie die 3D Karte, OSR, die ÖPNV Karte oder die andren diversen spezialisierten Karten fallen da leider oftmals unter den Tisch. Gruß Jörg Und damit sind wir wieder bei der Diskussion, wie OpenStreeMap.org aussehen sollte ... Ich denke auch, dass da der Fkus zu sehr auf einigen wenigen Kartenstilen liegt und man sich eher darauf konzentrieren sollte hier die Alternativen und Möglichkeiten sinnvoll zu präsentieren. Grüße, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hello from England
Hi, SteveC wrote: Well what else would they say, it's the only license they have that even applies. If you asked Microsoft what OS you should use, what do you think they would say? The other problem is they've made the leap from just providing licenses to taking a moral stance against anything but PD for data. All data in the entire world. That's nuts. I'm glad we have settled that Creative Commons officially suggested to us that we use CC0 for OpenStreetMap, rather than this just being a personal opinion of an individual as you seemed to suggest earlier. (Schoen, dass wir feststellen koennen: Creative Commons hat uns offiziell empfholen, ihre CC0-Lizenz fuer OSM zu nutzen; es handelte sich dabei nicht um eine Einzelmeinung, wie Du zuvor angedeutet hattest.) Also, there is no doubt that Creative Commons are quite well respected in the Free and Open community and have in the past been champions of the share-alike idea. (Ausserdem besteht kein Zweifel daran, dass Creative Commons in der Freien und Offenen community relativ gut angesehen sind und in der Vergangenheit durchaus auch die Share-Alike-Idee vertreten haben.) That's the only thing I wanted clearly said. Whether CC say what they say because they believe it is the best thing to do in the interests of the Free and Open community, or whether they just do so out of fear of being obliterated, or because they have a satanic portal in their headquarters, is something that everyone can think about for themselves. (Das ist alles, was ich klargestellt haben wollte. Ob CC das agen, weil sie glauben, es ist das beste fuer die Freie und Offene community, oder weil sie einfach nur Angst haben, ueberfluessig zuwerden, oder weil sie ein satanisches Portal im Keller haben, darueber kann sich jeder ja selber Gedanken machen.) (Hintergrund fuer talk-de: Wenn irgendjemand SteveC wegen irgendwas niedere Motive unterstellt, sagt er gern sowas wie Jaja, ich habe ein satanisches Portal im Keller, um die Vorwuerfe ins Laecherliche zu ziehen - da konnte ich nicht widerstehen, hier, wo er Creative Commons niedere Motive unterstellt, ebenso zu erwidern.) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hello from England
On 8 Jul 2009, at 11:55, Frederik Ramm wrote: Hi, SteveC wrote: Well what else would they say, it's the only license they have that even applies. If you asked Microsoft what OS you should use, what do you think they would say? The other problem is they've made the leap from just providing licenses to taking a moral stance against anything but PD for data. All data in the entire world. That's nuts. I'm glad we have settled that Creative Commons officially suggested to us that we use CC0 for OpenStreetMap, rather than this just being a personal opinion of an individual as you seemed to suggest earlier. Um, no, I don't think I've seen it. do you have a link? (Schoen, dass wir feststellen koennen: Creative Commons hat uns offiziell empfholen, ihre CC0-Lizenz fuer OSM zu nutzen; es handelte sich dabei nicht um eine Einzelmeinung, wie Du zuvor angedeutet hattest.) Also, there is no doubt that Creative Commons are quite well respected in the Free and Open community and have in the past been champions of the share-alike idea. (Ausserdem besteht kein Zweifel daran, dass Creative Commons in der Freien und Offenen community relativ gut angesehen sind und in der Vergangenheit durchaus auch die Share-Alike-Idee vertreten haben.) That's the only thing I wanted clearly said. Whether CC say what they say because they believe it is the best thing to do in the interests of the Free and Open community, or whether they just do so out of fear of being obliterated, or because they have a satanic portal in their headquarters, is something that everyone can think about for themselves. (Das ist alles, was ich klargestellt haben wollte. Ob CC das agen, weil sie glauben, es ist das beste fuer die Freie und Offene community, oder weil sie einfach nur Angst haben, ueberfluessig zuwerden, oder weil sie ein satanisches Portal im Keller haben, darueber kann sich jeder ja selber Gedanken machen.) (Hintergrund fuer talk-de: Wenn irgendjemand SteveC wegen irgendwas niedere Motive unterstellt, sagt er gern sowas wie Jaja, ich habe ein satanisches Portal im Keller, um die Vorwuerfe ins Laecherliche zu ziehen - da konnte ich nicht widerstehen, hier, wo er Creative Commons niedere Motive unterstellt, ebenso zu erwidern.) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Best Steve ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten: Konsensvorschlag Anlagenmapping
Hallo Tobias, Ist folgende Vorgehensweise konsensfähig? Gelände: amenity=kindergarten name=* [weitere Geländeattribute] Gebäude: building=yes (oder sonst ein Wert) [weitere Gebäudeattribute] Ausführlich beschrieben: * Das Gelände der amenity (z.B. amenity=kindergarten) wird als Fläche erfasst. Sämtliche Tags, die für die ganze Anlage gelten (etwa der Name) werden nur einmal angegeben, und zwar am mit amenity=* getaggten Way. * Die Gebäude der Anlage werden als building=yes (oder auf Wunsch mit spezifischerem Wert) gekennzeichnet. Sie erhalten _nicht_ nochmal das amenity=*, und Tags beziehen sich nur aufs jeweilige Gebäude (falls die Gebäude z.B. eigene Namen etc. haben). Analog für sonstige Bestandteile der Anlage (Sandkästen, Rutschen, ...). * site-Relationen können optional verwendet werden (etwa für komplizierte Anlagen). Ja, das wäre eine klare Unterscheidung von Gelände und Häusern. Diese müsste sich dann aber unbedingt auch in den Vorlagen wiederfinden. (Dein Vorschlag steht aber im Widerspruch zur jetzigen Gepflogenheit, die Häuser zu unterscheiden und die Flächen nicht zu beschreiben, Du kehrst das sozusagen um) Was Deinem Vorschlag noch fehlt ist noch eine ebenso klare Bezeichnung der Häuser. Wenn beispielsweise nur das Kindergartenhaus eingetragen wird, dann müsste das Haus als Kindergarten von normalen Häusern unterscheidbar sein. Und wenn auf dem Gelände mehrere Häuser stehen, dann muss unterscheidbar sein, welches der Kindergarten ist (und welches beispielsweise nur das Wohnhaus des Hausmeisters oder so). Man könnte es so versuchen: Gelände: site=Kindergarten (oder ein anderer aussagekräftiger Schlüssel für Gelände) Haus: building=Kindergarten Bei den Häusern kann man ja bereits Werte für den Schlüssel building angeben. Aber da ist nicht klar, ob damit Nutzungsarten oder architektonische Formen beschrieben werden sollen? Und manchmal wird dem Haus auch noch ein amenity zugeordnet. Für die beiden Klassen Nutzung und Form sollte man m.E. zwei verschiedene Attribute verwenden. (Beispielsweise gibt es Häuser die wie eine Kirche aussehen, die als religiöser Treffpunkt genutzt werden, und andere (die ebenfalls wie eine Kirche aussehen und auch mal als solche genutzt wurden), die als Museum, als Disco, als Geschäftshaus oder so genutzt werden. Kindergarten ist hier exemplarisch gemeint, soll aber übertragbar sein auf alle Geländenutzungen mit Häusern drauf (Schule, Krankenhaus, Bahnhof, Schwimmbad, Sportplatz, etc) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten: Konsensvorschlag Anlagenmapping
Am Mittwoch, 8. Juli 2009DE 12:00:59DE schrieb Tobias Knerr: Bisher gab es z.B. keine Proteststürme gegen mein Mail http://lists.openstreetmap.org/pipermail/talk-de/2009-July/049862.html Also versuch ichs mal: Ist folgende Vorgehensweise konsensfähig? Gelände: amenity=kindergarten name=* [weitere Geländeattribute] Gebäude: building=yes (oder sonst ein Wert) [weitere Gebäudeattribute] Ausführlich beschrieben: * Das Gelände der amenity (z.B. amenity=kindergarten) wird als Fläche erfasst. Sämtliche Tags, die für die ganze Anlage gelten (etwa der Name) werden nur einmal angegeben, und zwar am mit amenity=* getaggten Way. * Die Gebäude der Anlage werden als building=yes (oder auf Wunsch mit spezifischerem Wert) gekennzeichnet. Sie erhalten _nicht_ nochmal das amenity=*, und Tags beziehen sich nur aufs jeweilige Gebäude (falls die Gebäude z.B. eigene Namen etc. haben). Analog für sonstige Bestandteile der Anlage (Sandkästen, Rutschen, ...). So weit würde ich das auch machen. * site-Relationen können optional verwendet werden (etwa für komplizierte Anlagen). Auch bei weniger komplizierten Anlagen macht eine Kennzeichnung das gehört zusammen Sinn. Auf einer Karte sieht das relativ selbstverständlich aus und ist oft nicht nötig, für die Datenbank ist das aber eine durchaus nützliche Info. -- Mit freundlichen Grüßen René Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hello from England
Hi, SteveC wrote: I'm glad we have settled that Creative Commons officially suggested to us that we use CC0 for OpenStreetMap, rather than this just being a personal opinion of an individual as you seemed to suggest earlier. Um, no, I don't think I've seen it. do you have a link? http://www.sciencecommons.org/resources/readingroom/comments-on-odbl Then, http://lists.openstreetmap.org/pipermail/legal-talk/2009-June/002508.html and http://lists.openstreetmap.org/pipermail/legal-talk/2009-June/002513.html which you know because you replied to them. In February 2008, the OSM Wiki contained the following words written by yourself: We would have liked Creative Commons to have offered a sharealike/attribution data licence that we could adopt. However, their position is that map data should be dedicated to the public domain, ... http://wiki.openstreetmap.org/index.php?title=Open_Data_License_FAQoldid=77256 When I inquired, I received the following response from OSMF board member RichardF who was in charge at the time: Creative Commons' position is this (summarised from an e-mail to OSMF by John Wilbanks, head of Science Commons, to which CC has expressly delegated its policy on data licensing) ... This was in the February 2008 legal-talk thread Progressing OSM to a new data Licence regime which you know because you wrote half of the messages in it. I hope that suffices to refresh any lost memory ;-) Bye Frederik (Fuer talk-de: Eine Liste von offiziellen CC-Statements, die aussagen, dass sie die ODbL nicht gut finden, dass Daten CC0 bzw. PD sein sollten, sowie ein Verweis auf eine Wikiseite, die Steve selbst im Februar gefuellt hatte mit den Worten ... allerdings ist es die Position con Creative Commons, dass alle Kartendaten public domain sein sollten) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hello from England
On 8 Jul 2009, at 12:38, Frederik Ramm wrote: Hi, SteveC wrote: I'm glad we have settled that Creative Commons officially suggested to us that we use CC0 for OpenStreetMap, rather than this just being a personal opinion of an individual as you seemed to suggest earlier. Um, no, I don't think I've seen it. do you have a link? http://www.sciencecommons.org/resources/readingroom/comments-on-odbl oh that, you confused me because you keep saying CC but it's actually SC, which has a very different mandate which you're trying to turn around to what CC does. I too agree that science data that I pay my taxes for universities to produce should be in the public domain. Not sure how that applies to us. I hope that suffices to refresh any lost memory ;-) I don't need to remember emails I wrote 18 months ago when I have an army of people out there trying to use them as proof of this or that. Best Steve ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten: Konsensvorschlag Anlagenmapping
Am Mittwoch, 8. Juli 2009DE 12:33:00DE schrieb Markus: Hallo Tobias, Ist folgende Vorgehensweise konsensfähig? Gelände: amenity=kindergarten name=* [weitere Geländeattribute] Gebäude: building=yes (oder sonst ein Wert) [weitere Gebäudeattribute] Ausführlich beschrieben: * Das Gelände der amenity (z.B. amenity=kindergarten) wird als Fläche erfasst. Sämtliche Tags, die für die ganze Anlage gelten (etwa der Name) werden nur einmal angegeben, und zwar am mit amenity=* getaggten Way. * Die Gebäude der Anlage werden als building=yes (oder auf Wunsch mit spezifischerem Wert) gekennzeichnet. Sie erhalten _nicht_ nochmal das amenity=*, und Tags beziehen sich nur aufs jeweilige Gebäude (falls die Gebäude z.B. eigene Namen etc. haben). Analog für sonstige Bestandteile der Anlage (Sandkästen, Rutschen, ...). * site-Relationen können optional verwendet werden (etwa für komplizierte Anlagen). Ja, das wäre eine klare Unterscheidung von Gelände und Häusern. Diese müsste sich dann aber unbedingt auch in den Vorlagen wiederfinden. (Dein Vorschlag steht aber im Widerspruch zur jetzigen Gepflogenheit, die Häuser zu unterscheiden und die Flächen nicht zu beschreiben, Du kehrst das sozusagen um) Wir beschreiben die Flächen nicht? Das wäre mir neu. Was Deinem Vorschlag noch fehlt ist noch eine ebenso klare Bezeichnung der Häuser. Wenn beispielsweise nur das Kindergartenhaus eingetragen wird, dann müsste das Haus als Kindergarten von normalen Häusern unterscheidbar sein. Nimm als Workaround name=Kindergarten soundso. Meist ist das Wort Kindergarten eh Teil des Namens der Einrichtung, dann erledigt sich das von selbst. Darstellung auf der Karte ist Sache des Renderes. Und wenn auf dem Gelände mehrere Häuser stehen, dann muss unterscheidbar sein, welches der Kindergarten ist (und welches beispielsweise nur das Wohnhaus des Hausmeisters oder so). Man könnte es so versuchen: Gelände: site=Kindergarten (oder ein anderer aussagekräftiger Schlüssel für Gelände) Haus: building=Kindergarten Man benutze die site -Relation. (noch unvollständig) Beispiel: http://www.informationfreeway.org/?lat=53.600078110689694lon=10.043466938317026zoom=17layers=0F0B0F Bei den Häusern kann man ja bereits Werte für den Schlüssel building angeben. Aber da ist nicht klar, ob damit Nutzungsarten oder architektonische Formen beschrieben werden sollen? Und manchmal wird dem Haus auch noch ein amenity zugeordnet. Für die beiden Klassen Nutzung und Form sollte man m.E. zwei verschiedene Attribute verwenden. (Beispielsweise gibt es Häuser die wie eine Kirche aussehen, die als religiöser Treffpunkt genutzt werden, und andere (die ebenfalls wie eine Kirche aussehen und auch mal als solche genutzt wurden), die als Museum, als Disco, als Geschäftshaus oder so genutzt werden. In diesen Fällen kannst Du mit dem entsprechenden old_name-Tag zumindest den Namen der ehemaligen Kirche ausweisen. Übrigens gibt es auch ganz normale Wohngebäude, die als Kirchen genutzt werden. Kindergarten ist hier exemplarisch gemeint, soll aber übertragbar sein auf alle Geländenutzungen mit Häusern drauf (Schule, Krankenhaus, Bahnhof, Schwimmbad, Sportplatz, etc) -- Mit freundlichen Grüßen René Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Format für Datenimport?
Am Mi, 8.07.2009, 10:16 schrieb Sven Geggus: AFAIK gibts da leider keinen, aber für sowas einfaches wie Stadtteilgrenzen darfst Du dich gerne per Mail an mich wenden, das kriegen wir schon rein. Bitte bitte achte aber die Parameter. Wenn wir schon genaue Daten bekommen, dann sehe ich keinen Grund sie nicht auch korrekt abzuspeichern. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Format für Datenimport?
Hallo, Tobias Wendorff wrote: Bitte bitte achte aber die Parameter. Wenn wir schon genaue Daten bekommen, dann sehe ich keinen Grund sie nicht auch korrekt abzuspeichern. Genau, denn was aus staedtischen GIS-Systemen exportiert wird, muss ja zwangslaeufig besser, genauer und praeziser sein als alles, was wir sonst haben ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WG: www.freietonne.de - Upload unsererSeekartendatennach OSM gestartet
Andreas Labres schrieb: Jan Jesse wrote: Das muß ich glauben, die Angaben in den Verzeichnissen sind ja so seltsam. Aber verstehen verstehe ich das nicht. Heißt vom Schiff aus gepeilt immer, daß die Küste im Süden liegt? Oder geht es tatsächlich um das berühmte Banditen in 09.00 Uhr, was technisch dann kaum zu bewältigen wäre? Bitte denke mal kurz nach: - wenn ich ein Leuchtfeuer in 0° (im N) anpeile, so sehe ich den Strahl, der nach S zeigt - wenn ich ein Leuchtfeuer in 90° (im O) anpeile, so sehe ich den Strahl, der nach W zeigt - wenn ich ein Leuchtfeuer in 180° (im S) anpeile, so sehe ich den Strahl, der nach N zeigt - wenn ich ein Leuchtfeuer in 270° (im W) anpeile, so sehe ich den Strahl, der nach O zeigt und dazwischen analog. Oder anders gesagt: wenn wir aufeinander zufahren, wie groß ist dann die Richtungsdifferenz unserer Kurse? ;) Servus, Andreas Ich bin nautischer Laie, aber diese Erklärung ist einleuchtend. Ich bin somit für die Erfassung nach Süden=0°, weil sie unterstützt sowohl die Sichtweise der Leute die es vor Ort (sprich vom Wasser aus) erfassen, als auch die Leute, die nur Datentabellen in die Datenbank übertragen. Nur die Renderer müssen beim Ich bin der Leuchtturm-spielen halt die 180° draufrechnen, dass finde ich für einen Renderer der sich mit nautischer Materie beschäftigt akzeptabel. Grüße Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten
René Falk schrieb: Am Mittwoch, 8. Juli 2009DE 09:27:23DE schrieb Markus: Hallo Wolfgang, dieser Thread ist ja nun schon ziemlich lang. Aber irgendwie fehlt mir der zusammengefasste Konsens. Was also ist best practice für: - Kindergarten-Gebäude - Kindergarten-Gelände Konsens? Kicher. Der Link zeigt dir ein Gebiet mit 4 verschiedenen Schulen, die unterschiedlich gemappt worden sind. Schau es dir an, und dann mach es so, wie Du es für richtig hälst. http://www.informationfreeway.org/?lat=53.59928226809326lon=10.047908675483637zoom=16layers=BF000F wieso sind die Schlen unterschiedlich erfasst? Sieht für mich so aus, als sei die amenity=kindergarten/school immer das Gelände und bei der 2. von Links hat einer schon Wege und Gebäude auf diesem Gelande erfasst. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ist da was kaputt?
Dirk Stöcker (openstreet...@dstoecker.de)schrieb: From my point of view it was so obvious going wrong that I never would have thought somebody would really press upload when such shit happens. So this reaction was fast from my point of view. Just for the record: With the broken version dragging a node resulted in visibly nothing, so the bug wasn't that straightforward obvious. Only after an undo the node went visibly far away. After that undo a redo and further undo resulted in nothing. regards nadar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten: Konsensvorschlag Anlagenmapping
Markus schrieb: Hallo Tobias, Ist folgende Vorgehensweise konsensfähig? Gelände: amenity=kindergarten name=* [weitere Geländeattribute] Gebäude: building=yes (oder sonst ein Wert) [weitere Gebäudeattribute] Ausführlich beschrieben: * Das Gelände der amenity (z.B. amenity=kindergarten) wird als Fläche erfasst. Sämtliche Tags, die für die ganze Anlage gelten (etwa der Name) werden nur einmal angegeben, und zwar am mit amenity=* getaggten Way. * Die Gebäude der Anlage werden als building=yes (oder auf Wunsch mit spezifischerem Wert) gekennzeichnet. Sie erhalten _nicht_ nochmal das amenity=*, und Tags beziehen sich nur aufs jeweilige Gebäude (falls die Gebäude z.B. eigene Namen etc. haben). Analog für sonstige Bestandteile der Anlage (Sandkästen, Rutschen, ...). * site-Relationen können optional verwendet werden (etwa für komplizierte Anlagen). Ja, das wäre eine klare Unterscheidung von Gelände und Häusern. Diese müsste sich dann aber unbedingt auch in den Vorlagen wiederfinden. (Dein Vorschlag steht aber im Widerspruch zur jetzigen Gepflogenheit, die Häuser zu unterscheiden und die Flächen nicht zu beschreiben, Du kehrst das sozusagen um) Was Deinem Vorschlag noch fehlt ist noch eine ebenso klare Bezeichnung der Häuser. Wenn beispielsweise nur das Kindergartenhaus eingetragen wird, dann müsste das Haus als Kindergarten von normalen Häusern unterscheidbar sein. Und wenn auf dem Gelände mehrere Häuser stehen, dann muss unterscheidbar sein, welches der Kindergarten ist (und welches beispielsweise nur das Wohnhaus des Hausmeisters oder so). Man könnte es so versuchen: Gelände: site=Kindergarten (oder ein anderer aussagekräftiger Schlüssel für Gelände) Haus: building=Kindergarten Bei den Häusern kann man ja bereits Werte für den Schlüssel building angeben. Aber da ist nicht klar, ob damit Nutzungsarten oder architektonische Formen beschrieben werden sollen? Und manchmal wird dem Haus auch noch ein amenity zugeordnet. Für die beiden Klassen Nutzung und Form sollte man m.E. zwei verschiedene Attribute verwenden. (Beispielsweise gibt es Häuser die wie eine Kirche aussehen, die als religiöser Treffpunkt genutzt werden, und andere (die ebenfalls wie eine Kirche aussehen und auch mal als solche genutzt wurden), die als Museum, als Disco, als Geschäftshaus oder so genutzt werden. Kindergarten ist hier exemplarisch gemeint, soll aber übertragbar sein auf alle Geländenutzungen mit Häusern drauf (Schule, Krankenhaus, Bahnhof, Schwimmbad, Sportplatz, etc) Gruss, Markus wenn sich doch schon einer die Mühe macht das Gelände als area zu erfassen, warum taggt er dann nicht gleich ein amenity=* dran? Wenn man sich keine Mühe bei der Fläche machen will/kann, dann kommt in das Gebäude was man als area erfasst hat einfach ein Node mit amenity=* rein und fertig ;) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten
wieso sind die Schlen unterschiedlich erfasst? Sieht für mich so aus, als sei die amenity=kindergarten/school immer das Gelände und bei der 2. von Links hat einer schon Wege und Gebäude auf diesem Gelande erfasst. Warum hat man dann beides in den JOSM Presets unter Gebäude gesteckt? Müsste dann ja unter Landnutzung stehen. So mache ich das auch schon immer. building=yes und amenity=kindergarten/school plus weiteres wie Adresse usw. Das Gelände drumherum kann wiederum ganz unterschiedlich sein. Unsere Klosterschule und Internat liegt dann wie in der Realität in einem Park. Ebenso die Regelschule welche einen Öko Natrpark mit WEA, Bioteich etc hat. Dazu kommt noch Sportplätze usw. Da würde ein nacktes amenity als Fläche ohnehin wenig bringen, zuviel Informationsverlusst die man mit anderen Tags beschreiben kann. Zum Schluss wird das Grundstück eingezäunt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Format für Datenimport?
Am Mi, 8.07.2009, 14:32 schrieb Frederik Ramm: Genau, denn was aus staedtischen GIS-Systemen exportiert wird, muss ja zwangslaeufig besser, genauer und praeziser sein als alles, was wir sonst haben ;-) Du kannst ja nicht wissen, wie genau oder ungenau sie sind. Eine korrekter Import ist daher ein sinnvoller Weg. Beim Infas-Import sieht man sehr gut, was einmal die ursprüngliche Quelle war, aber nun ein Drift drin ist, der einfach unnötig war. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Format für Datenimport?
Hallo, Tobias Wendorff wrote: Beim Infas-Import sieht man sehr gut, was einmal die ursprüngliche Quelle war, aber nun ein Drift drin ist, der einfach unnötig war. Moment mal, soll das heissen, dass Jochen und ich beim Infas-Import irgendetwas falsch gemacht haben? Davon hoere ich jetzt gerade zum ersten Mal. Was fuer einen Drift meinst Du, und kannst Du mich mal auf eine Stelle hinweisen, an der man sehr gut sieht, was einmal die urspruengliche Quelle war? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten: Konsensvorschlag Anlagenmapping
Markus schrieb: Was Deinem Vorschlag noch fehlt ist noch eine ebenso klare Bezeichnung der Häuser. [...] Und wenn auf dem Gelände mehrere Häuser stehen, dann muss unterscheidbar sein, welches der Kindergarten ist (und welches beispielsweise nur das Wohnhaus des Hausmeisters oder so). Es gibt m.E. kein Gebäude, das der Kindergarten ist. Es gibt Räume, wo die Kinder spielen, wo sie essen, Waschräume, genauso gibt es Abstellräume, Räume für das Personal etc. Diese Einrichtungen können beliebig auf ein oder mehrere Häuser verteilt sein. Keine der Einrichtungen ist aber der Kindergarten, sondern jede ist nur Teil des Kindergartens. Deshalb ist es logisch, nur die gesamte Anlage mit dem amenity=kindergarten (oder einem vergleichbaren Tag) zu versehen. Du kannst natürlich ein Schema erfinden, mit dem man Einrichtungen in Kindergärten beschreibt (so wie wir es z.B. für die einzelnen Elemente eines Golfkurses als Proposal haben) und die Attribute dann an die jeweiligen Häuser hängen. Das ergänzt sich problemlos mit der Grundidee, die Tags, die die Gesamteinrichtung beschreiben - dazu gehört auch die amenity - nicht an jedes einzelne Haus zu taggen. Man könnte es so versuchen: Gelände: site=Kindergarten (oder ein anderer aussagekräftiger Schlüssel für Gelände) Haus: building=Kindergarten Dann hast du die Nutzung doppelt drin. Ein Haus wird doch dadurch zu einem als (Teil eines) Kindergarten genutzten Haus, dass es entweder selbst ein amenity=kindergarten trägt (bei Ein-Haus-Kindergärten) oder zu einem mit amenity=kindergarten getaggten Gelände gehört - letzteres kann durch Mitgliedschaft in einer site-Relation ausgedrückt werden (perfekt auswertbare Lösung) oder dadurch, dass es eben auf der so gekennzeichneten Fläche steht (einfacher einzutragende Lösung). Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten: Konsensvorschlag Anlagenmapping
René Falk schrieb: * site-Relationen können optional verwendet werden (etwa für komplizierte Anlagen). Auch bei weniger komplizierten Anlagen macht eine Kennzeichnung das gehört zusammen Sinn. Auf einer Karte sieht das relativ selbstverständlich aus und ist oft nicht nötig, für die Datenbank ist das aber eine durchaus nützliche Info. Finde ich auch, aber da die Relations doch (noch) etwas umständlich anzulegen sind, will ich das nicht für jede Einrichtung fordern. Für viele - nicht alle - Anwendungszwecke reicht es ohne Relation. Early Adopters können natürlich gleich die perfekte Ausstattung anlegen. :) Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten: Konsensvorschlag Anlagenmapping
Am Mittwoch, 8. Juli 2009DE 15:44:54DE schrieb Tobias Knerr: René Falk schrieb: * site-Relationen können optional verwendet werden (etwa für komplizierte Anlagen). Auch bei weniger komplizierten Anlagen macht eine Kennzeichnung das gehört zusammen Sinn. Auf einer Karte sieht das relativ selbstverständlich aus und ist oft nicht nötig, für die Datenbank ist das aber eine durchaus nützliche Info. Finde ich auch, aber da die Relations doch (noch) etwas umständlich anzulegen sind, will ich das nicht für jede Einrichtung fordern. Für viele - nicht alle - Anwendungszwecke reicht es ohne Relation. Early Adopters können natürlich gleich die perfekte Ausstattung anlegen. :) Nun, ich finde es weniger kompliziert, als die Bedienung meines Garmin, zumal site-Relationen zu den wirklich simpel gestrickten Relationen gehören. Die site-Relation eröffnet einem Möglichkeiten, die man ohne Relation nicht hätte. Vieles lässt sich damit einfacher abbilden. Aber letztendlich gibt es idealer Weise immer mehrere Lösungen. -- Mit freundlichen Grüßen René Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Format für Datenimport?
Am Mi, 8.07.2009, 15:35 schrieb Frederik Ramm: Moment mal, soll das heissen, dass Jochen und ich beim Infas-Import irgendetwas falsch gemacht haben? Nein, das habe ich nicht geschrieben und muss nicht auf Eurer Seite passiert sein. Nur durch das ganze uneinheitliche Gewandle, pflanzen sich die Fehler halt fort und aus passende Daten können unpassende und aus unpassenden ... Was fuer einen Drift meinst Du, und kannst Du mich mal auf eine Stelle hinweisen, an der man sehr gut sieht, was einmal die urspruengliche Quelle war? Ja, kann ich morgen am Desktop machen, das ist nichts für den Talk. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten
Am Mittwoch, 8. Juli 2009DE 14:44:51DE schrieb Mario Salvini: wieso sind die Schlen unterschiedlich erfasst? Sieht für mich so aus, als sei die amenity=kindergarten/school immer das Gelände und bei der 2. von Links hat einer schon Wege und Gebäude auf diesem Gelande erfasst. Unterschiede bestehen in der Anzahl der Details und wie sie in die Datenbank eingepflegt wurden. Gelände mit und ohne Gebäude, Relationen ja/nein, wo sind welche weiteren Infos (Adresse, Eingänge, Namen, etc.) zugefügt. Sieht man besser in JOSM. -- Mit freundlichen Grüßen René Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Format für Datenimport?
Frederik Ramm frede...@remote.org wrote: Genau, denn was aus staedtischen GIS-Systemen exportiert wird, muss ja zwangslaeufig besser, genauer und praeziser sein als alles, was wir sonst haben ;-) Solange man bei GK2/3/4 bleibt stimmt das vermutlich sogar. Beim umprojizieren passieren jedoch automatisch Fehler. Angeblich gibt es sehr genaue Umrechnungsprogramme für GK2/3/4 nach epsg:4326. Allerdings habe ich noch keinen offiziellen Eintrag für proj4 und epsg:31466,epsg:31467 und epsg:31468 gesehen. Das könnte natürlich daran liegen, dass viele offizielle Stellen lieber mit ESRI kuscheln und daher das freie Zeug vernachlässigen. Gruss Sven -- Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten
René Falk schrieb: Am Mittwoch, 8. Juli 2009DE 14:44:51DE schrieb Mario Salvini: wieso sind die Schlen unterschiedlich erfasst? Sieht für mich so aus, als sei die amenity=kindergarten/school immer das Gelände und bei der 2. von Links hat einer schon Wege und Gebäude auf diesem Gelande erfasst. Unterschiede bestehen in der Anzahl der Details und wie sie in die Datenbank eingepflegt wurden. Gelände mit und ohne Gebäude, Relationen ja/nein, wo sind welche weiteren Infos (Adresse, Eingänge, Namen, etc.) zugefügt. Sieht man besser in JOSM. ja, dass schon, aber immer ist ja das Gelände mit amenity= getaggt und nicht nur ein einzelnes Gebäude, dass meinte ich. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Format für Datenimport?
Am Mi, 8.07.2009, 16:25 schrieb Sven Geggus: Allerdings habe ich noch keinen offiziellen Eintrag für proj4 und epsg:31466,epsg:31467 und epsg:31468 gesehen. Das könnte natürlich daran liegen, dass viele offizielle Stellen lieber mit ESRI kuscheln und daher das freie Zeug vernachlässigen. Das stimmt so nicht. GK funktioniert an verschiedenen Stellen des Globus, daher wäre es gefährlich, feste Punkte in proj4 anzugeben. Das BKG empfiehlt ausdrücklich die Verwendung von proj4, wie man auch in den Mailinglisten sehen kann. BeTa:2008 funktioniert problemlos in proj4 - wenn man das nicht verwenden will, kann man die Transformationsparameter auch selbst berechnen, genug Mapper mit Punkten haben wir ja :-) Das LVermA NRW verwendet sogar Code aus proj4 in ihren eigenem Transformationsprogramm. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten: Konsensvorschlag Anlagenmapping
Es gibt m.E. kein Gebäude, das der Kindergarten ist. Es gibt Räume, wo die Kinder spielen, wo sie essen, Waschräume, genauso gibt es Abstellräume, Räume für das Personal etc. Diese Einrichtungen können beliebig auf ein oder mehrere Häuser verteilt sein. Keine der Einrichtungen ist aber der Kindergarten, sondern jede ist nur Teil des Kindergartens. Deshalb ist es logisch, nur die gesamte Anlage mit dem amenity=kindergarten (oder einem vergleichbaren Tag) zu versehen. Das ist so nicht ganz richtig. Es gibt durchaus auch die Fälle wo ein Gebäude der Kindergarten ist und sich ein Gelände mit anderen Gebäuden teilt. In WSF gibts z.B. ein Parkgelände in kommunalem Besitz. Darauf befindet sich zum einen das Kindergartengebäude und nebenan das Gebäude eines Jugendclubs, beide teilen sich das ganze Gelände. Das reine Kindergartengelände gibts nicht. Bei unserer Klosterschule gehört das Gelände mit Park einer Stiftung. Dieses Gelände teilen sich das eigentliche Gymnasium, das Internat, der Ruderclub und der Tennisverein, welche beide mal durch die Schule entstanden aber heute eigenständig sind aber das gleiche Gelände nutzen. Dazu gehören eigentlich noch zwei Beamtenhäuser, die früher die Dienstwohnungen der Lehrer darstellten. Auch hier gibts kein reines Schulgelände. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
