[talk-ph] OSM, planet.pm (perl module installing), planetosm-excerpt-area.pl in Mac OS X
Hi Maning, I need help on figuring how to these things, i.e. installing a PERL module Planet.pm and running planetosm-excerpt-area.pl in Mac OS X. I know that you using a Mac and working a lot of extracting data from OSM file. I am trying to extract State of Victoria from Australia.osm file for iPhone/iPad Openlayers + Spatialite app that I am working. I found this info (below). http://users.tpg.com.au/users/stevez/OSM/credits.html planetosm-excerpt-area.pl -bbox -39.4,140.2,-33.7,151.5 australia.osm VIC.osm However, it is need Planet.pm. How do you download the planet.pm and install this Perl module in Mac OS X? Thanks in advance. Noli ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] OSM, planet.pm (perl module installing), planetosm-excerpt-area.pl in Mac OS X
Noli, I use an Ubuntu machine for most of my osm data munging. And I also don't use Perl much. That said, most perl modules can be installed with CPAN or directly copy them to your /usr/lib/perl/5.8.8/ . On a mac, you probably have darwin port so it should be /opt/local/lib/perl5/5.8.8/darwin-2level/ Some threads I found: http://web.archiveorange.com/archive/v/tomQkFckXIEapRXDWu0z http://comments.gmane.org/gmane.comp.gis.openstreetmap.devel/12112 Hope that was helpful. Maybe Eugene can chime in. :) On Fri, Jul 1, 2011 at 9:22 AM, Noli Sicad nsi...@gmail.com wrote: Hi Maning, I need help on figuring how to these things, i.e. installing a PERL module Planet.pm and running planetosm-excerpt-area.pl in Mac OS X. I know that you using a Mac and working a lot of extracting data from OSM file. I am trying to extract State of Victoria from Australia.osm file for iPhone/iPad Openlayers + Spatialite app that I am working. I found this info (below). http://users.tpg.com.au/users/stevez/OSM/credits.html planetosm-excerpt-area.pl -bbox -39.4,140.2,-33.7,151.5 australia.osm VIC.osm However, it is need Planet.pm. How do you download the planet.pm and install this Perl module in Mac OS X? Thanks in advance. Noli ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- 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
Re: [talk-ph] OSM, planet.pm (perl module installing), planetosm-excerpt-area.pl in Mac OS X
Maning, For this process, just use osmosis: http://wiki.openstreetmap.org/wiki/Osmosis OK. This is easier option. You can even use a polygon instead of a simple -bbox: http://wiki.openstreetmap.org/wiki/Polygon Now, how I figure out the right polygon for Victoria for this bbox? -39.4,140.2, -33.7,151.5 from planetosm-excerpt-area.pl -bbox -39.4,140.2,-33.7,151.5 australia.osm VIC.osm Given this example for Australia http://wiki.openstreetmap.org/wiki/Polygon#Getting_polygon_files ~ australia_v 1 0.1446763E+03-0.3825659E+02 0.1446693E+03-0.3826255E+02 0.1446627E+03-0.3825661E+02 0.1446763E+03-0.3824465E+02 0.1446813E+03-0.3824343E+02 0.1446824E+03-0.3824484E+02 0.1446826E+03-0.3825356E+02 0.1446876E+03-0.3825210E+02 0.1446919E+03-0.3824719E+02 0.1447006E+03-0.3824723E+02 0.1447042E+03-0.3825078E+02 0.1446758E+03-0.3826229E+02 0.1446693E+03-0.3826255E+02 END !2 0.1422483E+03-0.3839481E+02 0.1422436E+03-0.3839315E+02 0.1422496E+03-0.3839070E+02 0.1422543E+03-0.3839025E+02 0.1422574E+03-0.3839155E+02 0.1422467E+03-0.3840065E+02 0.1422433E+03-0.3840048E+02 0.1422420E+03-0.3839857E+02 0.1422436E+03-0.3839315E+02 END END ~ What would be the right polygon for Victoria? Noli ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] OSM, planet.pm (perl module installing), planetosm-excerpt-area.pl in Mac OS X
Brilliant! Needs to one polygon for Victoria, or a whole state of Victoria with multiple polygons will do? Installing the plugin now. I think I can work this out now :-). Thanks a lot Maning. Noli On 7/1/11, maning sambale emmanuel.samb...@gmail.com wrote: An easier way to create a polygon file for osmosis is through QGIS' OSM_POLY Export plugin. Simply load the shapefile of Victoria and run the plugin. Given this example for Australia http://wiki.openstreetmap.org/wiki/Polygon#Getting_polygon_files ~ australia_v 1 0.1446763E+03 -0.3825659E+02 0.1446693E+03 -0.3826255E+02 0.1446627E+03 -0.3825661E+02 0.1446763E+03 -0.3824465E+02 0.1446813E+03 -0.3824343E+02 0.1446824E+03 -0.3824484E+02 0.1446826E+03 -0.3825356E+02 0.1446876E+03 -0.3825210E+02 0.1446919E+03 -0.3824719E+02 0.1447006E+03 -0.3824723E+02 0.1447042E+03 -0.3825078E+02 0.1446758E+03 -0.3826229E+02 0.1446693E+03 -0.3826255E+02 END !2 0.1422483E+03 -0.3839481E+02 0.1422436E+03 -0.3839315E+02 0.1422496E+03 -0.3839070E+02 0.1422543E+03 -0.3839025E+02 0.1422574E+03 -0.3839155E+02 0.1422467E+03 -0.3840065E+02 0.1422433E+03 -0.3840048E+02 0.1422420E+03 -0.3839857E+02 0.1422436E+03 -0.3839315E+02 END END ~ What would be the right polygon for Victoria? Noli -- 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
[OSM-talk-be] Weide
Ik ben nu al een paar dagen bezig met Kemzeke / Stekene in kaart te brengen en heb nu een vraagje. Wat is de beste manier om een weide aan te duiden waar dieren kunnen grazen? Ik gebruikte eerste landuse=meadow, maar dat blijkt niet juist genoeg te zijn. Is het landuse=pasture? Maar het is dan jammer dat je dat niet ziet ingekleurd op www.openstreetmap.org. Franky ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Weide
Ik gebruik ook meadow, waarom zou dat niet goed genoeg zijn? Polyglot Op 30 juni 2011 22:21 schreef Franky Braem franky.br...@gmail.com het volgende: Ik ben nu al een paar dagen bezig met Kemzeke / Stekene in kaart te brengen en heb nu een vraagje. Wat is de beste manier om een weide aan te duiden waar dieren kunnen grazen? Ik gebruikte eerste landuse=meadow, maar dat blijkt niet juist genoeg te zijn. Is het landuse=pasture? Maar het is dan jammer dat je dat niet ziet ingekleurd op www.openstreetmap.org. Franky __**_ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-behttp://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Weide
Meadow is de algemene term voor grasland. Dit kan zowel een weide, hooiland, als een natuurlijk, wild stuk grasgebied zijn. Pasture is specifiek een weide, dus een omheind grasveld waar dieren op grazen. Op veel plaatsen is ook de weide en het hooiland mee ingemapt met de velden onder het algemene farmland. (is eigenlijk bijna alles wat niet bebouwd is, bebost is of onder water staat :-) ) Het is natuurlijk ook zo dat de indeling van veld, hooiland of weide, naargelang het uitkomt voor de boer, wel eens durft te veranderen en dan is farmland (landbouwgebied) altijd correct. mvg Gerard Jo wrote: Ik gebruik ook meadow, waarom zou dat niet goed genoeg zijn? Polyglot Op 30 juni 2011 22:21 schreef Franky Braem franky.br...@gmail.com mailto:franky.br...@gmail.com het volgende: Ik ben nu al een paar dagen bezig met Kemzeke / Stekene in kaart te brengen en heb nu een vraagje. Wat is de beste manier om een weide aan te duiden waar dieren kunnen grazen? Ik gebruikte eerste landuse=meadow, maar dat blijkt niet juist genoeg te zijn. Is het landuse=pasture? Maar het is dan jammer dat je dat niet ziet ingekleurd op www.openstreetmap.org http://www.openstreetmap.org. Franky ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
On 29/06/11 19:56, Frederik Ramm wrote: Hi, James Livingston wrote: If I use software that builds an in-memory data structure which you believe to be a database in order to make a produced work, how would you suggest that I fulfil my obligation to make such derived database available on request? I have absolutely no idea. It's one of the many things I don't know about how the produced works part of the ODbL will work in practice. Thinking about this more, the problem would only occur if you have a black-box software wich might or might not create a database internally, and the thing that falls out of the black box is a produced work that you will publicly use. Because then, and only then, will you have to share the derived database upon which the produced work is based. If, on the other hand, out of the black box comes a derived database, then you can simply share *that* database and nobody cares what happened in the black box, because you only have to share the last in a chain of derived databases that leads to a produced work, right? I think that's right - that's the only one which you're publicly using. Really I'm at a loss to see the point of the share-alike clause (4.4). I can't think of a use-case for OSM where processing the database doesn't reduce the amount of information. When you want to render geodata, it typically involves discarding most of the metadata, getting rid of points from ways, and transforming lat/long to cartesian co-ordinates in a projection. The resulting database is always going to have a lot less information than the original, and be difficult or impossible to translate back into OSM (without the OSM IDs or original lat/long). So what's the point of the huge burden of being required to make it available on request? Who benefits? Jonathan. -- Jonathan Harley: Managing Director : SpiffyMap Ltd Email: m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com Post: The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
Jonathan Harley wrote: Really I'm at a loss to see the point of the share-alike clause (4.4). I can't think of a use-case for OSM where processing the database doesn't reduce the amount of information. The canonical case, often cited by those who say OSM needs a share-alike licence, is to prevent commercial map providers taking the data we have and they don't (e.g. footpaths), adding it to the data they have but we don't (e.g. complete road network), and not giving us anything back. IRMFI, not because I believe it myself. :) cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Exception-in-Open-Data-License-Community-Guidelines-for-temporary-file-tp6504201p6532530.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open DataLicense/Community Guidelines for temporary file
- Original Message - From: Richard Fairhurst rich...@systemed.net To: legal-talk@openstreetmap.org Sent: Thursday, June 30, 2011 10:53 AM Subject: Re: [OSM-legal-talk] Exception in Open DataLicense/Community Guidelines for temporary file Jonathan Harley wrote: Really I'm at a loss to see the point of the share-alike clause (4.4). I can't think of a use-case for OSM where processing the database doesn't reduce the amount of information. The canonical case, often cited by those who say OSM needs a share-alike licence, is to prevent commercial map providers taking the data we have and they don't (e.g. footpaths), adding it to the data they have but we don't (e.g. complete road network), and not giving us anything back. IRMFI, not because I believe it myself. :) cheers Richard That would certainly seem a very good thing. In lots of peoples opinion where you *add* data, then it is good if that data can be shared back to the community. However where you *don't* add data, but merely process the OSM data, either by extracting some sub-set of it, or simply by transforming it from one form of database to another, then what is the point of requiring compliance with ODbL clause 4.6. Regards David ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] OSM-Garmin relationship?
Hi, Does someone know if there is some sort of relationship between OSM and Garmin? The reason I'm asking is that 1) as you may know OSM is the only good enough map (data) for Haiti that e.g. makes routing possible -- now or in the foreseeable future (and most probably beyond). 2) Without GPS+good map finding one's way around in Haiti is difficult even for people who are pretty good in navigation (says me who did good chunk of my military service in Navy/navigation) 3) My understanding is that Garmin is the only stand-along navigator that works (at least somewhat well) with OSM data (which my testing in the last months has proven) 4) Someone who was/is interested in bringing Garmin (or any other functioning navigators) to Haitian market contacted Garmin and got a response from Someone there who said that Garmin is not supporting OSM and does not recommend it due to warranty reasons (what ever on earth that would be!). They instead referred the guy asking about Garmin's interest in Haiti to Navteq. ... Of which I can only think that the person at Garmin didn't know what s/he was talking about. Or then, Garmin Really doesn't like OSM + don't understand and/or care about Haiti / other similar areas. Or I don't understand something. Any ideas / alternatives? The way I see this is that getting devices that use OSM data to peoples'/organizations' use in Haiti would not only make their lives/operations easier/ more efficient and through that help boost the development of Haiti but also increase the organic need and hence possibilities for resources to improving the Haiti OSM data further. Cheers, -Jaakko -- http://osm.org/user/jaakkoh ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM-Garmin relationship?
Jaakko Helleranta.com jaa...@helleranta.com writes: Does someone know if there is some sort of relationship between OSM and Garmin? The reason I'm asking is that 1) as you may know OSM is the only good enough map (data) for Haiti that e.g. makes routing possible -- now or in the foreseeable future (and most probably beyond). 2) Without GPS+good map finding one's way around in Haiti is difficult even for people who are pretty good in navigation (says me who did good chunk of my military service in Navy/navigation) 3) My understanding is that Garmin is the only stand-along navigator that works (at least somewhat well) with OSM data (which my testing in the last months has proven) 4) Someone who was/is interested in bringing Garmin (or any other functioning navigators) to Haitian market contacted Garmin and got a response from Someone there who said that Garmin is not supporting OSM and does not recommend it due to warranty reasons (what ever on earth that would be!). They instead referred the guy asking about Garmin's interest in Haiti to Navteq. ... Of which I can only think that the person at Garmin didn't know what s/he was talking about. Or then, Garmin Really doesn't like OSM + don't understand and/or care about Haiti / other similar areas. Or I don't understand something. Any ideas / alternatives? The way I see this is that getting devices that use OSM data to peoples'/organizations' use in Haiti would not only make their lives/operations easier/ more efficient and through that help boost the development of Haiti but also increase the organic need and hence possibilities for resources to improving the Haiti OSM data further. As far as I can tell, the mkgmap effort and other efforts to build garmin-format maps have not been officially aided by Garmin, and Garmin does not seem to publish technical specs. I would guess that the 'warranty' comment is just the typical corporate reaction to questions of liability, perhaps combined with a lack of understanding of open data. If the goal is to get working GPS navigation receivers to people Haiti, rather than to form a business to do that, then I would suggest finding contacts in the Haitian government/UN/etc. to request that Garmin openly publish specifications for the file formats. It may be easier to get them to do that than to support OSM, because of differing perceptions of liability exposure. But with real specs (without strings attached), I'm sure the mkgmap crowd would make even more rapid progress in producing garmin-format maps from OSM data. pgpfjsRy915Ut.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM-Garmin relationship?
Thanks Greg as well as the few others that have replied to me privately, Just to clarify (so others don't need to reply on that): I do know of the OSM-Garmin coversion tools as well as the ready-made downloads that are available from various places. My personal BIG thanks in this regard goes to Geofabrik for offering the Garmin files (which have navigated me from PaP to the Eastern tip of Hispanola and more locally) as well as the other Haiti downloads! An interesting idea to try to work through Haitian government / UN / etc to get Garmin's specs albeit I don't really see why Garmin would respond positively to such requests. What would be in it for them? Regarding getting working GPS-navigation devices to use in Haiti vs. trying to create a business out of it (whether that be for private profit or for some social good as I'm hoping this could turn out); I don't see that there must be at odds with each other necessarily. In my experience providing a service in Haiti is difficult enough by itself that if/when someone is able to do it that business is protected by the mere fact that you have are able to deliver that service. Anyways. Thanks for the responses. It seems like Greg's reply condenses the situation. Cheers, -Jaakko -- jaa...@helleranta.com * Skype: jhelleranta * Mobile: +509-37-269154 * http://go.hel.cc/MyProfile ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM-Garmin relationship?
Greg Troxel g...@ir.bbn.com writes: I would guess that the 'warranty' comment is just the typical corporate reaction to questions of liability, perhaps combined with a lack of understanding of open data. Especially when you consider that when you turn on your device you get a warning saying All information is presented for reference only. You assume total responsibility and risk associated with using this device. (at least mine does that.) So there is no warranty for the data anyway. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM-Garmin relationship?
On Thu, Jun 30, 2011 at 1:37 PM, Jaakko Helleranta.com jaa...@helleranta.com wrote: Hi, Does someone know if there is some sort of relationship between OSM and Garmin? I'm not aware of any relationship between OSMF and Garmin. I've had two people tell me that their new Garmins arrived with OSM data on the device (with license details on boot up). I don't know where they purchased the Garmins. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] wandelroute
Gert heeft volkome gelijk. In vergelijking met Potlatch is Relaties beheren in JOSM een feest. Toch blijven relaties een lastig onderwerp en een reden voor sommige mappers om zich daar niet mee in te laten. Theo, maar voor wandelaars als jij heb ik misschien een goed idee. Ik heb de mogelijkheid om hulp op afstand te organiseren. De Primeur heb ik een paar maanden geleden gedaan met JanWandelaar. Ook hij zag wandelingen zitten, maar JOSM te moeilijk. Na een uurtje samen achter de 'PC' heb ik je door de meeste probleempjes met relaties heen geholpen. mvrgr Robert Citeren ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: Ik denk dat je beter af bent met josm dan potlatch... voor het editen van relaties Gert Van: TheoV [mailto:urbanci...@gmail.com] Verzonden: woensdag 29 juni 2011 17:56 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] wandelroute Ok, ik heb het teruggezet naar =tertiary; maar dan zie ik geen mogelijkheid in Potlatch om bij tabblad walking een route te kiezen. een mogelijkheid die wel wordt gegeven bij =track. dus gelijktijdig een highway en een wandelpad: kan dat? hoe doe ik dat in Potlatch? via het tabblad cycle zie je dat de LF21 en een regionale route wel aan diezelfde asfaltweg gerelateerd zijn. Theo Op 29 juni 2011 15:04 schreef Floris Looijesteijn o...@floris.nu het volgende: Hoi Theo, Jij hebt van de weg een highway=track gemaakt, terwijl het gewoon een highway=tertiary moet blijven. Je hebt de route ingevoerd als relatie, volgens mij is dat voldoende. Hier is de history van de weg: http://www.openstreetmap.org/browse/way/6588201/history Draai je het zelf terug? Groet, Floris 2011/6/29 TheoV urbanci...@gmail.com: hoi, Ik loop een wandelroute LAW (nu de Havezatenroute); Heb pas de Zuiderzeeroute (LAW8) gelopen en wil de route in OSM opnemen. Even geprobeeerd bij de IJsselmeerdijk in Warder NH; Probleem is dat de asfaltweg daarna als een stippellijn gepresenteerd wordt. Wat doe ik niet goed? TheoV ___ 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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] radlkarte.at
Hi Markus, mir fehlt im Waldbereich die Beschaffenheit des Weges. - Was fuer einen Untergrund habe ich? - Wie steil ist es? Wenn ich eine Tour plane ist es wichtig zu wissen, ob ich ein MTB brauche oder mit einem normalen Rad dort entlang komme. Auch ob ich mit meinen Kindern die Strecke fahren kann, ohne dass die Fahrt in Stress ausartet. Ansonsten gefaellt mir dein Ansatz schon ganz gut. bis dann David Am 29.06.2011 22:03, schrieb Markus Straub: liebe liste, ich arbeite seit geraumer zeit an einem mapnik style für eine fahrradkarte, da ich mit der opencyclemap nicht ganz zufrieden war. das ergebnis bis jetzt könnt ihr euch hier ansehen: -- http://www.radlkarte.at -- das hehre ziel war die karte übersichtlich zu halten, nicht zu überladen, aber dennoch alle für radfahrer wichtigen aspekte zu visualisieren. im moment ist ganz österreich verfügbar, der letzte import ca vor einer woche passiert (noch importiere ich manuell und nur österreich) feedback ist erwünscht, am liebsten natürlich in konkreten vorschlägen, z.b. 'graue wege sieht man im wald nicht gut, nimm dich stattdessen #XX für fahrverbot für radler' schöne grüße aus wien, markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] radlkarte.at
Hallo Markus, die Karte sieht schon mal sehr gut aus. Allerdings hab ich auch ein paar Kritikpunkte. Da wären die ganzen Grüntöne. Grüner Radweg auf grüner Fläche (Wald, Wiese) ist nicht gut zuerkennen. Weiterhin wäre es nützlich, wenn man die Wege abseits der Straßen auch nach deren Zustand unterschieden werden. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] radlkarte.at
Markus Straub markus.straub.at at gmail.com writes: ich arbeite seit geraumer zeit an einem mapnik style für eine fahrradkarte, da ich mit der opencyclemap nicht ganz zufrieden war. das ergebnis bis jetzt könnt ihr euch hier ansehen: -- http://www.radlkarte.at -- Auf den ersten Blick macht das einen sehr ordentlichen Eindruck. feedback ist erwünscht, am liebsten natürlich in konkreten vorschlägen, z.b. 'graue wege sieht man im wald nicht gut, nimm dich stattdessen #XX für fahrverbot für radler' Zum Stil selber kann ich erstmal noch keine Aussage machen. Zur Funktion im allgemeinen: - Button zum Ausblenden der Legende ist zu unscheinbar. Das schwarz auf transparent geht bei mir komplett unter. - Letzter Zustand sollte via Cookie gemerkt werden. Noch muss ich die Layer-Auswahl und die Legende bei jedem Besuch wieder wegklicken. Auch letzter Zoomwert und letzte Kartenposition könnten im Cookie hinterlegt werden. Sehr schön finde ich, dass die POIs als extra Layer ausgeblendet werden können. Wenn du in einem zweiten Schritt Deutschland mit in die DB nehmen könntest, wäre natürlich klasse. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] radlkarte.at
hi, kurz: angenehme Farbmischung. Das von Henning angesprochene Grün-in-grün-Problem finde ich nicht hinderlich. G.t. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] highway=axis
Hi, hab ich da was verpasst: http://www.openstreetmap.org/browse/way/118720117 highway=axis barrier=beam_barrier visor=hedge oder ist jemand da einfach nur erfindungsreich? Gab es dazu mal ne Diskussion zum Thema Mapping von Autobahn-Mittelstreifen? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30.06.2011 12:32, schrieb Frederik Ramm: hab ich da was verpasst: http://www.openstreetmap.org/browse/way/118720117 highway=axis barrier=beam_barrier visor=hedge oder ist jemand da einfach nur erfindungsreich? Vermutlich, sind denn alle 84 Stück vom Wolfgang gemappt worden? Gab es dazu mal ne Diskussion zum Thema Mapping von Autobahn-Mittelstreifen? Nicht dass ich wüsste. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30. Juni 2011 12:32 schrieb Frederik Ramm frede...@remote.org: hab ich da was verpasst: http://www.openstreetmap.org/browse/way/118720117 highway=axis barrier=beam_barrier visor=hedge oder ist jemand da einfach nur erfindungsreich? Gab es dazu mal ne Diskussion zum Thema Mapping von Autobahn-Mittelstreifen? Dazu gabs m.E. keine Diskussion (muss ja auch nicht unbedingt). Ich finde das Mappen von solchen Dingen durchaus hilfreich, allerdings ist highway=axis m.E. murks und überflüssig (das ist kein highway sondern eine barrier). Für Leitplanken verwende ich persönlich barrier=guard_rail (gibts ca. 273 im planet), beam_barrier bisher erst 75 mal. visor=hedge ist vermutlich Unsinn, ist auch im Wiki nicht dokumentiert und hat erst 42 Vorkommen: http://taginfo.openstreetmap.de:8001/keys/visor#values Vermute dass visor nicht richtige Wort ist, ich stelle mir da eher die Klappe einer Ritterrüstung oder das Glas eines Sturzhelms vor, ganz sicher bin ich mir allerdings auch nicht. M.E. kann es nicht schaden, wenn man nicht besonders gut Englisch spricht, mal auf tagging nachzufragen, bevor man irgendwelche Übersetzungen im Wörterbuch sucht, und dann Wörter wählt, die nicht passen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30. Juni 2011 13:02 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 30. Juni 2011 12:32 schrieb Frederik Ramm frede...@remote.org: Vermute dass visor nicht richtige Wort ist, ich stelle mir da eher die Klappe einer Ritterrüstung oder das Glas eines Sturzhelms vor, ganz sicher bin ich mir allerdings auch nicht. M.E. kann es nicht schaden, wenn man nicht besonders gut Englisch spricht, mal auf tagging nachzufragen, bevor man irgendwelche Übersetzungen im Wörterbuch sucht, und dann Wörter wählt, die nicht passen. Gegenvorschlag für visor: central_reservation (scheint gem. Wikipedia BE zu sein): http://en.wikipedia.org/wiki/Central_reservation Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30/06/2011 13:06, schrieb M∡rtin Koppenhoefer: Am 30. Juni 2011 13:02 schrieb M∡rtin Koppenhoeferdieterdre...@gmail.com: Am 30. Juni 2011 12:32 schrieb Frederik Rammfrede...@remote.org: Vermute dass visor nicht richtige Wort ist, ich stelle mir da eher die Klappe einer Ritterrüstung oder das Glas eines Sturzhelms vor, ganz sicher bin ich mir allerdings auch nicht. M.E. kann es nicht schaden, wenn man nicht besonders gut Englisch spricht, mal auf tagging nachzufragen, bevor man irgendwelche Übersetzungen im Wörterbuch sucht, und dann Wörter wählt, die nicht passen. Gegenvorschlag für visor: central_reservation (scheint gem. Wikipedia BE zu sein): http://en.wikipedia.org/wiki/Central_reservation Im Straßenbau ist Median gebräuchlich und wird auch von vielen Non-English-Natives verwendet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] radlkarte.at
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.06.2011 08:53, schrieb Manuel Reimer: Wenn du in einem zweiten Schritt Deutschland mit in die DB nehmen könntest, wäre natürlich klasse. Erweiterungen der Bereichs sind immer gut. Unabhängig davon schlage ich vor, nicht an der österreichischen (oder ggf. der deutschen) Grenze aufzuhören, sondern auch einen vernünftigen Bereich drumherum ebenfalls darzustellen. Beispiel: http://www.radlkarte.at/?zoom=13lat=47.57062lon=10.5205layers=B000T Hier wäre es nützlich, den weißen Bereich (Pfronten) zu füllen, damit die Verbindung von Vils über das Engetal nach Grän oder über das Vilstal nach Schattwald vorhanden ist. Wenn Du für Radler relevante Gefahrenstellen aufnehmen möchtest, würde ich Weideroste darstellen, z.B. im o.g. Bereich Straße L261 im Engetal http://www.openstreetmap.org/browse/node/307921404 Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4MbC0ACgkQnMz9fgzDSqeMmACfQelWe3wPQJDfQMeR8MtTpuMy ZUUAn0ZQkODdufteQlfvre70DPIwHyGh =Kvea -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30.06.2011 13:06, schrieb M∡rtin Koppenhoefer: Am 30. Juni 2011 13:02 schrieb M∡rtin Koppenhoeferdieterdre...@gmail.com: Am 30. Juni 2011 12:32 schrieb Frederik Rammfrede...@remote.org: Vermute dass visor nicht richtige Wort ist, ich stelle mir da eher die Klappe einer Ritterrüstung oder das Glas eines Sturzhelms vor, ganz sicher bin ich mir allerdings auch nicht. M.E. kann es nicht schaden, wenn man nicht besonders gut Englisch spricht, mal auf tagging nachzufragen, bevor man irgendwelche Übersetzungen im Wörterbuch sucht, und dann Wörter wählt, die nicht passen. Gegenvorschlag für visor: central_reservation (scheint gem. Wikipedia BE zu sein): http://en.wikipedia.org/wiki/Central_reservation Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Uninteressant ist ein Mittelstreifen sicherlich nicht, und es gibt da sicherlich auch die Interessantesten Begebenheiten... Ich interpretiere diese 3 Schlüssel so: highway=axis: Eine Achse, de facto ein Mittlerer Grenzstreifen zwischen zwei entgegengerichteten Autobahnspuren Da sehe ich dann statt Axis auch eher die central reservation (im BE) http://dict.leo.org/?lp=endefrom=fx3search=Trennstreifen barrier=beam_barrier: Hier soll wohl das Vorhandensein eines Sicht-/Blendschutzes angezeigt werden... wenn ich jetzt einfach mal grob zurückübersetze Sicherlich wäre der Ausbauzustand des Mittelstreifens allgemein interessanter. Also Leitplanke, Betonplanke, mit Begrühnung, Breite, mögliche Durchlassstelle, etc. visor=hedge Und dann noch ein zusätzlicher neuer Schlüssel, der Anzeigt, ob vom Mittelstreifen eine Schutzwirkung vor dem Licht des Gegenverkehres ausgeht... Ich weiß leider nicht, wie der Fachbegriff für diese ofmals verwendeten grünen Paddel lautet. vielleicht lieber mit glare shield übersetzen? wohl aber einfach nur als yes oder no spezifiziert Der Sicht-/Blendschutz wird durch Straßenbegleitgrün in Form einer Hecke realisiert... http://de.wikipedia.org/wiki/Straßenbegleitgrün So, das war mein Senf zu dem Thema... Grüße Dominik -- Dominik Wegerle fortunequest ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30. Juni 2011 14:19 schrieb Roland Spielhofer rsp...@gmx.net: Am 30/06/2011 13:06, schrieb M∡rtin Koppenhoefer: Gegenvorschlag für visor: central_reservation (scheint gem. Wikipedia BE zu sein): http://en.wikipedia.org/wiki/Central_reservation Im Straßenbau ist Median gebräuchlich und wird auch von vielen Non-English-Natives verwendet. Gem. Wikipedia ist das amerikanisches Englisch. Dazuhin ist das ein sehr vieldeutiges Wort. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Hallo, Am Donnerstag 30 Juni 2011 12:32:26 schrieb Frederik Ramm: Hi, hab ich da was verpasst: nö, nur was gefunden ;-) als Autor dieser Begriffe dazu: Ich halte es für sinnvoll, den Mittelstreifen zu mappen. Die Begriffe habe ich mir mit Hilfe von Leo rausgesucht. Im Straßenbau ist es in D üblich, die Mittellinie der Autobahn als Achse zu bezeichnen, das passt möglicherweise nicht unbedingt im Englischen Sprachbereich. http://www.openstreetmap.org/browse/way/118720117 highway=axis Mittellinie einer mehrspurigen Straße, ich habe kein Problem mit einer Umbenennung barrier=beam_barrier Barriere zum Schutz des Gegenverkehrs. beam_barrier = Leitplanke, concrete = Betonbarriere, ... visor=hedge Sichtschutz. scrub halte ich für übertrieben, Knick past auch nicht, am ehesten ist es IMO eine Hecke (diese Grünzeug-Kette, die ab und zu geschitten wird). Da brauchts auch noch einen Begriff für diese Metallblenden. Am HH- Flughafen gibt es eine Schnellstraße mit einem horizontalem Blendschutz über der Fahrbahn, damit die landenden Flugzeuge nicht geblendet werden. Dafür wäre das tag auch interessant. Eine Erläuterung dafür hatte ich gerade im Wiki begonnen, als der Server abgeschaltet wurde. Ich werde dazu demnächst eine Seite anlegen im Wiki, aber im Moment fehlt einfach die Zeit. Zu vorherigen Nachfragen in Mailinglisten: wer viel fragt, bekommt viel Antwort, aber ich habe noch nicht erlebt, dass man sich bei osm dabei irgendwie einig wird. Ich habe aber überhaupt kein Problem damit, die Dinge umzubenennen. ps. noch was: bridge=seperated -/- combined (an der Achse) Brückenbauwerke auf Autobahnen werden bisher überhaupt nicht erfasst. Getaggt wird nur da ist Brücke. Ob das jetzt ein Bauwerk ist oder zwei oder mehrere parallel stehen, geht bisher an osm vorbei, zumindest habe ich noch nichts dazu gefunden. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30. Juni 2011 18:40 schrieb Wolfgang wolfg...@ivkasogis.de: Ich halte es für sinnvoll, den Mittelstreifen zu mappen. +1. Nicht dass ich das für erste oder zweite Priorität halte, aber prinzipiell spricht nichts dagegen. Mein eigener Vorschlag (relation, type=area) dazu sieht u.a. vor, das auch implizit zuzulassen, so dass man nicht unnötig Pseudogeometrie eingeben muss, die dann doch keinen Mehrwert bringt (explizit geht mit der Relation natürlich auch, wird man aber eher selten brauchen). Die Begriffe habe ich mir mit Hilfe von Leo rausgesucht. das geht leider oft schief, besser hier oder auf tagging mal nachfragen. Im Straßenbau ist es in D üblich, die Mittellinie der Autobahn als Achse zu bezeichnen, das passt möglicherweise nicht unbedingt im Englischen Sprachbereich. http://www.openstreetmap.org/browse/way/118720117 highway=axis Mittellinie einer mehrspurigen Straße, ich habe kein Problem mit einer Umbenennung hier würde ich doch gerne nochmal nachhaken, weil die Achse einer mehrspurigen Straße haben wir in OSM bereits als way mit highway=* drin. Von daher finde ich highway als key eher ungeschickt, weil man dann schonmal bei nichtmehrbahnigen Straßen die Mittellinie taggen könnte. Auch Achse finde ich nicht so toll, den Begriff gibt es zwar im Straßenbau, er ist aber ggf. abstrakt, d.h. man benutzt die Achse zwar in der Konstruktion und zum Bezug, aber in der Realität findet man gerade bei mehrbahnigen Straßen meist keine Achse vor Ort vor (weil der Mittelstreifen nicht als Linie sondern flächig ausgebildet ist). Dir geht es ja um mehrteilige Straßen, also solchen, die aus mehreren Fahrbahnen bestehen. barrier=beam_barrier Barriere zum Schutz des Gegenverkehrs. beam_barrier = Leitplanke, concrete = Betonbarriere, ... barrier=concrete halte ich für schlecht, weil das ein Material und keinen Typ bezeichnet, wie wärs mit barrier=wall (oder ggf. jersey_barrier, dem spezifischen Ausdruck für die Teile)? Anstatt beam_barrier würde ich guard_rail verwenden. Beides ist hier dokumentiert im Wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/New_barrier_types visor=hedge Sichtschutz. scrub halte ich für übertrieben, Knick past auch nicht, am ehesten ist es IMO eine Hecke (diese Grünzeug-Kette, die ab und zu geschitten wird). Hecke ist OK, aber Visier? Ich glaube Du meintest etwas anderes ;-) Da stellt sich jetzt allerdings das übliche Problem bei barrier: welche Ebene taggt man, oder stapelt man? Unten Leitplanke oben Hecke (oft gibts auch unten Mauer, dann Zaun, und ggf. oben noch Stacheldraht). Oder Stützmauer mit Zaun oben drauf, etc. Dafür habe ich bisher auch keine detaillierte Lösung. ps. noch was: bridge=seperated -/- combined (an der Achse) lieber separated ;-) Brückenbauwerke auf Autobahnen werden bisher überhaupt nicht erfasst. Getaggt wird nur da ist Brücke. Ob das jetzt ein Bauwerk ist oder zwei oder mehrere parallel stehen, geht bisher an osm vorbei, zumindest habe ich noch nichts dazu gefunden. dazu gibts allerdings schon Vorschläge (z.B. bridge relation), jedenfalls aus meiner Sicht kein Grund, die Mitte zweier Straßen explizit zu zeichnen. Dieser separated/combined Ansatz würde ja sowieso wieder nur für bestimmte Fälle funktionieren. M.E. ist eine saubere Brücken-Einheit irgendwann an der Zeit, wo man noch viel mehr Zeugs dazutaggen kann, vom Baujahr über den Namen bis zu Details wie Konstruktionstyp, Auflager / Widerlager / Zugverankerungen etc. Dazu würde ich einen umschliessenden Way (Grundriss) haben wollen (analog sonstiger Gebäude), nicht einen Way in der Mitte zweier Straßen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] radlkarte.at
Liebe Liste, danke für die vielen Rückmeldungen! Das motiviert mich weiterhin meine Freizeit zu opfern :) Ich versuch mal auf die Antworten einzugehen, die meisten Kritikpunkte sind auf jeden Fall schon auf meiner sehr sehr langen TODO Liste gewesen, es ist also nur eine Frage der Zeit bis es realisiert wird. @David Ecker: Die Wegbeschaffenheit ist noch interessant, das stimmt.. ich hab derweil alles was asphaltiert oder tracktype=grade1 weiß gerendert. path track die grad2 oder weniger sind: braun. Steilheit: welches Attribut wäre das.. und vor allem: Vorschläge für ein Rendering? @Henning Scholland: Ja, ich weiß, es sind viele grüns auf der Karte. Ich hoffe noch immer eineN GrafikerIn zu finden um die Farben wirklich auf Vordermann zu bekommen. Ich finde die grüns sind aber gut unterscheidbar, viel schlechter find ich graue Wege im Wald.. da muss ich mir noch was einfallen lassen. @Manuel Reimer: Die Website ist im Moment nur prototypisch.. klar träume ich auch von Cookies, einer Legende, die nicht aus Worten sondern Bildern besteht etc.. Wenn du mir Code für die Cookies schicken könntest weil du sowas schon wo gemacht hast - gerne, bau ich sofort ein! Ansonsten - ist schon auf der TODO Liste :) @Bodo Meissner: cattle_grid ist notiert. Das aktuelle Gebiet ist Österreich weil ich meinen Server nicht überlasten möchte und der Import des Geofabrik Extrakts halbwegs angenehm schnell geht.. Ich träume natürlich von der ganzen Welt, weiß aber nicht wann das spruchreif wird. Vorerst hoffe ich, dass ich bald Neusiedler Bodensee rendern kann, dadurch, dass sie als Relation zusammengestöpselt werden (oder weil sie nicht komplett im Export enthalten sind?) scheinen sie in meiner DB nicht auf (ich verwende noch osm2pgsql). Hat da wer eine Idee? LG, Markus On 2011-06-30 08:29, David Ecker wrote: Hi Markus, mir fehlt im Waldbereich die Beschaffenheit des Weges. - Was fuer einen Untergrund habe ich? - Wie steil ist es? Wenn ich eine Tour plane ist es wichtig zu wissen, ob ich ein MTB brauche oder mit einem normalen Rad dort entlang komme. Auch ob ich mit meinen Kindern die Strecke fahren kann, ohne dass die Fahrt in Stress ausartet. Ansonsten gefaellt mir dein Ansatz schon ganz gut. bis dann David Am 29.06.2011 22:03, schrieb Markus Straub: liebe liste, ich arbeite seit geraumer zeit an einem mapnik style für eine fahrradkarte, da ich mit der opencyclemap nicht ganz zufrieden war. das ergebnis bis jetzt könnt ihr euch hier ansehen: -- http://www.radlkarte.at-- das hehre ziel war die karte übersichtlich zu halten, nicht zu überladen, aber dennoch alle für radfahrer wichtigen aspekte zu visualisieren. im moment ist ganz österreich verfügbar, der letzte import ca vor einer woche passiert (noch importiere ich manuell und nur österreich) feedback ist erwünscht, am liebsten natürlich in konkreten vorschlägen, z.b. 'graue wege sieht man im wald nicht gut, nimm dich stattdessen #XX für fahrverbot für radler' schöne grüße aus wien, markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
2011/6/30 M∡rtin Koppenhoefer dieterdre...@gmail.com M.E. kann es nicht schaden, wenn man nicht besonders gut Englisch spricht, mal auf tagging nachzufragen, bevor man irgendwelche Übersetzungen im Wörterbuch sucht, und dann Wörter wählt, die nicht passen. Wenn man schon nicht gut Englisch spricht, dann hat man erst recht nicht die sprachlichen Fähigkeiten, um auf einer englischsprachigen Mailingliste zu fragen. Zumal die allermeisten Mapper noch nie von einer tagging-Mailingliste gehört haben dürften. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
2011/6/30 Wolfgang wolfg...@ivkasogis.de Hallo, Am Donnerstag 30 Juni 2011 12:32:26 schrieb Frederik Ramm: Hi, hab ich da was verpasst: nö, nur was gefunden ;-) als Autor dieser Begriffe dazu: Ich halte es für sinnvoll, den Mittelstreifen zu mappen. Was willst du denn genau erfassen? Den Mittelstreifen als Straßenachse oder den Mittelstreifen als bauliche Trennung? Bei letzterem sollte dann auch die Trennung der Richtungsfahrbahnen von den Paralelfahrbahnen im Autobahnkreuz erfasst werden. Wobei das dann eigentlich überflüssig ist, da wir sowieso nur die einzelnen Fahrbahnen mappen; für das mappen von Fahrspuren gibt es noch kein überzeugendes Konzept. Im Straßenbau ist es in D üblich, die Mittellinie der Autobahn als Achse zu bezeichnen, das passt möglicherweise nicht unbedingt im Englischen Sprachbereich. Jein. Im Straßenbau hat jede Fahrbahn ihre eigene Achse, also jede Richtungsfahrbahn, Rampe oder einbahnige Straße. Die Autobahn als ganzes hat dann als Straße bestehend aus 2 Richtungsfahrbahnen nochmal eine eigene Straßenachse, die im Regelfall im Mittelstreifen verläiuft. (Und im Brückenbau wird jede Pfeilerreihe auch noch als Achse bezeichnet.) Da brauchts auch noch einen Begriff für diese Metallblenden. Der Blendschutz / die Blendschutzzäune!? ps. noch was: bridge=seperated -/- combined (an der Achse) Brückenbauwerke auf Autobahnen werden bisher überhaupt nicht erfasst. Getaggt wird nur da ist Brücke. Ob das jetzt ein Bauwerk ist oder zwei oder mehrere parallel stehen, geht bisher an osm vorbei, zumindest habe ich noch nichts dazu gefunden. Vlt. hilft das: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Hallo, Am Donnerstag 30 Juni 2011 23:38:17 schrieb Robert S.: 2011/6/30 Wolfgang wolfg...@ivkasogis.de Ich halte es für sinnvoll, den Mittelstreifen zu mappen. Was willst du denn genau erfassen? Den Mittelstreifen als Straßenachse oder den Mittelstreifen als bauliche Trennung? Bei letzterem sollte dann auch die Trennung der Richtungsfahrbahnen von den Paralelfahrbahnen im Autobahnkreuz erfasst werden. Wobei das dann eigentlich überflüssig ist, da wir sowieso nur die einzelnen Fahrbahnen mappen; für das mappen von Fahrspuren gibt es noch kein überzeugendes Konzept. Nein, nur den Mittelstreifen als Mitte/Trennung der Gegenfahrbahnen. Die Parallelfahrbahnen werden, sofern sie baulich getrennt sind, bereits korrekt erfasst, mit der Ausnahme gemeinsmer Brückenbauwerke. Im Straßenbau ist es in D üblich, die Mittellinie der Autobahn als Achse zu bezeichnen, das passt möglicherweise nicht unbedingt im Englischen Sprachbereich. Jein. Im Straßenbau hat jede Fahrbahn ihre eigene Achse, also jede Richtungsfahrbahn, Rampe oder einbahnige Straße. Die Autobahn als ganzes hat dann als Straße bestehend aus 2 Richtungsfahrbahnen nochmal eine eigene Straßenachse, die im Regelfall im Mittelstreifen verläiuft. (Und im Brückenbau wird jede Pfeilerreihe auch noch als Achse bezeichnet.) Die Autobahnbaustellen, mit denen ich in den letzten 30 Jahren zu tun hatte, hatten genau eine Ache in der Mitte. Das kann allerdings in Bereichen anders sein, in denen sich die Fahrbahnen voneinander trennen, aus welchen Gründen auch immer. Da brauchts auch noch einen Begriff für diese Metallblenden. Der Blendschutz / die Blendschutzzäune!? Ja, und auch für die Blendschutzdecke nach oben. ps. noch was: bridge=seperated -/- combined (an der Achse) Brückenbauwerke auf Autobahnen werden bisher überhaupt nicht erfasst. Getaggt wird nur da ist Brücke. Ob das jetzt ein Bauwerk ist oder zwei oder mehrere parallel stehen, geht bisher an osm vorbei, zumindest habe ich noch nichts dazu gefunden. Vlt. hilft das: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels Darin sehe ich keinen hilfreichen Beitrag. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Hi, Wolfgang wrote: Vlt. hilft das: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels Darin sehe ich keinen hilfreichen Beitrag. Der Plan ist, dass man langfristig eine Bruecke nicht als Eigenschaft einer Strasse erfasst, wie wir das im Moment tun, sondern als eigenes Bauwerk. Wenn man das aber tut, dann ist es natuerlich sinnvoll, die fuehrt-ueber oder fuehrt-unter-Beziehung zwischen einer Strasse und einem Brueckenbauwerk zu mappen - die Strasse hat dann nicht mehr eine Bruecke (wie jetzt), sondern sie fuehrt ueber eine Bruecke. So wird es dann moeglich, zu beschreiben, dass z.B. eine Eisenbahn, ein Fussweg und zwei Richtungsfahrbahnen einer Autobahn das gleiche Brueckenbauwerk verwenden, oder ein unterschiedliches; Ungenauigkeiten wie http://www.openstreetmap.org/?lat=49.0367lon=8.303934zoom=18layers=M wuerden dann der Vergangenheit angehoeren. Man koennte endlich auch Dinge tun wie einer Bruecke einen Namen zu geben, ohne den Namen der darueberfuehrenden Strasse zu vermurksen. Leider ist das eine elendige Frickelei, wenn man das richtig rendern will, und daher sind solche Relationen relativ selten genutzt. Da Du aber offensichtlich kein Problem mit visionaerem Tagging hast, das noch keiner richtig auswertet, koenntest Du ja auch ein Pionier des ordentlichen Brueckentaggings werden. Die Information, ob bridge=separated oder bridge=combined ergibt sich dann automatisch, und wie gesagt hat man auch den Vorteil, dass man modellieren kann, ob ein Fussweg noch mit ueber die gleiche Bruecke fuehrt usw. Bye Frederik PS: Gibt es das eigentlich ueberhaupt, dass Strassen und Schienen ueber die gleiche Bruecke fuehren? Ich kenne, zumindest in Deutschland, glaub ich nur separate Bruecken, selbst wenn beides direkt benachbart ist. -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Hallo, Am Donnerstag 30 Juni 2011 19:28:47 schrieb M∡rtin Koppenhoefer: Am 30. Juni 2011 18:40 schrieb Wolfgang wolfg...@ivkasogis.de: Ich halte es für sinnvoll, den Mittelstreifen zu mappen. +1. Nicht dass ich das für erste oder zweite Priorität halte, aber prinzipiell spricht nichts dagegen. Mein eigener Vorschlag (relation, type=area) dazu sieht u.a. vor, das auch implizit zuzulassen, so dass man nicht unnötig Pseudogeometrie eingeben muss, die dann doch keinen Mehrwert bringt (explizit geht mit der Relation natürlich auch, wird man aber eher selten brauchen). Den Mittelstreifen als area zu erfassen, ist sicherlich möglich. In der Realität ist der Mittelstreifen allerdings ein ganz langes, schmales Dings, das mit den Mittelpunktskoordinaten genau genug erfasst werden kann, ggf. unter Zuhilfenahme von width. hier würde ich doch gerne nochmal nachhaken, weil die Achse einer mehrspurigen Straße haben wir in OSM bereits als way mit highway=* drin. Von daher finde ich highway als key eher ungeschickt, weil man dann schonmal bei nichtmehrbahnigen Straßen die Mittellinie taggen könnte. Selbst wenn jemand auf die Idee käme: highway=axis wird von den Renderern (bisher) nicht unterstützt. Damit sehe ich keine Gefahr, dass jemand eine aus einer Fahrbahn bestehende Straße so taggt. Auch Achse finde ich nicht so toll, den Begriff gibt es zwar im Straßenbau, er ist aber ggf. abstrakt, d.h. man benutzt die Achse zwar in der Konstruktion und zum Bezug, aber in der Realität findet man gerade bei mehrbahnigen Straßen meist keine Achse vor Ort vor (weil der Mittelstreifen nicht als Linie sondern flächig ausgebildet ist). Ja, aber die Straße als Ganzes incl. aller Fahrsteifen, Standspur, Bankett, Graben, Böschung etc hängt ausschließlich an dieser Achse. Dir geht es ja um mehrteilige Straßen, also solchen, die aus mehreren Fahrbahnen bestehen. richtig barrier=beam_barrier Barriere zum Schutz des Gegenverkehrs. beam_barrier = Leitplanke, concrete = Betonbarriere, ... barrier=concrete halte ich für schlecht, weil das ein Material und keinen Typ bezeichnet, wie wärs mit barrier=wall -1, gibt es schon als Wände, beispielsweise an Tunnelbauwerken. (oder ggf. jersey_barrier, dem spezifischen Ausdruck für die Teile)? Anstatt beam_barrier würde ich guard_rail verwenden. Beides ist hier dokumentiert im Wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/New_barrier_types ich bin offen für bessere Begriffe visor=hedge Sichtschutz. scrub halte ich für übertrieben, Knick past auch nicht, am ehesten ist es IMO eine Hecke (diese Grünzeug-Kette, die ab und zu geschitten wird). Hecke ist OK, aber Visier? Ich glaube Du meintest etwas anderes ;-) visor != visier visor = Blendschutz, Nr.1 bei Leio aber schlage gerne was passenderes vor. Da stellt sich jetzt allerdings das übliche Problem bei barrier: welche Ebene taggt man, oder stapelt man? Unten Leitplanke oben Hecke (oft gibts auch unten Mauer, dann Zaun, und ggf. oben noch Stacheldraht). Oder Stützmauer mit Zaun oben drauf, etc. Dafür habe ich bisher auch keine detaillierte Lösung. barrier halte ich für das Wesentliche: Schutz vor Einwirkungen der Gegenrichtung. Der Blendschutz etc ist unterstützend für die Unfallvermeidung und sollte zusätzlich getaggt werden. ps. noch was: bridge=seperated -/- combined (an der Achse) lieber separated ;-) Brückenbauwerke auf Autobahnen werden bisher überhaupt nicht erfasst. Getaggt wird nur da ist Brücke. Ob das jetzt ein Bauwerk ist oder zwei oder mehrere parallel stehen, geht bisher an osm vorbei, zumindest habe ich noch nichts dazu gefunden. dazu gibts allerdings schon Vorschläge (z.B. bridge relation), jedenfalls aus meiner Sicht kein Grund, die Mitte zweier Straßen explizit zu zeichnen. Zeichnen verlangt niemand. Nur die Angabe der Mitte einer Straße mit mehreren Fahrbahnen. Welcher Renderer das für welchen Maßstab nutzt, ist eine ganz andere Sache. Dieser separated/combined Ansatz würde ja sowieso wieder nur für bestimmte Fälle funktionieren. M.E. ist eine saubere Brücken-Einheit irgendwann an der Zeit, wo man noch viel mehr Zeugs dazutaggen kann, vom Baujahr über den Namen bis zu Details wie Konstruktionstyp, Auflager / Widerlager / Zugverankerungen etc. Dazu würde ich einen umschliessenden Way (Grundriss) haben wollen (analog sonstiger Gebäude), nicht einen Way in der Mitte zweier Straßen. Sofort einverstanden. Aber bis das für alle Bauwerke weltweit gemappt ist, halte ich es für sinnvoll, dem Renderer für große Maßstäbe schon mal eine Möglichkeit des näherunsweise korrekten Zeichnens zu geben. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Hi, PS: Gibt es das eigentlich ueberhaupt, dass Strassen und Schienen ueber die gleiche Bruecke fuehren? Ich kenne, zumindest in Deutschland, glaub ich nur separate Bruecken, selbst wenn beides direkt benachbart ist. ja, gibt es. In Deutschland kenne ich aus dem Stegreif auch kein Beispiel für eine richtige Straße (Fußwege schon, siehe hier bei Bad Friedrichshall: [1], ist ja schließlich auch highway). Außerhalb von D kenne ich aber mindestens eine Brücke [2], wo das der Fall ist. Auch wenn es aktuell in OSM wie nebeneinander aussieht, hat diese Brücke zwei Ebenen (unten Eisenbahn, oben Straße+Straßenbahn+Obus). Über die bin ich selbst mehrfach gefahren, sogar auf beiden Ebenen :) Warum sollte es das auch nicht geben? Es gibt kein Naturgesetz, was das verbieten würde :) Selten ist es wohl aus politischen Gründen (Bahnverwaltung != Straßenbauverwaltung), weil die physikalischen Anforderungen (zulässige Achslast etc.) zu unterschiedlich sind und weil die Trassierung von Straßen sich deutlich von der der Bahnen unterscheidet, sodass sich diese eher kreuzen als parallel nebeneinander verlaufen. Grüße Igor [1] http://www.openstreetmap.org/?lat=49.231408lon=9.192716zoom=18layers=M [2] http://www.openstreetmap.org/?lat=48.48817lon=35.02507zoom=15layers=M ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 1. Juli 2011 00:48 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Donnerstag 30 Juni 2011 19:28:47 schrieb M∡rtin Koppenhoefer: Am 30. Juni 2011 18:40 schrieb Wolfgang wolfg...@ivkasogis.de: Ich halte es für sinnvoll, den Mittelstreifen zu mappen. +1. Nicht dass ich das für erste oder zweite Priorität halte, aber prinzipiell spricht nichts dagegen. Mein eigener Vorschlag (relation, type=area) dazu sieht u.a. vor, das auch implizit zuzulassen, so dass man nicht unnötig Pseudogeometrie eingeben muss, die dann doch keinen Mehrwert bringt (explizit geht mit der Relation natürlich auch, wird man aber eher selten brauchen). Den Mittelstreifen als area zu erfassen, ist sicherlich möglich. In der Realität ist der Mittelstreifen allerdings ein ganz langes, schmales Dings, das mit den Mittelpunktskoordinaten genau genug erfasst werden kann, ggf. unter Zuhilfenahme von width. vermutlich hast Du Dir die relation area nicht angesehen, und zugegebenermaßen könnte man das proposal auch noch besser beschreiben. Die Idee ist, dass man nur die beiden bereits bestehenden highways einfügen würde und über die area-Relation beschreibt man im Normalfall eine virtuelle area wo man über Tags z.B. definiert, aus was sie besteht (hier z.B. Hecke). Optional kann man natürlich für diese Tags auch eine Geometrie zeichnen, aber aus den Straßenbreiten ergibt sich die Breite des Mittelstreifens meist von selbst. Man definiert so gleichzeitig auch eine lineare Übergangsmöglichkeit z.B. für Fußgänger (bzw. an der Autobahn würde man foot=no setzen, da verboten). Auch Achse finde ich nicht so toll, den Begriff gibt es zwar im Straßenbau, er ist aber ggf. abstrakt, d.h. man benutzt die Achse zwar in der Konstruktion und zum Bezug, aber in der Realität findet man gerade bei mehrbahnigen Straßen meist keine Achse vor Ort vor (weil der Mittelstreifen nicht als Linie sondern flächig ausgebildet ist). Ja, aber die Straße als Ganzes incl. aller Fahrsteifen, Standspur, Bankett, Graben, Böschung etc hängt ausschließlich an dieser Achse. bei der Konstruktion / Herstellung vielleicht. In der realen Welt sieht man sie nicht. Sie ist ein theoretisches / vermessungstechnisches Konstrukt. barrier=concrete halte ich für schlecht, weil das ein Material und keinen Typ bezeichnet, wie wärs mit barrier=wall -1, gibt es schon als Wände, beispielsweise an Tunnelbauwerken. das ist auch nichts anderes als eine Wand, daher ja der Vorschlag. Mit entsprechender Höhe ist es klar definiert. visor != visier visor = Blendschutz, Nr.1 bei Leio Dir ist schon klar, dass Blendschutz z.B. auch eine Sonnenbrille ist? aber schlage gerne was passenderes vor. s.o. im Thread dazu gibts allerdings schon Vorschläge (z.B. bridge relation), jedenfalls aus meiner Sicht kein Grund, die Mitte zweier Straßen explizit zu zeichnen. Zeichnen verlangt niemand. Nur die Angabe der Mitte einer Straße mit mehreren Fahrbahnen. Welcher Renderer das für welchen Maßstab nutzt, ist eine ganz andere Sache. mit zeichnen meine ich, dass man einen expliziten Way mit expliziten Nodes einträgt, wie Du das getan hast. Dazu würde ich einen umschliessenden Way (Grundriss) haben wollen (analog sonstiger Gebäude), nicht einen Way in der Mitte zweier Straßen. Sofort einverstanden. Aber bis das für alle Bauwerke weltweit gemappt ist, halte ich es für sinnvoll, dem Renderer für große Maßstäbe schon mal eine Möglichkeit des näherunsweise korrekten Zeichnens zu geben. ja, aber bitte nicht so. Lasst es uns gleich so machen, dass es auch weiterverwendbar ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Brücken ( war: highway=axis)
Moin! Am 01.07.2011 00:44, schrieb Frederik Ramm: PS: Gibt es das eigentlich ueberhaupt, dass Strassen und Schienen ueber die gleiche Bruecke fuehren? Ich kenne, zumindest in Deutschland, glaub ich nur separate Bruecken, selbst wenn beides direkt benachbart ist. Das ist gar nicht so selten. In Schleswig-Holstein fallen mir spontan die Fehmarnsundbrücke, die Grünentaler Hochbrücke und die Levensauer Hochbrücke mit je einer zweispurigen Straße und einem Gleis ein. Etwas kurios ist die Schleibrücke bei Lindaunis [1], wo ein Gleis in der einspurigen Fahrbahn liegt. Der Verkehr der L283 wird wechselweise über die Brücke geführt wenn nicht ein Zug kommt oder das bewegliche Brückenteil für den Schiffsverkehr aufgeklappt wird. Viele Grüße Stephan [1] http://osm.org/go/0HnuoQ2WS- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Hallo, Am Freitag 01 Juli 2011 00:44:23 schrieb Frederik Ramm: PS: Gibt es das eigentlich ueberhaupt, dass Strassen und Schienen ueber die gleiche Bruecke fuehren? Ich kenne, zumindest in Deutschland, glaub ich nur separate Bruecken, selbst wenn beides direkt benachbart ist. weitere Beispiele dazu: Rethe-Hubbrücke in Hamburg (falsch dargestellt), http://www.openstreetmap.org/?lat=53.872488lon=10.682243zoom=18layers=M Katwyk-Hubbrücke in Hamburg (falsch dargestellt), http://www.openstreetmap.org/?lat=53.494048lon=9.952092zoom=18layers=M Brücke am Museumshafen in Lübeck (als einzige richtig dargestellt) http://www.openstreetmap.org/?lat=53.872488lon=10.682243zoom=18layers=M Bei allen genannten Brücken führen die Schienen in der Mitte der Fahrbahn über die Brücke. Für einen Zug wird die Brücke mit Schranken für den Straßenverkehr gesperrt wie ein langgezogener Bahnübergang. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Hallo, Am Freitag 01 Juli 2011 01:27:44 schrieb M∡rtin Koppenhoefer: vermutlich hast Du Dir die relation area nicht angesehen, und zugegebenermaßen könnte man das proposal auch noch besser beschreiben. Die Idee ist, dass man nur die beiden bereits bestehenden highways einfügen würde und über die area-Relation beschreibt man im Normalfall eine virtuelle area wo man über Tags z.B. definiert, aus was sie besteht (hier z.B. Hecke). Optional kann man natürlich für diese Tags auch eine Geometrie zeichnen, aber aus den Straßenbreiten ergibt sich die Breite des Mittelstreifens meist von selbst. Man definiert so gleichzeitig auch eine lineare Übergangsmöglichkeit z.B. für Fußgänger (bzw. an der Autobahn würde man foot=no setzen, da verboten). Das ist eine Möglichkeit, die ich aber aus Gründen der Zweckmäßigkeit für ungünstig halte. Bei unserer Erfassungsqualität schwankt diese Area gewaltig in der Breite, während in der Realität der Mittelstreifen über (mindestens) viele Kilometer die gleiche Breite hat., was durch das width-Tag wesentlich besser erfasst wird. Lineare Bauwerke wie Straßen oder Mittelsteifen lassen sich durch die real als Mittelleitplanke vorhandene Achse besser abbilden als durch eine Fläche. Es spricht natürllich nichts dagegen, zusätzlich ein Flächenpolygon aufzunehmen, das Thema hatten wir schon vor längerer Zeit (Straßen als Flächen). Im Übrigen stellst du mit deiner Area nicht die Leitplanke dar. bei der Konstruktion / Herstellung vielleicht. In der realen Welt sieht man sie nicht. Sie ist ein theoretisches / vermessungstechnisches Konstrukt. -1, s.o. barrier=concrete halte ich für schlecht, weil das ein Material und keinen Typ bezeichnet, wie wärs mit barrier=wall -1, gibt es schon als Wände, beispielsweise an Tunnelbauwerken. das ist auch nichts anderes als eine Wand, daher ja der Vorschlag. Mit entsprechender Höhe ist es klar definiert. -1 Wand = Senkrecht, Betonabweiser ist keine senkrechte Wand. Ich kann da leider nicht anhalten, um das Ding genau aufzunehmen. visor != visier visor = Blendschutz, Nr.1 bei Leio Dir ist schon klar, dass Blendschutz z.B. auch eine Sonnenbrille ist? Da in der Straßenmitte kaum ein Wall aus Sonnenbrillen montiert wird, kann ich damit leben. Im Übrigen heißt der *Key* visor, nicht der Value. Dazu würde ich einen umschliessenden Way (Grundriss) haben wollen (analog sonstiger Gebäude), nicht einen Way in der Mitte zweier Straßen. Sofort einverstanden. Aber bis das für alle Bauwerke weltweit gemappt ist, halte ich es für sinnvoll, dem Renderer für große Maßstäbe schon mal eine Möglichkeit des näherunsweise korrekten Zeichnens zu geben. ja, aber bitte nicht so. Lasst es uns gleich so machen, dass es auch weiterverwendbar ist. -1 Es ist so weiterverwendbar, nichts spricht gegen zusätzliche Polygone als Bauwerksgrenzen. Außerdem haben wir allein in D eine nette Menge an Brücken (allein in HH über 2500 lt. Wikipedia), die mit einem (richtigen!) Polygon noch eine nette Arbeit für die nächsten Jahre darstellen können. Bei OSM ist es üblich, eine Sache zunächst mal zu erfassen, damit sie erfasst ist. Verbessern kann man immer. Vor einiger Zeit schrieb hier mal jemand, wenn wir die Zeit für diese Diskussionen zum Mappen genutzt hätten, wäre Deutschland schon fertig. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Hallo, Am Freitag 01 Juli 2011 06:03:40 schrieb Wolfgang: Hallo, Rethe-Hubbrücke in Hamburg (falsch dargestellt), http://www.openstreetmap.org/?lat=53.872488lon=10.682243zoom=18layers=M und hat dann auf den falschen Link geklickt :-( Korrekt: http://www.openstreetmap.org/?lat=53.504282lon=9.967763zoom=18layers=M Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Operator bei Bundesstraßen und Autobahnen
Hallo! Es gibt in Deutschland ja einige Streckenabnschnitte von Bundesstraßen (z.B. Herrentunnel in Lübeck) und Autobahnen (z.B. A1 zwischen Hamburg und Bremen) die von privaten Unternehmen betrieben werden. Also kommt an diese Streckenabschnitte ganz klar ein entsprechender Operator. Nun gibt es ja auch die Sammelrelationen für Autobahnen bzw. Bundesstraßen; dort steht aber als Operator 'Bundesrepublik Deutschland' drin. Für die ganze Strecke ist das aber falsch. Wie soll man nun vorgehen? Die Information aus der Relation rausnehmen und alle Streckenabschnitte taggen? Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Operator bei Bundesstraßen und Autobahnen
Hallo, Am Freitag 01 Juli 2011 07:14:19 schrieb Christian H. Bruhn: Hallo! Es gibt in Deutschland ja einige Streckenabnschnitte von Bundesstraßen (z.B. Herrentunnel in Lübeck) und Autobahnen (z.B. A1 zwischen Hamburg und Bremen) die von privaten Unternehmen betrieben werden. Also kommt an diese Streckenabschnitte ganz klar ein entsprechender Operator. Nun gibt es ja auch die Sammelrelationen für Autobahnen bzw. Bundesstraßen; dort steht aber als Operator 'Bundesrepublik Deutschland' drin. Für die ganze Strecke ist das aber falsch. Wie soll man nun vorgehen? Die Information aus der Relation rausnehmen und alle Streckenabschnitte taggen? Oder der Regel folgen, dass das Spezielle das Allgemeinere verdrängt / überlagert. Ins Wiki eintragen und gut ist. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Richiesta di ri-licenza dati alla Regione Veneto
In data domenica 22 maggio 2011 21:19:32, Maurizio Napolitano ha scritto: / Uff ... // Il documento gfoss.it e' pronto solo che e' ancora in attesa di // alcune firme importanti. // potete pazientare ancora un po'? / Novità su questo fronte? E' arrivata la tanto sospirata firma? Alessandro Pozzato ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Richiesta di ri-licenza dati alla Regione Veneto
Sul fronte gfoss.it le cose vanno avanti a rilento, ma vanno avanti. Il problema non e' gfoss.it ma la p.a. Nel frattempo sono entrato in contatto diretto con le persone della regione Veneto (per altro progetto). Qualcosa si e' mosso ... vediamo iprossimi passi :) On 30/06/2011, Alessandro Pozzato apozz...@libero.it wrote: In data domenica 22 maggio 2011 21:19:32, Maurizio Napolitano ha scritto: / Uff ... // Il documento gfoss.it e' pronto solo che e' ancora in attesa di // alcune firme importanti. // potete pazientare ancora un po'? / Novità su questo fronte? E' arrivata la tanto sospirata firma? Alessandro Pozzato -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Richiesta di ri-licenza dati alla Regione Veneto
Il 30 giugno 2011 09:58, Maurizio Napolitano napoo...@gmail.com ha scritto: Sul fronte gfoss.it le cose vanno avanti a rilento, ma vanno avanti. Il problema non e' gfoss.it ma la p.a. Arrivati a questo punto, secondo me, la cosa migliore e' ufficializzare comunque il documento. Che e' firmato dalle associazioni ... Ci fate un riassunto della situazione? Quante e quali associazioni hanno aderito? Dove leggiamo il testo finale? Ciao. luca -- Passa al software libero! ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: Italian lights
2011/6/28 Federico Cozzi f.co...@gmail.com: 2011/6/27 M∡rtin Koppenhoefer dieterdre...@gmail.com: L'import si occupa della costa Italiana occidentale e della Sardegna. Se vi va aiutate a correggere gli eventuali errori. Servirebbero le posizioni dei fari importati, per aiutare a correggere gli errori... La risposta che mi hanno dato è giustamente un link al changeset: http://www.openstreetmap.org/browse/changeset/8558956 ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: Italian lights
2011/6/30 M∡rtin Koppenhoefer dieterdre...@gmail.com: La risposta che mi hanno dato è giustamente un link al changeset: http://www.openstreetmap.org/browse/changeset/8558956 Per vedere le coordinate dovresti usare questo file: http://www.openstreetmap.org/api/0.6/changeset/8558956/download ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: Italian lights
Messaggio originale Da: dieterdre...@gmail.com Data: 30/06/2011 13.35 A: openstreetmap list - italianotalk-it@openstreetmap.org Ogg: Re: [Talk-it] Fwd: Italian lights 2011/6/30 M∡rtin Koppenhoefer dieterdre...@gmail.com: La risposta che mi hanno dato è giustamente un link al changeset: http://www.openstreetmap.org/browse/changeset/8558956 Per vedere le coordinate dovresti usare questo file: http://www.openstreetmap.org/api/0.6/changeset/8558956/download ciao, Martin ___ Il changeset è composto da 23 pagine: io mi occupo della 23-esima ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: Italian lights
Il 27/06/2011 13:25, M∡rtin Koppenhoefer ha scritto: L'import si occupa della costa Italiana occidentale e della Sardegna. Se vi va aiutate a correggere gli eventuali errori. Ho corretto qualche errore, in particolare ho riportato i tag di un faro su un building che avevo mappato in precedenza. Ora però questo non viene visualizzato da openseamap. Sempre nell'ottica di non mappare per il rendering, come è meglio mappare il faro? - lasciarlo così com'è (un area taggata con building=yes e tutti i tag che sono stati importati da openseamap) - aggiungere un nodo al centro, riportando gli stessi tag (ma così non si viene a creare un duplicato?) - ...altro? Grazie, Martin Ciao Stefano signature.asc Description: OpenPGP digital signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: Italian lights
2011/6/30 Stefano Pallicca palli...@gmail.com: Il 27/06/2011 13:25, M∡rtin Koppenhoefer ha scritto: L'import si occupa della costa Italiana occidentale e della Sardegna. Se vi va aiutate a correggere gli eventuali errori. Ho corretto qualche errore, in particolare ho riportato i tag di un faro su un building che avevo mappato in precedenza. Ora però questo non viene visualizzato da openseamap. Sempre nell'ottica di non mappare per il rendering, come è meglio mappare il faro? - lasciarlo così com'è (un area taggata con building=yes e tutti i tag che sono stati importati da openseamap) - aggiungere un nodo al centro, riportando gli stessi tag (ma così non si viene a creare un duplicato?) - ...altro? secondome hai fatto bene. Casomai potresti segnalare il bug a OSeaM che devono guardare anche le aree. Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: Italian lights
Il 30/06/2011 14:15, M∡rtin Koppenhoefer ha scritto: 2011/6/30 Stefano Pallicca palli...@gmail.com: Ho corretto qualche errore, in particolare ho riportato i tag di un faro su un building che avevo mappato in precedenza. Ora però questo non viene visualizzato da openseamap. Sempre nell'ottica di non mappare per il rendering, come è meglio mappare il faro? - lasciarlo così com'è (un area taggata con building=yes e tutti i tag che sono stati importati da openseamap) - aggiungere un nodo al centro, riportando gli stessi tag (ma così non si viene a creare un duplicato?) - ...altro? secondome hai fatto bene. Casomai potresti segnalare il bug a OSeaM che devono guardare anche le aree. Ho dato un'occhiata alla wiki (perché lo faccio sempre dopo? :-) ), e come spesso avviene i miei dubbi sono aumentati, anziché diminuire... Partiamo da [1]: dice di mappare i fari (edifici da visualizzare a prescindere dalla loro funzione nautica) come area e di applicare: man_made=lighthouse + building=yes + name=* E di mappare invece i fari (intesi come ausili alla navigazione) con un nodo, a cui sono applicati tutti i vari tag dei oseamap. Sulla pagina del wiki dei fari, secondo lo schema oeseamap [2] dice come taggare i fari. Ora ho visto che nell'import, quello che io avrei taggato come faro, in realtà viene chiamato light_major. Non ho capito la differenza, tuttavia adesso sarei propenso a taggare come segue: l'area che ho già definito come man_made=lighthouse building=yes E poi inserire al suo interno un nodo con tutte le indicazioni derivanti dall'import. Che ne pensate? Ciao, Martin Ciao Stefano [1] http://wiki.openstreetmap.org/wiki/Lighthouse#Data_Scheme [2] http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights_Data_Model#Lighthouse signature.asc Description: OpenPGP digital signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: Italian lights
Messaggio originale . Partiamo da [1]: dice di mappare i fari (edifici da visualizzare a prescindere dalla loro funzione nautica) come area e di applicare: man_made=lighthouse + building=yes + name=* E di mappare invece i fari (intesi come ausili alla navigazione) con un nodo, a cui sono applicati tutti i vari tag dei oseamap. taggato come faro, in realtà viene chiamato light_major. Non ho capito la differenza, - - - - - - Concordo con quanto scritto sopra: man_made=lighthouse building=yes è giusto che sia mappato come area: è un edificio ed è riconoscibile anche di giorno (quando le luci dei fari sono spente) I tag di openseamap servono per riconoscere (anche da lontano) la luce del faro, che è un punto e andrebbe mappata più precisamente possibile. L'edificio che ospita il faro potrebbe essere grosso anche diverse decine di metri (mettiamo il caso che ospiti anche la Capitaneria di Porto), il faro deve essere sempre un punto. I light_major sono i fari veri e propri e servono ad orientarsi durante la navigazione, i light_minor invece indicano gli ingressi dei porti, delle banchine, segnalano delle secche ecc.. ed hanno una portata luminosa molto inferiore ai primi perchè servono 'localmente' e non devono essere poter confusi con i light_major dai naviganti (ma per questo c'è anche una codifica luminosa differente). Alessandro P.S.: ho verificato i fari della 23-esima pagina del changeset ed ho tolto il tag please_fix_position solo ai pochi di cui ero certo che quella fosse la posizione esatta. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] comuni che liberano dati? o forse no
ciao, mi sono imbattuto in questi tre siti web: http://www.comune.forli.fc.it/cartografiavettoriale/default.asp?sect=informativa http://cartografia.comune.padova.it/website/tuttopadova/viewer.asp http://websit.provincia.roma.it ovviamente, non viene segnalata nessuna licenza di uso dei dati, qualcuno ha notizie in piu'? ho gia' mandato mail agli indirizzi indicati per avere informazioni, aspettiamo. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-es] Guia para catrasteitor
El 30/06/2011, a las 07:08, Oscar Fonts escribió: 2011/6/29 Iván Sánchez Ortega: +1 a la idea de un catastreitor-hackathon. ¿En Agosto valdría? Por mí valdría si es antes del 22 y no coincide con operación salida/retorno/ciudaddevacaciones (por poder moverse). vale... lugar? ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Guia para catrasteitor
El 30/06/2011 08:36, sergio sevillano sergiosevillano.m...@gmail.com escribió: El 30/06/2011, a las 07:08, Oscar Fonts escribió: 2011/6/29 Iván Sánchez Ortega: +1 a la idea de un catastreitor-hackathon. ¿En Agosto valdría? Por mí valdría si es antes del 22 y no coincide con operación salida/retorno/ciudaddevacaciones (por poder moverse). vale... 13-14 o 20-21 en Madrid o Valencia? Hacemos tambien meeting de la asociación? -- Jaime ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Guia para catrasteitor
El 30/06/2011, a las 08:42, jynus escribió: El 30/06/2011 08:36, sergio sevillano sergiosevillano.m...@gmail.com escribió: El 30/06/2011, a las 07:08, Oscar Fonts escribió: 2011/6/29 Iván Sánchez Ortega: +1 a la idea de un catastreitor-hackathon. ¿En Agosto valdría? Por mí valdría si es antes del 22 y no coincide con operación salida/retorno/ciudaddevacaciones (por poder moverse). vale... 13-14 o 20-21 cualquiera me vale en Madrid o Valencia? prefiero madrid... Hacemos tambien meeting de la asociación? ok s.___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] radlkarte.at
On Thu, Jun 30, 2011 at 12:07:35AM +0200, Markus Straub wrote: -- http://www.radlkarte.at -- das hehre ziel war die karte übersichtlich zu halten, nicht zu überladen, aber dennoch alle für radfahrer wichtigen aspekte zu visualisieren. Also ich hab ja schon das eine oder andere Mal Feedback gegeben :) Und ich find die Karte ziemlich cool. Allerdings: - ich find nicht, dass es wirklich sinnvoll ist, bus- und strassenbahnhaltestellen einzuzeichnen. ich find die eher entbehrbar. - es sind noch immer keine rad-abstell-plätze eingezeichnet. gruesse, Stephan -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Plepelits, | | Technische Universität Wien -Studien Informatik Raumplanung | | Projects: | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | Contact:| | Mail: sk...@xover.mud.at Blog: plepe.at Jabber: sk...@fsinf.at| | Twitter: twitter.com/plepe Wave: plepel...@googlewave.com | `-' signature.asc Description: Digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] radlkarte.at
2011/6/30 Stephan Plepelits sk...@xover.htu.tuwien.ac.at: On Thu, Jun 30, 2011 at 12:07:35AM +0200, Markus Straub wrote: -- http://www.radlkarte.at -- das hehre ziel war die karte übersichtlich zu halten, nicht zu überladen, aber dennoch alle für radfahrer wichtigen aspekte zu visualisieren. Also ich hab ja schon das eine oder andere Mal Feedback gegeben :) Und ich find die Karte ziemlich cool. Allerdings: - ich find nicht, dass es wirklich sinnvoll ist, bus- und strassenbahnhaltestellen einzuzeichnen. ich find die eher entbehrbar. - es sind noch immer keine rad-abstell-plätze eingezeichnet. Was mir beim ersten Ansehen aufgefallen ist: Im Gegensatz zur OpenCycleMap werden Radwege, die *unter* z.B. der Autobahn durchgehen, nicht durchgängig gezeichnet. Ich finde, da es um Radwege geht, dürfen die auch ruhig in den obersten Layer ;) eg: http://www.radlkarte.at/?zoom=18lat=48.32362lon=14.29841layers=B000T Hannes ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] radlkarte.at
On 06/30/2011 12:07 AM, Markus Straub wrote: liebe liste, das ergebnis bis jetzt könnt ihr euch hier ansehen: -- http://www.radlkarte.at -- Ich find schön, dass endlich mal die in highways integrierten cycleways gezeichnet werden. Vielleicht hält das ja ein paar Leute davon ab unnötig parallele Radwege anzulegen. (War schon länger auf meiner Wunschliste sowas zu haben, vielen Dank dafür.) Was mich ein bisschen stört (ich aber auch nicht weiß wie verbessern) ist, dass die grünen Radstreifen wie ein Fremdkörper im Straßennetz ausschauen (gut, das sind sie ja auch immer noch). Ich fänd das schön, wenn es dir gelingen würde bspw. Autobahnen nur relativ transparent anzudeuten und dafür den Kontrast zwischen normaler residential und div. Fahrradstreifen/-straßen zu reduzieren. Auf die Gefahr hin, dass Wien anhand vom Straßennetz nicht mehr auf den ersten Blick als Wien zu erkennen ist, aber dafür alle Straßen die für Radfahrer in irgendeiner Form befahrbar sind als optisch zusammenhängendes Straßennetz erkennbar sind. (So, ich hoff ich hab mich vage genug ausgedrückt um deine Kreativität anzuregen. *G*) lg, Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] OT: Suche defektes GPS
Hi, ist etwas OT hier, aber ev. hat einer von euch ein altes, defektes und höchstens noch als Briefbeschwerer taugliches GPS Device rumliegen, dass er mir gegen Versandkosten abtreten würde. Mir ist eigentlich ganz egal was für ein Device das ist, wenn es nicht zu groß wär, wär das super. Ich hab vor das Teil zu zerlegen, es sollte also wirklich vollkommen unbrauchbar sein, denn danach ist es das ganz sicher. danke, Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OT: Suche defektes GPS
Hallo Norbert, da könnte ich dir helfen. Hab sowas zuhause rumliegen. Kann es dir gerne am Montag zusenden (oder du holst es in Linz ab). LG Dominik Am 30. Juni 2011 09:04 schrieb Norbert Wenzel norbert.wenzel.li...@gmail.com: Hi, ist etwas OT hier, aber ev. hat einer von euch ein altes, defektes und höchstens noch als Briefbeschwerer taugliches GPS Device rumliegen, dass er mir gegen Versandkosten abtreten würde. Mir ist eigentlich ganz egal was für ein Device das ist, wenn es nicht zu groß wär, wär das super. Ich hab vor das Teil zu zerlegen, es sollte also wirklich vollkommen unbrauchbar sein, denn danach ist es das ganz sicher. danke, Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at -- Freundliche Grüße / Best regards, Dominik Hurnaus *C *a t a l y s t s Software Engineer Mobil: +43 (650) 723 6 723 dominik.hurn...@catalysts.cc www.catalysts.cc Ottensheimer Straße 27, A-4040 Linz *task**mind** ** ... Aufgaben im Team erledigen** www.taskmind.net* http://www.taskmind.net/ Catalysts GmbH, Firmensitz: 4232 Hagenberg, Firmenbuchnummer: FN 292140v beim Landesgericht Linz ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] radlkarte.at
On 2011-06-30 08:57, Hannes Brandstätter-Müller wrote: 2011/6/30 Stephan Plepelitssk...@xover.htu.tuwien.ac.at: On Thu, Jun 30, 2011 at 12:07:35AM +0200, Markus Straub wrote: -- http://www.radlkarte.at-- das hehre ziel war die karte übersichtlich zu halten, nicht zu überladen, aber dennoch alle für radfahrer wichtigen aspekte zu visualisieren. Also ich hab ja schon das eine oder andere Mal Feedback gegeben :) Und ich find die Karte ziemlich cool. Allerdings: - ich find nicht, dass es wirklich sinnvoll ist, bus- und strassenbahnhaltestellen einzuzeichnen. ich find die eher entbehrbar. - es sind noch immer keine rad-abstell-plätze eingezeichnet. Was mir beim ersten Ansehen aufgefallen ist: Im Gegensatz zur OpenCycleMap werden Radwege, die *unter* z.B. der Autobahn durchgehen, nicht durchgängig gezeichnet. Ich finde, da es um Radwege geht, dürfen die auch ruhig in den obersten Layer ;) eg: http://www.radlkarte.at/?zoom=18lat=48.32362lon=14.29841layers=B000T Ähnliches finde ich auch: http://www.radlkarte.at/?zoom=15lat=47.12244lon=15.36038layers=B000T Da ist der Radweg (grün) von einer Straße (grau) unterbrochen. Etwas unschön, ich erwarte eigentlich, das der Radweg (grüner strich) durchgängig ist. Oder aber ich verstehe gerade die Karte weniger... Hannes ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at MfG, Lars Schimmer -- - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] radlkarte.at
On 06/30/2011 12:58 AM, Boris Cornet wrote: Der zweite Eindruck ist: Ups, da passt was mit dem Datenmodell noch nicht ganz. Ich hatte noch nicht Zeit, das genau zu studieren, aber ich habe in Innsbruck auf den ersten Blick eine nicht unbeträchtliche Menge an grünen Wegen gefunden, die eindeutig NICHT mit dem Fahrrad befahren werden dürfen. Es scheint, dass der OP highway=track (m. tracktype=grade1) per default grün renderst. Nichtsdestotrotz ein ambitioniertes Projekt und sicher am richtigen Weg. LG; Stefan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] radlkarte.at
Servus Markus! So, jetzt hatte ich etwas mehr Zeit... Gestern nacht schrieb ich: OK, der erste Eindruck ist: sieht sehr aufgeräumt und übersichtlich aus. ...und der erste Eindruck trügt nie ;-) Ich komme mehr und mehr zur Überzeugung, dass hier etwas großartiges entsteht! ich habe in Innsbruck auf den ersten Blick eine nicht unbeträchtliche Menge an grünen Wegen gefunden, die eindeutig NICHT mit dem Fahrrad befahren werden dürfen. Für diese Aussage muss ich Abbitte leisten: Diese Stellen waren alle falsch getaggt! Auf der cyclemap sind sie mir aber nie aufgefallen. Da sieht man wieder, wie wichtig Spezialkarten für das Aufspüren von Fehlern sind. Auch scheint es noch ein Probelm bei Radwegen gegen die Einbahn zu geben (kein Richtungspfeil). Auch hier hab ich mich getäuscht, ich hab die 'Radikalität' deines Ansatzes nicht gecheckt. Wenn der Radweg gegen die Einbahn geht, ist die Einbahn aus Radfahrersicht nicht existent, und wird also erst gar nicht eingezeichnet. Passt! Das selbe gilt für die Fußgängerzonen mit bicycle=yes (die werden als normale Straße dargestellt), aber damit bin ich nicht ganz glücklich. Bei der Planung einer schnellen Route würde ich Fußgängerzonen (ohne dezidierte Radspuren) fast immer umgehen, also sollte diese Information schon ersichtlich sein, wie wäre es mit hellblau? Drittens fehlen die Radrouten (relationen) komplett. Dieses Manko ist gravierend, ich würde vorschlagen, sie analog zur cyclemap dezent halbtransparent darzustellen. Stephan Plepelits schrieb: - ich find nicht, dass es wirklich sinnvoll ist, bus- und strassenbahnhaltestellen einzuzeichnen. ich find die eher entbehrbar. Einspruch! In vielen Städten (wie auch Innsbruck) ist die Fahrradmitnahme in Bussen und Straßenbahn kostenlos, somit sind Haltestellen schon eine interessante Information. Im Sinne der Übersichtlichkeit würde ich aber den Haltestellen-Namen weglassen. = Und nun zu einem schwierigen Thema: track und path und damit der ganze Themenkreis Moutainbiking und die vermaledeite Streitfrage [foootway + cycleway = path?]. Derzeit werden alle tracks mit grade1 grün, also als dezidierte Radwege dargestellt (und zwar leider unabhängig davon, ob es einen bicycle tag gibt). Dafür wird ein path (selbst wenn er mit bicicle=designated getaggt ist), braun, also gleich wie ein track = grade2 dargestellt. Hierzu wird es wohl noch einige Denkarbeit benötigen. Stichworte: - bicycle = designated|official vs. yes: Ich würde hier eine deutliche Unterscheidung vornehmen. Das wird zwar zur Folge haben, dass eine Weile recht uneinheitliche und z.T. auch falsche Informationen dargestellt werden, aber das ist gut so. Auf diese Art wird es automatisch zu einer Bereinigung dieses Trümmerhaufens kommen. - Ist-Situation vs. Gesetz: grundsätzlich darf man in den meisten Bundesländern auf Forstwegen *nicht* Rad fahren, außer sie sind ausdrücklich freigegeben (aus Haftungsgründen). Tatsächlich schert sich kein Mensch darum, auch nicht die Exekutive. - Vorwiegend in Deutschland ist es üblich gemeinsame Rad/Fußwege als path mit bicycle=designated|official zu taggen. Ob das sinnvoll ist, sei dahingestellt (auf [talk-de] tobt seit Jahren ein grausamer Grabenkampf darüber). Fakt ist, das es im Sinne des damaligen proposals für path ist, ebenso Fakt ist, dass es in Österreich - wie ich meine glücklicherweise - weitgehend anders gehandhabt wird. (Falls darüber jetzt hier eine Diskussion ausbricht, BITTE, BITTE in einem anderen thread!!!) - tracktype und mtb:scale: Ein zwiespältiges Thema. Währen ein Rennradler schon bei grade2 scheitert, ist einem Benützer eines Trekking-Rads mtb:scale=1 gerade noch zuzumuten. Es wird also nötig sein, Kategorisierungen vorzunehmen. Sinnvoll erscheint mir: - Kat.1: Rennrad-geeignet (durchgehende Linie) - Kat.2: Trekkingrad-geeignet (strichliert) - Kat.3: Moutainbiking (gepunktete Linie) = Noch ein paar Dinge: Häuser: dass 'wichtige' Häuser markant dargestellt werden, finde ich sehr gut, aber ich vermisse trotzdem die anderen. Sollte man sie nicht doch in *sehr* hellem Grau darstellen? Es gibt offenbar ein Problem mit dem layer-tag bzw. bridge und tunnel, ich habe ein paar Stellen gefunden, wo die Darstellung nicht stimmt (Tunnel verläüft über der Straße, Brücke darunter). Ich konnte keine Regelmäßigkeit dabei feststellen, also vermute ich, dass es mit dem Alter der Daten zu tun hat (first come, first served). Bei der klassischen OSM Karte sieht man solche Effekte bei Einmündungen, aber nie bei Tunnels und Brücken. Ich schließe mich der Meinung von Hannes an: Im Gegensatz zur OpenCycleMap werden Radwege, die *unter* z.B. der Autobahn durchgehen, nicht durchgängig gezeichnet. Ich finde, da es um Radwege geht, dürfen die auch ruhig in den obersten Layer ;) .. oder sollten wenigstens strichliert durchgezogen werden. bicycle=dismount: wäre das nicht auch berücksichtigenswert? Im freien Gelände (speziell in den Bergen) gibt es zu wenig Orientierungspunkte. Kannst
Re: [Talk-pe] Saludos
Hola Vladimircs y Omar Vega Gracias por responderme. Omar, gracias por las referencias están muy buenas y voy a ponerme a estudiarlas, con respecto a mi tesis quisiera hacer un sistema experto de control de vehículos, para lo cual tengo un amigo que me a autorizado hacer las pruebas con su empresa (Empresa interprovincial). Con respecto al móvil que tengo es un Nokia y un LG Optimus (Androi). Vladimircs, ahora me uno a la red de facebook y twitter Saludos Jonathan Lázaro Date: Wed, 29 Jun 2011 09:11:58 -0500 From: vladimi...@gmail.com To: talk-pe@openstreetmap.org Subject: Re: [Talk-pe] Saludos No lo actualizamos tanto como quisiéramos, pero también podriasunirte a nuestra pagina de facebook, para compartir rutas de mapeo,fotografias y noticias... http://www.facebook.com/pages/OpenStreetMap-Per%C3%BA/214559971889533?sk=wall y tambien en twitter:http://twitter.com/#!/osmpe cuéntanos un poco mas sobre cual es tu proyecto de tesis y que modelo es tu telefono para ver si podemos sugerirtealgún software... Por lo demás cualquier duda... aquí estamos... saludos El 29 de junio de 2011 08:09, Omar Vega Ramos ovr...@riseup.net escribió: Hola Jonathan o/ Que bueno que estés interesado en OpenStreetMaps, no estoy seguro si entendí correctamente tus dudas, pero aquí respondo. - ¿Qué es OpenStreetMap? OpenStreetMap es un proyecto dirigido expresamente a crear y ofrecer datos geográficos libres, tales como planos de calles, a cualquiera que los desee. El proyecto comenzó debido a que muchos mapas que se cree que son libres, tienen en realidad restricciones legales o técnicas para su uso, lo cual evita que la población los utilice de forma creativa, productiva o inesperada. (¿Por qué hacemos OpenStreetMap? : http://wiki.openstreetmap.org/wiki/ES:FAQ#.C2.BFPor_qu.C3.A9_hacemos_OpenStreetMap.3F) - Te podría ser de ayuda también la Guía para principiantes: http://wiki.openstreetmap.org/wiki/ES:Beginners_Guide - También te podría servir para la edición el JOSM ( http://wiki.openstreetmap.org/wiki/ES:JOSM ) y en el caso de tu mobil puede servirte algún software de los de la lista, según sea tu dispositivo ( http://wiki.openstreetmap.org/wiki/Software/Mobile ) - Además información sobre el proyecto en Perú: http://wiki.openstreetmap.org/wiki/WikiProject_Per%C3%BA - En Trujillo se que ha estado cartografiando Harold Julian que creo es de TELCOM IP, tal vez con el podrías reunirte presencialmente para algún apoyo, además cualquier consulta también la puedes realizar por este medio. Bytes Hola Soy Jonathan Lázaro soy nuevo en esto de foros y grupos, quisiera conocer más acerca de OpenStreetMap, ya que quiero hacer mi tesis y quiero participar de manera activa con este proyecto open source ya que me entere que hacen recorridos GPS para hacer correcciones sobre la cartografía, ups me olvide de decir que soy de Trujillo y que tengo un Celular GPS disponible con el que puedo aportar mi granito de arena a este proyecto. Saludos ___ Talk-pe mailing list Talk-pe@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-pe -- Omar Vega Escucha radioGNU: http://radiognu.org/ Usa el facebook libre: http://www.gnewbook.org/ Usa el twitter libre: http://identi.ca/ ___ Talk-pe mailing list Talk-pe@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-pe -- Vladito VLADIMIR E. CASTRO SALAS La libertad no es el objetivo... es el PRINCIPIO ___ Talk-pe mailing list Talk-pe@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-pe ___ Talk-pe mailing list Talk-pe@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-pe
Re: [Talk-cz] Infikovaná data
tak nějak ... něco jsem opravoval a zařvalo to na mě, že nemůže uploadnout, tak jsem něco odklikal, ani jsem to nečetl, doufaje, že ví, co dělají ... pokud se to ukáže jako problém, tj. zmizí mi podstatnej kus dat pod rukama nebo si s tou mapou nebudu smět dělat, co potřebuju, tak jdu taky jinam (snad bude kam ...) ne že by se těch mejch pár editací ňák poznalo, ale cihlu k cihle ... odradit si dav mravenečků taky není ideální, třeba turistickejch tras je tolik, že není v silách pár jedinců to projít, a žádnej legální zdroj pro import nebo obkreslování AFAIK nemáme K. Dne St 29. června 2011 Jakub Sykora napsal(a): Ja jsem licenci odsouhlasil vicemene kvuli tomu, abych mohl na OSM dal pracovat. Pokud ale jednoho dne zjistim, ze chybi UHUL, dibavod a pulka mesta, tak se nastvu a pujdu najit neco jineho... K Dne 29.6.2011 16:49, honny napsal(a): Hmmm, sám jsem licenci odsouhlasil (takže moje data zůstanou), ale jak tu někdo psal o znechucení mapperů... Tak to docela sedí. Jak se říká: poslední zhasne. ~ honny ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Infikovan? data
On Wed 2011-06-29 17:01:40, hanoj wrote: Zajímavé je, že infikováno je spousta importů - adresy, lesy, dibavod. Je to tím, že v rozporu s import guidelines byla data importována pod účty běžných uživatelů. Z těchto dat by se dalo v budoucnu hodně zachránit. Anebo tím, že onen běžný uživatel odmítl licenci právě proto, že nemůže provést přelicencování dat ke zdrojům, které použil. *** Uz asi pred rokem probehlo na talk-cz: ti, kteri importy dali dispozici OSM je uplne jedno zda to bude CC-BY-SA nebo ODbL. Oni ta data dali protoze je chteli dat nebo jiz drive dali free k dispozici jiz pred tim, tj. UHUL, Dibavod, HS-RS, UIR-ADR. Odkaz? U uhulu/dibavodu/uir-adr tomu verim. Co BNHELP? To byla velmi dulezita data, od komercni firmy. Souhlasi s OdBL? A s kazdou dalsi licenci? Protoze licence se ted muze zmenit treba na libovolne komercni pouziti dovoleno Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Infikovaná data
Zdá se mi, že jsem tu asi trochu nešťastnou formulací vzbudil pěkný FUD :-( Omlouvám se. Jen aby bylo jasno, nikdo žádná data zatím nemaže. Data, která jsou k dispozici teď a které vzniknou až do dne D kdy se změní licence zůstanou k dispozici navždy. Projekt OSM je bude poskytovat po rozumně dlouhou dobu i nadále a vzhledem ke svobodné licenci budou existovat dokud budou mít pro někoho význam. Pro ty co novou licenci odsouhlasili tedy není zatím žádný důvod přestávat s editacemi, fork bude možno udělat kdykoli (a fosm.org to také tak zdá se zamýšlí). =TT= 2011/6/30 Karel Volný ka...@seznam.cz tak nějak ... něco jsem opravoval a zařvalo to na mě, že nemůže uploadnout, tak jsem něco odklikal, ani jsem to nečetl, doufaje, že ví, co dělají ... pokud se to ukáže jako problém, tj. zmizí mi podstatnej kus dat pod rukama nebo si s tou mapou nebudu smět dělat, co potřebuju, tak jdu taky jinam (snad bude kam ...) ne že by se těch mejch pár editací ňák poznalo, ale cihlu k cihle ... odradit si dav mravenečků taky není ideální, třeba turistickejch tras je tolik, že není v silách pár jedinců to projít, a žádnej legální zdroj pro import nebo obkreslování AFAIK nemáme K. Dne St 29. června 2011 Jakub Sykora napsal(a): Ja jsem licenci odsouhlasil vicemene kvuli tomu, abych mohl na OSM dal pracovat. Pokud ale jednoho dne zjistim, ze chybi UHUL, dibavod a pulka mesta, tak se nastvu a pujdu najit neco jineho... K Dne 29.6.2011 16:49, honny napsal(a): Hmmm, sám jsem licenci odsouhlasil (takže moje data zůstanou), ale jak tu někdo psal o znechucení mapperů... Tak to docela sedí. Jak se říká: poslední zhasne. ~ honny ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Infikovan? data
U uhulu/dibavodu/uir-adr tomu verim. Co BNHELP? To byla velmi dulezita data, od komercni firmy. Souhlasi s OdBL? A s kazdou dalsi licenci? Protoze licence se ted muze zmenit treba na libovolne komercni pouziti dovoleno Pavel -- Zrovna BNHELP jsou tak nekvalitní data, že pokaždé když na jejich zbytky narazím, lituji že jsme je tenkrát importovali. Když si pak vezmu jak rychle byly hotové silnice 3. třídy, tak jedničky a dvojky by byly v tom entuziastickém období hotové max. za měsíc ručně. Jó byla to jiná doba :-) Škoda :-( Jinak Pavle, jsem rád, že jsi neopustil konferenci, i když už se nechceš na projektu aktivně účastnit. Přemýšlel jsem ještě o těch importech a měl bych na Tebe jednu prosbu. Souhlasil bys prosím s tím, aby se data, která jsi importoval (a pouze importy, ne data na kterých jsi pracoval ručně) přelicencovala na novou licenci? Moje idea je taková, že bych vzal všechna data kde jsi autorem importu a nikdo je nezměnil, nebo na nich po importu pracovali pouze zelení uživatelé. Data bych smazal a vzápětí ta samá naimportoval pod speciálně vytvořeným uživatelem (nebo více uživateli - jedním pro každý dataset). Souhlasil bys s tím? Pokud ano, technické detaily bychom ještě doladili, teď bych chtěl jen vědět zda se tím máme vůbec zbývat. Díky za odpověď ať bude jakákoliv. =TT= ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Infikovan? data
Můžete mi někdo vysvětlit, jaký smysl má ten reimport? Přece pokud vezmeme data, které vytvořil někdo, kdo s novou licencí nesouhlasí, a znovu je tam naimportujem ve stejném znění, tak mi to přijde stejné, jako je kopírovat z čehokoliv jiného. Ano, v současné době jde o volná data k libovolnému použití - takže to vlastně jde, proč to ale pak prostě neudělat pro všechno - vytvořit uživatele reimport a všechna data, která by se jinak smazala, se přeimportují a bude vymalováno. Nějak mi to nedává celé smysl. A už vůbec ne, že budou nakonec dva projekty, což je v podstatě proti smyslu OSM. A nějak se mi také nechce věřit, že by se ta data opravdu smazala, maximálně, že by jich tam bylo velmi velmi málo. Jinak to může takto jet v podstatě donekonečna. V současné době by ale došlo ke smazání snad poloviny mapy, což si snad nikdo nedovolí. A jestli ano, tak projekt asi opustí hodně lidí, protože na tohle mít nervy nebudou. On 06/30/2011 11:00 PM, Tomáš Tichý wrote: U uhulu/dibavodu/uir-adr tomu verim. Co BNHELP? To byla velmi dulezita data, od komercni firmy. Souhlasi s OdBL? A s kazdou dalsi licenci? Protoze licence se ted muze zmenit treba na libovolne komercni pouziti dovoleno Pavel -- Zrovna BNHELP jsou tak nekvalitní data, že pokaždé když na jejich zbytky narazím, lituji že jsme je tenkrát importovali. Když si pak vezmu jak rychle byly hotové silnice 3. třídy, tak jedničky a dvojky by byly v tom entuziastickém období hotové max. za měsíc ručně. Jó byla to jiná doba :-) Škoda :-( Jinak Pavle, jsem rád, že jsi neopustil konferenci, i když už se nechceš na projektu aktivně účastnit. Přemýšlel jsem ještě o těch importech a měl bych na Tebe jednu prosbu. Souhlasil bys prosím s tím, aby se data, která jsi importoval (a pouze importy, ne data na kterých jsi pracoval ručně) přelicencovala na novou licenci? Moje idea je taková, že bych vzal všechna data kde jsi autorem importu a nikdo je nezměnil, nebo na nich po importu pracovali pouze zelení uživatelé. Data bych smazal a vzápětí ta samá naimportoval pod speciálně vytvořeným uživatelem (nebo více uživateli - jedním pro každý dataset). Souhlasil bys s tím? Pokud ano, technické detaily bychom ještě doladili, teď bych chtěl jen vědět zda se tím máme vůbec zbývat. Díky za odpověď ať bude jakákoliv. =TT= ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Infikovan? data
2011/6/30 Mike m...@mikecrash.com Můžete mi někdo vysvětlit, jaký smysl má ten reimport? Přece pokud vezmeme data, které vytvořil někdo, kdo s novou licencí nesouhlasí, a znovu je tam naimportujem ve stejném znění, tak mi to přijde stejné, jako je kopírovat z čehokoliv jiného. Ano, v současné době jde o volná data k libovolnému použití - takže to vlastně jde, proč to ale pak prostě neudělat pro všechno - vytvořit uživatele reimport a všechna data, která by se jinak smazala, se přeimportují a bude vymalováno. Nějak mi to nedává celé smysl. A už vůbec ne, že budou nakonec dva projekty, což je v podstatě proti smyslu OSM. Data u kterých tvůrce s novou licencí nesouhlasí se reimportovat nesmí !!! Mě jde o to, jak co nejjednodušeji reimportovat data (hlavně od státních institucí), která jsou použitelná se starou i novou licencí, ale víceméně omylem je importovali uživatelé, kteří s novu licencí nesouhlasí. Mimochodem velmi sympatický je mi v tomto ohledu krok společnosti Nearmap, která dříve poskytovala fotomapy pro OSM. S novou licencí nesouhlasí, takže jejich podklady už není možné využívat, ale dali generální souhlas s tím, aby data která vznikla v minulosti mohla být i nadále využívána pod libovolnou licencí. A nějak se mi také nechce věřit, že by se ta data opravdu smazala, maximálně, že by jich tam bylo velmi velmi málo. Jinak to může takto jet v podstatě donekonečna. V současné době by ale došlo ke smazání snad poloviny mapy, což si snad nikdo nedovolí. A jestli ano, tak projekt asi opustí hodně lidí, protože na tohle mít nervy nebudou. Nepředpokládám, že se bude cokoli mazat v dohledné době. Souhlasím s tím, že teď je vlastně ideální stav, protože teď je teoreticky možné vytvořit dva datasety s dvěma různými licencemi, takže si každý může vybrat. Ta data budou k sobě časem nevyhnutelně obsahově konvergovat. Ale sama od sebe to nezvládnou, takže jim bude potřeba trochu pomoci :-) Pokud se ale bude tento proces neúměrně protahovat, hrozí štěpení projektu, což by asi svobodným geodatům neprospělo jako celku. =TT= ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Infikovan? data
Dne Čt 30. června 2011 Tomáš Tichý napsal(a): Zrovna BNHELP jsou tak nekvalitní data, že pokaždé když na jejich zbytky narazím, lituji že jsme je tenkrát importovali. Když si pak vezmu jak rychle byly hotové silnice 3. třídy, tak jedničky a dvojky by byly v tom entuziastickém období hotové max. za měsíc ručně. Jó byla to jiná doba :-) Škoda :-( nezlob se na mě, na tohlento se nemůžu koukat, to jsou od tebe tak účelové kecy, že až to není možné, že ti není stydno :-( jestli je podle tebe lepší vůbec nemít informaci, že někde vede silnice, než ji mít s nějakou docela zanedbatelnou nepřesností (já jsem nikde nenarazil na víc než +-10 m, a to ještě kdovíjak na tom byla moje GPS a zarovnání dlaždic z ortofoto), a spoléhat na armádu dobrovolníků, která ovšem v té době nebyla, a aby byla, bylo potřeba už něco v mapě mít, protože málokdo je ochoten používat prázdnou mapu, tak tedy nevím ... K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Infikovaná data
oukej, a vysvětlíš nám tedy v rámci potírání FUDu, až ten den D přijde, jaký bude pro běžného uživatele rozdíl mezi tím, zda se data reálně smažou nebo zda se jenom zneviditelní na mapě a znepřístupní pro další editace? K. Dne Čt 30. června 2011 Tomáš Tichý napsal(a): Zdá se mi, že jsem tu asi trochu nešťastnou formulací vzbudil pěkný FUD :-( Omlouvám se. Jen aby bylo jasno, nikdo žádná data zatím nemaže. Data, která jsou k dispozici teď a které vzniknou až do dne D kdy se změní licence zůstanou k dispozici navždy. Projekt OSM je bude poskytovat po rozumně dlouhou dobu i nadále a vzhledem ke svobodné licenci budou existovat dokud budou mít pro někoho význam. Pro ty co novou licenci odsouhlasili tedy není zatím žádný důvod přestávat s editacemi, fork bude možno udělat kdykoli (a fosm.org to také tak zdá se zamýšlí). =TT= 2011/6/30 Karel Volný ka...@seznam.cz tak nějak ... něco jsem opravoval a zařvalo to na mě, že nemůže uploadnout, tak jsem něco odklikal, ani jsem to nečetl, doufaje, že ví, co dělají ... pokud se to ukáže jako problém, tj. zmizí mi podstatnej kus dat pod rukama nebo si s tou mapou nebudu smět dělat, co potřebuju, tak jdu taky jinam (snad bude kam ...) ne že by se těch mejch pár editací ňák poznalo, ale cihlu k cihle ... odradit si dav mravenečků taky není ideální, třeba turistickejch tras je tolik, že není v silách pár jedinců to projít, a žádnej legální zdroj pro import nebo obkreslování AFAIK nemáme K. Dne St 29. června 2011 Jakub Sykora napsal(a): Ja jsem licenci odsouhlasil vicemene kvuli tomu, abych mohl na OSM dal pracovat. Pokud ale jednoho dne zjistim, ze chybi UHUL, dibavod a pulka mesta, tak se nastvu a pujdu najit neco jineho... K Dne 29.6.2011 16:49, honny napsal(a): Hmmm, sám jsem licenci odsouhlasil (takže moje data zůstanou), ale jak tu někdo psal o znechucení mapperů... Tak to docela sedí. Jak se říká: poslední zhasne. ~ honny ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée
En fait il y a 2 versions du site: http://www.pistes-nordiques.org Le 29 juin 2011 23:04, Vincent Pottier vpott...@gmail.com a écrit : Le 29/06/2011 18:41, yvecai a écrit : Un autre exemple ici: http://dev-yves.dyndns.org/** alpha/pistes-nordiques-**backend/http://dev-yves.dyndns.org/alpha/pistes-nordiques-backend/ Excellent ! Bon, ça n'est pas la forte saison pour le ski, mais je vais faire découvrir aux Bisontins ! -- FrViPofm __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée
Par contre, pour la réalisation, je vois pas bien. Classiquement, les courbes de niveau est une informations que l'on cale sur un calque (si je puis dire) que l'on place au-dessus du calque de la nature des sols (les beaux pavés de couleurs variées) et en dessous des informations plus précises telles les routes. Du coup, je ne vois pas trop, à moins de splitter tous les rendus en deux, comment on peut intégrer des courbes de niveaux précalculées en raster. A moins qu'on ne parle pas de ça et que je sois hors sujet. Tu as tout à fait raison, mutualiser des tuiles raster de courbes de niveau ne peut pas être fait si simplement que ça. On peut cependant obtenir un résultat disons à peu prêt pas trop mauvais avec par exemple la méthode suivante : Un serveur fourni des tuiles raster de représentation des courbes de niveau avec les courbes et l'altitude de la courbe au format png, avec un fond transparent (et le canal alpha kivabien pour l'anti-aliasing). Un autre serveur fourni par exemple un fond en png sans transparence des ombrages des pentes Enfin, celui qui veut présenter un rendu spécial le réalise avec un fond transparent et demande à openlayers d'aller chercher les 3 tuiles pour que la tuile résultante en mémoire et visible à l'écran soit la somme des 3 Le résultat devrait donner quelque chose d'acceptable et mutualisé, avec toutefois des défauts : - la valeur des courbes de niveau va être obscurcie en partie par les surfaces de type forêt/prairies/etc. On pourrait découper le rendu spécial en 2 autres tuiles : le filaire+étendues d'eau (qui doivent passer par dessus les courbes de niveau) et le surfacique (qui doit passer sous les courbes de niveau) et faire un rendu coté navigateur par superposition de 4 couches voir plus. Je constate que j'avais d'ailleurs déjà détaillé ça ici : http://wiki.openstreetmap.org/wiki/Talk:Hiking/openhikingmap#Contours_sometimes_not_very_readable_.28TODO.29 En résumé, oui, ça serait cool, oui ça peut se faire, mais la résultat ne sera pas au mieux. -- sly qui suis-je : http://sly.letuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée
On mercredi 29 juin 2011, ad...@partir-en-vtt.com wrote: Bonjour, Il est tout à fait possible de générer des courbes de niveaux avec des outils libres comme GDAL avec la commande gdal_contour être possible ne veut pas dire être facile ;-) Pour passer des données SRTM à couverture mondial au format géotif, à des courbes de niveau vecteur au format shapefile, à des tuiles allant du zoom 0 au zoom 20 sur la terre entière, il n'y a peut-être qu'un pas, mais c'est un graad pas. Et la question que pieren a posé est : arriverait-on à les (les tuiles) mutualiser sur un serveur unique ? -- sly qui suis-je : http://sly.letuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée
Zut, alors faut que je change le design de mes boutons. Ce sont les deux boutons en bas à droite dans la barre. Les couches ne sont pas actives par défaut par manque de ressources :) On constate d'ailleurs un des défauts dont je parlais avant, les courbes s'affichent par dessus les routes, par dessus les toponymes ce qui nuit un peu à la lisibilité parfois. PS pour yves : ce n'est pas un reproche, j'aide à avancer la discussion : peut-on mutualiser les courbes de niveau -- sly qui suis-je : http://sly.letuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée
http://www.openstreetmap.org/?lat=45.23488lon=5.76347zoom=16layers=C (SRTM) contre http://www.refuges.info/nav.php?lat=45.23493lon=5.76284zoom=16layers=B000FTTFFFTTT (DEM3 j'imagine, peut-être que les auteurs pourront confirmer) J'utilise ASTER uniquement http://wiki.openstreetmap.org/wiki/Hiking/openhikingmap -- sly qui suis-je : http://sly.letuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée
And now for something completely different ... Ces histoires de serveurs de tuiles avec des superpositions d'images difficiles à gérer, cela m'a fait penser à l'approche très originale d'un développeur russe (Komяpa) pour le rendu des tuiles. A mon niveau, c'est complexe, je vais essayer de décrire les principes le plus simplement possible : L'objectif c'est de basculer la charge de rendu du côté du client, soit en pratique le navigateur web de l'utilisateur. Il y a donc un moteur javascript associé à du HTML 5, qui va générer des images selon des règles de rendu (format mapcss), en allant piocher des données vectorielles stockées sous forme de tuiles http://wiki.openstreetmap.org/wiki/Kothic_JS C'est proche du format GeoJSON, pour ceux qui suivent encore :-) Allez voir ici l'exemple de Minsk, c'est bluffant de qualité et de rapidité http://kothic.org/js/ (on a les statistiques de temps de rendu sur la droite de l'écran) Tout ceci est encore très expérimental, et il n'y a pas de tuiles disponibles pour de grandes zones géographiques. Je me demande dans quelle mesure les données d'altimétrie (SRTM ou autres) pourraient être intégrées à ces tuiles vectorielles et par voie de conséquence être utilisées pour faire le rendu Le vrai avantage de tout cela, c'est qu'un seul dépôt de tuiles vectorielles ouvrirait la possibilité de faire tous les ajustements imaginables dans les règles de rendu en fonction de l'usage (vélo, ski de fond, rando ...). Un jour peut-être ... Le 30 juin 2011 10:16, sly (sylvain letuffe) sylv...@letuffe.org a écrit : Zut, alors faut que je change le design de mes boutons. Ce sont les deux boutons en bas à droite dans la barre. Les couches ne sont pas actives par défaut par manque de ressources :) On constate d'ailleurs un des défauts dont je parlais avant, les courbes s'affichent par dessus les routes, par dessus les toponymes ce qui nuit un peu à la lisibilité parfois. PS pour yves : ce n'est pas un reproche, j'aide à avancer la discussion : peut-on mutualiser les courbes de niveau -- sly qui suis-je : http://sly.letuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Orthophoto Tours(s) Plus en panne ?
Bonjour, L'imagerie Orthophoto Tour(s) Plus ne fonctionne plus chez moi dans JOSM. Est-ce de même chez vous ? Merci -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_randonn=E9e?=)
On part un peu HS là, alors je change le titre Allez voir ici l'exemple de Minsk, c'est bluffant de qualité et de rapidité http://kothic.org/js/ (...) Un jour peut-être ... Pour moi, il est clair que cette solution à vraiment un bel avenir et du potentiel. A l'heure où même les téléphone portable intègrent des processeurs doubles coeur à 1.2Ghz, il devient très clairement envisageable (pour la masse) de concevoir des serveurs qui n'envoient plus des images figées dans la pierre mais bien des données vectorielle que le client pourra rendre selon ses souhaits. Ça existe déjà depuis longtemps avec le protocol WMS, mais c'était compliqué car il fallait à chaque fois le logiciel kivabien, une machine assez puissante et tout ça avec peu de flexibilité. L'arrivée de projet de ce type, ou un simple navigateur pourra lancer une petite application de rendu codée sur mesure en canvas+js ouvre la voie à que du bon ! Reste un peu d'optimisation pour accélérer, un peu de standardisation pour le format vecteur à envoyer, un peu plus de navigateur qui le supporte et ça devrait le faire. J'ai ouïe dire que openlayers avait un renderer js basé sur canvas... peut être que des solutions viendrons aussi de ce coté là -- sly qui suis-je : http://sly.letuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_randonn=E9e?=)
2011/6/30 sly (sylvain letuffe) sylv...@letuffe.org Pour moi, il est clair que cette solution à vraiment un bel avenir Comme d'hab, je ne vais pas être d'accord avec Sly mais on a l'habitude ;-) Cette solution ne marche que pour de l'expérimental, à faible échelle et à faible nombre de clients. Parce qu'au lieu de calculer le rendu une fois pour toutes, on le fait pour chaque client et à chaque visite (il y a des optimisations possibles). Vous allez me dire on s'en fout, c'est délocalisé chez le client. Oui, mais le client va faire une requête bdd pour chaque tuile. Le serveur qui fournit les données va rapidement s'écrouler face à la demande de requêtes, celles-ci augmentant proportionnellement avec le nombre de clients. Alors que la solution classique avec tuiles ne nécessite cet effort (requête vers la base) qu'une seule fois (à part les actualisations fréquentes de données qui sont un problème spécifique à OSM). On va me dire : oui mais on peut mettre tout ça en cache. C'est vrai. Mais il est plus facile et rapide de faire du cache d'images fixes (tuiles) que de données dont les requêtes (et les résultats) changent en permanence (niveau de zoom, type de rendu, position). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophoto Tours(s) Plus en panne ?
Bonjour, Je confirme, JOSM n'affiche pas de tuiles à ce niveau. D'ailleurs sur la sortie standard, il y a des messages du genre, /failed loading 18/131614/91840 http://tms.mapspot.ge/tms/2/nonstandard/18/131614/91840.jpeg/. Le serveur a du subir quelques changements. Il faut voir avec Simon, qui saura vraiment d'où vient le problème. A+ Le 30/06/2011 12:10, cyrille giquello a écrit : Bonjour, L'imagerie Orthophoto Tour(s) Plus ne fonctionne plus chez moi dans JOSM. Est-ce de même chez vous ? Merci -- Emmanuel Dewaele, Doctorant, Université de Tours, Laboratoire d'Informatique Ingénieur études et recherche, La Compagnie des mobilités 64, avenue Portalis bureau 202 37200 TOURS ? 06 26 94 94 71 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Début d'interface de génération à la demande des fichiers du cadastre
Le 28/06/2011 18:33, Damouns a écrit : J'ai commencé à développer une interface pour réaliser les fichiers du cadastre à la demande. C'est ultra-sommaire pour l'instant. N'hésitez pas à faire part de vos remarques. Les fichiers anciens ne sont pas remplacés par les nouveaux mais ils semblent s'ajouter sur ton serveur : par exemple sur http://cadastre.osm.cleo-carto.org/025/ les fichiers de FRASNE sont en trois exemplaires (j'ai fait la demande 2 fois) C'était un bug à la con que j'ai corrigé en ajoutant un trim() sur le nom de la ville. J'ai eu des échanges avec Pierre et quand je reprendrais le dev de ce machin, je vais recommencer à 0 avec un fonctionnement asynchrone plus intéressant. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Début d'interface de génération à la demande des fichiers du cadastre
Le 30/06/2011 13:45, Philippe Pary a écrit : Le 28/06/2011 18:33, Damouns a écrit : J'ai commencé à développer une interface pour réaliser les fichiers du cadastre à la demande. C'est ultra-sommaire pour l'instant. N'hésitez pas à faire part de vos remarques. Les fichiers anciens ne sont pas remplacés par les nouveaux mais ils semblent s'ajouter sur ton serveur : par exemple sur http://cadastre.osm.cleo-carto.org/025/ les fichiers de FRASNE sont en trois exemplaires (j'ai fait la demande 2 fois) C'était un bug à la con que j'ai corrigé en ajoutant un trim() sur le nom de la ville. Accessoirement, j'ai ôté les fichiers concernés : il va falloir régénérer vos villes :-) Pour la génération des départements, j'ajouterai l'option rapidement (dimanche ?) Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Début d'interface de génération à la demande des fichiers du cadastre
C'était un bug à la con que j'ai corrigé en ajoutant un trim() sur le nom de la ville. Accessoirement, j'ai ôté les fichiers concernés : il va falloir régénérer vos villes :-) Pour la génération des départements, j'ajouterai l'option rapidement (dimanche ?) OK merci ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Jeu de données ASTER = conversion en courbe de niveau
Bonjour, J'ai regardé les données ASTER, c'est facilement exploitable. Ci-joint, un jeu de données test sur une dalle avec un SHAPE contenant les courbes fusionnées selon l’altitude et un autre sans fusion. S'il faut produire cela à l'échelle Française, je pourrai lancer le traitement et vous faire un backup dans une base postgis par exemple. téléchargement du jeu de données Projection : wgs84 Code EPSG : 4326 Dites moi ce que vous en pensez. -- Loïc et Flo. Créateurs et administrateurs de www.partir-en-vtt.com.___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)
On jeudi 30 juin 2011, Pieren wrote: 2011/6/30 sly (sylvain letuffe) sylv...@letuffe.org Pour moi, il est clair que cette solution à vraiment un bel avenir Comme d'hab, je ne vais pas être d'accord avec Sly mais on a l'habitude ;-) Tant mieux ! ça ne serait pas drôle sinon, il faut bien confrontation pour avoir de nouvelles idées ou choses qu'on oublie. optimisations possibles). Vous allez me dire on s'en fout, c'est délocalisé chez le client. on s'en fout, c'est délocalisé chez le client ;-) J'admet toutefois que sur un tel modèle, l'opération de rendu nécessite au final beaucoup plus de temps CPU total puisqu'en effet, elle est exécutée chez chaque client (navigateur) plutôt qu'une fois pour tous sur le serveur. Tout est question de comparer ce qu'il y a à gagner en fonctionnalité et ce qu'il y a à perdre en energie totale consommée Oui, mais le client va faire une requête bdd pour chaque tuile. Le serveur qui fournit les données va rapidement s'écrouler face à la demande de requêtes, celles-ci augmentant proportionnellement avec le nombre de clients. Alors que la solution classique avec tuiles ne nécessite cet effort (requête vers la base) qu'une seule fois Mmmm, je pense que tu perçois la requête comme une lourde tâche alors que ça n'est pas forcément le cas. Il est question ici de tuiles vectorielles c'est à dire de l'ensemble des données vecteurs (utile au niveau de zoom demandé) présentes sur un carré fixe, défini à l'avance, pas un truc genre WMS ou les données sont construites à la volée. Il est envisageable, je pense, d'en garder une version en cache de la même manière que les serveurs de tuiles gardent une version image en cache et de la servir au navigateur. On pourrait même imaginer se passer de base de donnée pour ce cache et stocker des fichiers du syle : /zoom/x/y.json (.gml, .osm, ou le format qu'on aura décidé de garder à fournir au client) On va me dire : oui mais on peut mettre tout ça en cache. C'est vrai. Oups, ça m'apprendra à lire le mail dans son entier, avant ;-) Mais il est plus facile et rapide de faire du cache d'images fixes (tuiles) que de données dont les requêtes (et les résultats) changent en permanence (niveau de zoom, type de rendu, position). Pas forcément, voir plus haut le modèle auquel je pense. Qui, bien sûr, présente des défauts par rapport à la requête où on demande ce qu'on veut comme on veut sur une zone arbitraire. Cas typique du client qui ne veut afficher que les cours d'eau alors que la tuile contient forêt, cours d'eau, route, amenity, c'est à dire trop de données par rapport à l'affichage final souhaité -- sly qui suis-je : http://sly.letuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Jeu de données ASTER = conversion en courbe de niveau
On jeudi 30 juin 2011, ad...@partir-en-vtt.com wrote: Bonjour, J'ai regardé les données ASTER, c'est facilement exploitable. Ci-joint, un jeu de données test sur une dalle avec un SHAPE contenant les courbes fusionnées selon l’altitude et un autre sans fusion. Qu'entends tu par fusion et sans fusion ? Avec fusion tu veux dire que pour l'altitude 1000m par exemple tu n'as qu'un et un seul enregistrement de type MULTILINESTRING qui contient toutes les courbes d'altitude 1000m ? S'il faut produire cela à l'échelle Française, je pourrai lancer le traitement et vous faire un backup dans une base postgis par exemple. J'ai déjà ça pour une bonne partie de l'europe, mais je souhaiterais passer world wide pour mon rendu et je me heurte a des problèmes soit de méthodologie, soit de performance machine. Sans compter que les données ASTER sont à télécharger morceaux par morceaux et c'est un peu long. J'en suis là si ça peut gagner du temps : 19G amerique-nord 21G amerique-sud 90G europe 22G oceanie Mais je me heurte au problème des îles, de l'asie et du recouvrement des dalles que j'ai déjà récupéré. J'avais rêvé fusionner tout ça en un gros geotiff de la terre de 400 Go pour lancer ensuite du gdal_contours et du hillshading, hillcoloring dessus, mais je crois que ça va pas le faire. Faut que je re-réfléchisse au problème pour faire ça tuile par tuile -- sly qui suis-je : http://sly.letuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu coté navigateur (était: OSM destiné pour un besoin de randonnée)
sly == sly (sylvain letuffe) sylv...@letuffe.org writes: sly On pourrait même imaginer se passer de base de donnée pour ce cache et stocker sly des fichiers du syle : sly /zoom/x/y.json (.gml, .osm, ou le format qu'on aura décidé de garder à fournir sly au client) C'est effectivement ce qui est fait pour Kothic-JS http://osmosnimki.ru/vtile/ et il y a l'air d'avoir un moteur qui met ces tuiles à jour lorsque les données correspondantes évoluent (les dates des fichiers .js ne sont pas toutes les mêmes). -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)
J'ai la même compréhension : ce sont des tuiles vectorielles, qui doivent être générées selon une stratégie optimisée en fonction de la demande pour les zones géographiques données. Bref ce que l'on demande à des machins (*) qui répondent au doux nom de Renderd ou Tirex pour des tuiles image. Je suis d'ailleurs curieux de savoir dans quelle mesure ces outils pourraient gérer ce genre d'objets. C'est peut être assez transparent puisque les tuiles image suivent le même arrangement géographique que les tuiles images. (*) dénomination adaptée à mes connaissances en la matière Le 30 juin 2011 14:49, sly (sylvain letuffe) sylv...@letuffe.org a écrit : On jeudi 30 juin 2011, Pieren wrote: Oui, mais le client va faire une requête bdd pour chaque tuile. Le serveur qui fournit les données va rapidement s'écrouler face à la demande de requêtes, celles-ci augmentant proportionnellement avec le nombre de clients. Alors que la solution classique avec tuiles ne nécessite cet effort (requête vers la base) qu'une seule fois Mmmm, je pense que tu perçois la requête comme une lourde tâche alors que ça n'est pas forcément le cas. Il est question ici de tuiles vectorielles c'est à dire de l'ensemble des données vecteurs (utile au niveau de zoom demandé) présentes sur un carré fixe, défini à l'avance, pas un truc genre WMS ou les données sont construites à la volée. Il est envisageable, je pense, d'en garder une version en cache de la même manière que les serveurs de tuiles gardent une version image en cache et de la servir au navigateur. On pourrait même imaginer se passer de base de donnée pour ce cache et stocker des fichiers du syle : /zoom/x/y.json (.gml, .osm, ou le format qu'on aura décidé de garder à fournir au client) -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophoto Tours(s) Plus en panne ?
Hello, Vu d'ici http://tms.mapspot.ge/tms/2/nonstandard/18/131614/91840.jpeg - http://maps.qualitystreetmap.org/tiles/ortho08/18/131614/170303.jpeg est OK. Le service de redirection a dû avoir quelques petits soucis durant un instant, puisque rien ne m'a été remonté comme alerte au niveau de qualitystreetmap.org F. 2011/6/30 Emmanuel Dewaele emmanuel.dewa...@geovelo.fr: Bonjour, Je confirme, JOSM n'affiche pas de tuiles à ce niveau. D'ailleurs sur la sortie standard, il y a des messages du genre, failed loading 18/131614/91840 http://tms.mapspot.ge/tms/2/nonstandard/18/131614/91840.jpeg. Le serveur a du subir quelques changements. Il faut voir avec Simon, qui saura vraiment d'où vient le problème. A+ Le 30/06/2011 12:10, cyrille giquello a écrit : Bonjour, L'imagerie Orthophoto Tour(s) Plus ne fonctionne plus chez moi dans JOSM. Est-ce de même chez vous ? Merci -- Emmanuel Dewaele, Doctorant, Université de Tours, Laboratoire d'Informatique Ingénieur études et recherche, La Compagnie des mobilités 64, avenue Portalis bureau 202 37200 TOURS ☏ 06 26 94 94 71 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)
2011/6/30 Ab_fab gamma@gmail.com J'ai la même compréhension : ce sont des tuiles vectorielles, qui doivent être générées selon une stratégie optimisée en fonction de la demande pour les zones géographiques données. Mouais. Je voudrais voir comment sont réglés les grands objets dans ce système. Si un ou les deux nodes d'un way ne se trouvent pas sur la tuile par exemple - obligation de créer des noeuds virtuels aux limites ? Si on fait un way par tuile, comment on fusionne les données pour ne pas créer d'artefacts à l'affichage (par exemple un nom affiché sur chaque tuile) ? Comment gère-t-on les grandes surfaces côté serveur (forêts, lacs) ou côté client (lignes de côte pour l'océan) ? en utilisant les shapefiles de Mapnik ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Données ouverte sur les transports et plans de ville
Dans le magazine en ligne OWNI, Andréa Fradin a publié une description du projet Mapnificent réalisé par un Berlinois, Stefan Wehrmeyer. Dans les villes où les données sur le transport public ont été libérées, il peut réaliser des isochrones sur un fond de carte Google. Voi ici : http://www.mapnificent.net/ et montrer ce qui est accessible par transport public dans un temps donné. Il n'y a, apparemment, que les données de Rennes et de Bordeaux qui sont disponibles en France. http://www.mapnificent.net/rennes/#/?lat0=48.1117611lng0=-1.68026540053t0=15lat=48.1117611lng=-1.68026540053zoom=14 Par défaut, le délai est fixé à 15 minutes. Lire l'interview de S. Wehrmeyer : http://owni.fr/2011/06/13/vos-deplacements-a-la-carte/ Des idées pour avor ça sur OSM? Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)
C'est apparemment pris en compte à la génération des tuiles (noeuds aux limites) et pendant le rendu If a polygon or a line crosses a tile boundary, it should be cropped to only contain points that lie inside or on boundary of a tile, but Kothic JS will automatically hide edges of polygon which lie on tile boundaries. https://github.com/kothic/kothic-js/wiki/Tiles-format Les tuiles sont générées à partir d'une base Postgis, elle même remplie a l'aide d'osm2pgsql https://github.com/kothic/kothic-js/wiki/json_getter-setup Donc le processus n'est finalement pas si éloigné de la fabrication de tuiles images. Je comprends les problèmes potentiels que tu indiques, mais je n'ai pas vu de messages mettant en évidence ce genre de bugs dans le fil de discussion suivant : http://lists.openstreetmap.org/pipermail/mapcss/2011-June/000196.html Le 30 juin 2011 17:47, Pieren pier...@gmail.com a écrit : 2011/6/30 Ab_fab gamma@gmail.com J'ai la même compréhension : ce sont des tuiles vectorielles, qui doivent être générées selon une stratégie optimisée en fonction de la demande pour les zones géographiques données. Mouais. Je voudrais voir comment sont réglés les grands objets dans ce système. Si un ou les deux nodes d'un way ne se trouvent pas sur la tuile par exemple - obligation de créer des noeuds virtuels aux limites ? Si on fait un way par tuile, comment on fusionne les données pour ne pas créer d'artefacts à l'affichage (par exemple un nom affiché sur chaque tuile) ? Comment gère-t-on les grandes surfaces côté serveur (forêts, lacs) ou côté client (lignes de côte pour l'océan) ? en utilisant les shapefiles de Mapnik ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données ouverte sur les transports et plans de ville
Oui, mais cela existe déjà en fait, depuis plus d'un an ! http://lists.openstreetmap.org/pipermail/talk-fr/2010-June/022660.html http://blog.isokron.com/category/cartes-isochrones Ces cartes sont obtenues en temps réel en se servant des données OpenStreetMap http://www.openstreetmap.org/. http://www.rue89.com/2011/06/12/on-se-retrouve-ou-la-reponse-est-sur-la-carte-isokron-208972 Après des débuts très parisiens, ils ont aussi phosphoré sur Rennes à la suite de la liberation des données Le 30 juin 2011 18:05, Christian Rogel christian.ro...@club-internet.fr a écrit : Dans le magazine en ligne OWNI, Andréa Fradin a publié une description du projet Mapnificent réalisé par un Berlinois, Stefan Wehrmeyer. Dans les villes où les données sur le transport public ont été libérées, il peut réaliser des isochrones sur un fond de carte Google. Voi ici : http://www.mapnificent.net/ et montrer ce qui est accessible par transport public dans un temps donné. Il n'y a, apparemment, que les données de Rennes et de Bordeaux qui sont disponibles en France. http://www.mapnificent.net/**rennes/#/?lat0=48.1117611** lng0=-1.68026540053t0=15**lat=48.1117611lng=-1.** 68026540053zoom=14http://www.mapnificent.net/rennes/#/?lat0=48.1117611lng0=-1.68026540053t0=15lat=48.1117611lng=-1.68026540053zoom=14 Par défaut, le délai est fixé à 15 minutes. Lire l'interview de S. Wehrmeyer : http://owni.fr/2011/06/13/vos-**deplacements-a-la-carte/http://owni.fr/2011/06/13/vos-deplacements-a-la-carte/ Des idées pour avor ça sur OSM? Christian __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger les entrées de métro
Le 27 juin à 13:24 Pieren a écrit 2011/6/27 Vincent-Xavier JUMEL endymion+...@thetys-retz.net Par ailleurs, je mets en garde les personnes (j'en ai déjà rencontré) qui seraient tentées, même dans un but louable de cartographier les couloirs du métro. Cela me semble risquer. Oui ou les quais aussi. En souterrain, c'est du pifométrique qui en plus dérange fortement ceux qui éditent en surface (comme moi). Le tag d'entrée de métro, c'est railway=subway_entrance non ? En tout cas, c'est comme ça que j'en ai taggué un grand nombre (et non railway_entrance). Pardon, je viens de prendre le temps de revérifier, et tu avais raison. Ça correspond aux quelques unes que j'avais fait. Il reste encore beaucoup à faire dans ce domaine comme distinguer les bouches d'entrée, sortie, les deux, les escalators, la connexion aux autres voies pédestres, l'accessibilité, sens des escaliers, zones avec ou sans titres de transport (passages publics souterrains, etc... Une chose qui n'est visiblement pas faite, ou alors, c'est que j'ai mal compris quelque choses, c'est comment indiquer que telle subway_entrance permet d'accéder à telle railway_station ? Peut-être une relation pourrait résoudre ce problème ? -- Vincent-Xavier JUMEL GPG Id: 0x2E14CE70 http://thetys-retz.net Rejoignez les 5500 adhérents de l'April http://www.april.org/adherer Parinux, logiciel libre à Paris : http://www.parinux.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Association OpenStreetMap France !
Le 28/06/2011 19:56, RatZilla$ a écrit : Bonnes Nouvelles les ami[e]s, \o/ Certains contributeurs, m'ont relancé sur le montage de l'association. Je remonte donc les dernières avancées. merci pour ces infos et pour tout le boulot que tu as abattu. Au Charbon ;-) vi. Je serai (aussi) aux RMLL (à partir de dimanche soir). Une rencontre sur ce sujet pourrait être utile. Amitiés, -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
