Re: [OSM-talk-be] Geocoding met foute postcode's
The person that made this error has made several , at random I started checking his edits, things like numbers that are in the wrong key (addr:housename=537) http://www.openstreetmap.org/browse/node/864788506 Edited twice more, but user TAA didn't seem to have fixed that mistake. I find it more and more disturbing that people are just creating more work for others by delivering low quality or careless work. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Geocoding met foute postcode's
On 2013-07-23 19:29, Kurt Roeckx wrote: So I asked on IRC in #osm-nominatim and got as answer that it should work but currently doesn't work. tx for the notice. I'm cleaning up the whole postal code information as we speak, plenty of errors: - city in addr:postcode - reversing city with postcode - postal codes prepended with B or B- or Bspace - postcode + city in addr:postcode - housenumbers in as the postcode I'm looking straight into the placex table from nominatim to see what crap is in there, and then use Overpass to extract the data into JOSM so I can edit and fix. Almost done with the current mess. My edit history reflects this mess. I think half of it is due to not paying enough attention to what josm autocompletes while entering a new key. I hope this will sort out the Belgium quality of postal codes as it stands now. Whatever the future will bring us, atleast the present is correct. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] About the changes on the OSM.org site
For those of you that do not follow e.g. OSM-talk: here is a post on the recent and upcoming changes on the openstreetmap.orgwebsite http://www.mapbox.com/osmdev/2013/07/19/implementing-osm-vision/ I hope some of you find this helpful regards m ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] sharealike trigger
From: John Bazik [mailto:m...@johnbazik.com] Subject: Re: [OSM-legal-talk] sharealike trigger On Mon, Jul 22, 2013 at 10:46:30PM -0700, Paul Norman wrote: What do you mean by fields? I mean columns in RDBMS tables. I don't believe you can make any general comment about columns in a RDBMS table. For example, you could use a RDBMS as a k-v store and store both OSM data and a completely unrelated set of photos in it. On the other hand, you could use a schema which is in 3NF and then the OSM database is over many different tables. As a practical matter, most data consumers probably want an un-normalized table because they are only reading. I had thought about saying something about tables in un-normalized forms, but I'm not sure if it's general enough. I still believe it's best to avoid talking about a technology-specific way of storing databases, particularly when the OSM database comes as an XML file, which is closer to a set of flat text files than an RDBMS in many ways. I also found when I shifted my thinking to avoid using any terms from a particular way of storing databases the database directive became clearer. One description for the OSM map database (planet.osm) is a database of georeferenced shapes (including points) with associated data (what the shape represents) and meta-data (time edited, user edited by, etc). I am very And OSM excludes *some* of that meta-data from what it considers to be derived - fields like user edited by. I'm not sure what you mean. The meta-data included in planet.osm is part of the OSM map database, although most consumers drop the user-related metadata because it unnecessary for most applications. In RDBMS terms, might one expect to use a SELECT to produce a derivative database, excluding non-derivative data? Well, in RDBMS terms SELECT produces a rowset which is closer to a table, not a database. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] sharealike trigger
On Tue, Jul 23, 2013 at 11:43:57AM -0700, Paul Norman wrote: in a RDBMS table. For example, you could use a RDBMS as a k-v store and store both OSM data and a completely unrelated set of photos in it. On the other hand, you could use a schema which I guess I was just trying to make the (trivial?) point that data coexistant in an RDBMS or even within a table therein has no bearing on whether it is derivative of OSM data. I still believe it's best to avoid talking about a technology-specific way of storing databases, particularly when the OSM database comes as an XML file, which is closer to a set of flat text files than an RDBMS in many ways. Well, if most consumers of your data are like me, technology-specific references are helpful. I'm not sure what you mean. The meta-data included in planet.osm is part of the OSM map database, although most consumers drop the user-related metadata because it unnecessary for most applications. I thought that OSM does not consider the user data derivative and does not distribute it (or, is not compelled to, by the ODBL). Well, in RDBMS terms SELECT produces a rowset which is closer to a table, not a database. My point was that select produces a rowset that may exclude columns. John ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Build your own osm.org (was Re: New technology ...)
Main page UI change does not changes how does embedded osm map looks if you include it using either leaflet, openlayers JS library and that just single js file + css in any web page and you are free to customize it to look how you or your client wants and that does not requires to need for servers as tiles can still be displayed from osm servers. 2013/7/22 Lester Caine les...@lsces.co.uk Lauris Bukšis-Haberkorns wrote: If you are so confused with how map works it not much of a work to use any JavaScript library to embed OSM map in any page to look and act how you like it. I might be missing something but I don't quite don't understand where is the problem here? Advertising OSM ... Over the last year I've slowly moved a number of legacy sites from using google location maps to simple 'OSM' ones. With a link to the 'large map' and a link to yours or osrm for routing. With a view to providing my own routing page at some point. Yes I can switch back to my own servers, but that will take time, and that is the one commodity everybody is saying we don't have. Currently 'yours' seems to have lost the scale navigation altogether? My own copy still has the older style bars but for some reason is no longer 'routing' :( OSRM actually fits better with the new style, but will not even display properly on the android tablet, which is why I was back with yours ... there was a nicely functional suite of tools ... today some of the cross working is different ... and I'd missed that originally when the new style appeared! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Build your own osm.org (was Re: New technology ...)
Lauris Bukšis-Haberkorns wrote: Main page UI change does not changes how does embedded osm map looks if you include it using either leaflet, openlayers JS library and that just single js file + css in any web page and you are free to customize it to look how you or your client wants and that does not requires to need for servers as tiles can still be displayed from osm servers. Lauris I have not doubt what you are saying is true, but currently the style of all my embedded maps has changed from the old style to the new style. It would be a lot more helpful if you could point me to some documentation that will provide an 'old' .css file that I can access so I don't have to spend hours trying to find out how to change it. Since the embedded map ideally needs to match the map which opens when you select 'large map' or 'directions', then I'm probably NOW looking to move the +/- buttons on the embedded map from the left to the right so they match the main page, and then restyle the osrm router to have them in the same position as well. Everything bouncing around the screen is the current problem, when they were all top left ... by default. But this is all extra work that takes a valuable resource to sort out ... time ... and it would be nice if those who made the changes and understand how to do so passed it on so we can change it back if we want? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Another OSM use without attribution (unusual rendering)
On Mon, Jul 22, 2013 at 01:22:50PM -0400, AJ Ashton wrote: On Mon, Jul 22, 2013 at 1:10 PM, Simon Hewison si...@zymurgy.org wrote: Okay, so it's mapbox, any idea how often they update their data? It seems the data is over 12 months old. Not the best way to showcase how quick it is to update the maps they are rending. We update every 5 minutes or so*, what makes you say this is over 12 months old? *Except for coastlines, admin boundaries, and admin labels. Then why does way 164845193 (Old Street Magistrates Court (closed)) have an old label? It is because your renderer is removing superflous words like (closed) ? -- Simon Hewison ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Is there some lag in the backend data?
I made some changes this morning [1], most notably added some maxspeed tags. Now it's over 3 hours later and I download the same area again in JOSM and my changes are not visible. But when I look at the history of the items (e.g. way 6701036), the change is there. The history says highway=residential and maxspeed=30. JOSM does not show that on the item. I also can not open the changeset in my browser, it is trying to load now for 5 minutes. [1] http://www.openstreetmap.org/browse/changeset/17057508 Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Is there some lag in the backend data?
On 23 Jul 2013, at 10:27, Maarten Deen md...@xs4all.nl wrote: I made some changes this morning [1], most notably added some maxspeed tags. Now it's over 3 hours later and I download the same area again in JOSM and my changes are not visible. But when I look at the history of the items (e.g. way 6701036), the change is there. The history says highway=residential and maxspeed=30. JOSM does not show that on the item. I also can not open the changeset in my browser, it is trying to load now for 5 minutes. [1] http://www.openstreetmap.org/browse/changeset/17057508 This url opened straight away for me. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Is there some lag in the backend data?
On 2013-07-23 11:43, Maarten Deen wrote: On 2013-07-23 11:36, Shaun McDonald wrote: On 23 Jul 2013, at 10:27, Maarten Deen md...@xs4all.nl wrote: I made some changes this morning [1], most notably added some maxspeed tags. Now it's over 3 hours later and I download the same area again in JOSM and my changes are not visible. But when I look at the history of the items (e.g. way 6701036), the change is there. The history says highway=residential and maxspeed=30. JOSM does not show that on the item. I also can not open the changeset in my browser, it is trying to load now for 5 minutes. [1] http://www.openstreetmap.org/browse/changeset/17057508 This url opened straight away for me. It does now for me too, but when I download the area in JOSM I still get old data, with the newer data shown in the history screen. I had a thought and looked at the close open changesets in JOSM. JOSM told me this changeset was not closed even though the changeset screen said (and still does): Aangemaakt op: din 23 jul 2013 06:07:37 UTC Gesloten op: din 23 jul 2013 06:07:43 UTC I closed it and now it is ok. Glitch in JOSM. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Is there some lag in the backend data?
Maarten Deen writes: I had a thought and looked at the close open changesets in JOSM. JOSM told me this changeset was not closed even though the changeset screen said (and still does): Aangemaakt op: din 23 jul 2013 06:07:37 UTC Gesloten op: din 23 jul 2013 06:07:43 UTC I closed it and now it is ok. Glitch in JOSM. For me this sounds more like a replication problem. Data is available immediately. It's not related to closing a changeset. Is the API delivering /map call responses from the main database or from a read-only replication? If its the later than JOSM might need to be extended to evaluate a timestamp to detect outdated responses. Stephan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] (no subject)
___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Another OSM use without attribution (unusual rendering)
On Tue, Jul 23, 2013 at 4:16 AM, Simon Hewison si...@zymurgy.org wrote: It is because your renderer is removing superflous words like (closed) ? Yes, that's what's going on. We've made this decision because in most cases, text inside parentheses is either a translation, which we handle separately, or not actually part of the name, as in this case. Our render used to respect the disused tag, but this feature got lost in some reshuffling. We have updates in the works that will re-add it make cases like this more clear, but still avoid the extra data tacked onto the label. -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Working toward a vision for OSM
Hey all, John Firebaugh just wrote up a post that's useful in light of the conversations we've been having about changes to OSM and how they're organized: http://www.mapbox.com/osmdev/2013/07/19/implementing-osm-vision/ Hopefully this story from the video to wireframes, to thought, and finally to the actual code and pull requests we're working on, will help to clarify what we[1]'re interested in working on and why. Tom [1]: we = John, Saman, Alex, myself ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bringing new life to the OSM.org front page
On Sun, Jul 21, 2013 at 4:16 AM, Rob Nickerson rob.j.nicker...@gmail.com wrote: Finally, a few other things to note: * With over 1 million registered users it is impossible to please everyone. Please put things into perspective before replying with negative comments. Also consideration of the amount of development time is always appreciated. * OSM has numerous communication channels (too many maybe). Where would you stop if it was decided to post announcements to the community. Furthermore as the OSM Foundation did not ask for permission to send email to registered users they cannot therefore push notifications to all users (rather users will need to read the communication channels that interest them). My suggestion: when big, highly visible changes are coming, that non-dev community members might have an interest in, consider just dropping a line to talk@ like this: Hi, we're working on some cool new map controls for the front page. Check out the discussion here: link. (I don't think it's practical for non-developers to lurk on development mailing lists on the off-chance that something interesting will pop up.) Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Upgraded map controls
On Jul 22, 2013, at 7:21 AM, Simon Poole wrote: Am 21.07.2013 20:18, schrieb Michal Migurski: Supporting official venues for orderly change is what the board should be doing, but is not. I would support the creation and use of a proposal/vote/implementation process for the community, even if the first proposal is just be it resolved that Mapbox accepts responsibility for the visual design of OSM.org. I would find it very very difficult to subject superficial design changes to a popular vote, these are matters of personal taste and work flow and it is very unlikely that we could reach any kind of consensus within a reasonable time frame, wit this thread. What would be nice if we could get to a state where changing the visual appearance of the main site would not be such a heavy weight task (at least not for the devs) and could happen substantially more often than once in a decade. It's a heavyweight task because there's no higher-level process to guide it, other than the one brought by volunteers. No strategy or goals from the foundation that would provide some rationale for a change and no decisions that would delegate someone to follow through on those goals. Bikeshedding is rarely a failure on the part of the bike shedders, more often a failure of strategy and leadership. The workings of our front page are most definitely not a matter of personal taste! Now high level goals and to a certain point functionality is something that, IMHO, is worth discussing with a large group, and we have ongoing discussions that cover exactly such territory. Besides what has been written here, there is a larger one on the German list about the potential gamification of OSM which shows that such a step is not simply a design question and definitely needs more community consensus if it should be seriously considered for implementation. No kidding! Any consensus from the Germans? -mike. michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] New tile rendering server (Experimental)
Sorry I don't really understand this, how will this affect me and what I see? Thanks David - Original message - From: Grant Slater [1]openstreet...@firefishy.com To: talk-au [2]talk-au@openstreetmap.org, [3]nzopen...@googlegroups.com Subject: [talk-au] New tile rendering server (Experimental) Date: Mon, 22 Jul 2013 18:18:49 +0100 Hi Oceania (Talk-AU and nzopengis), I have just switched the default OpenStreetMap.org “Mapnik style” map tiles for tile.openstreetmap.org in the Oceania region across to our new rendering server. The new rendering server has been tested and is now ready for production. We’re migrating traffic over region-by-region and the Oceania region is the first to go live. The countries in the Oceania region affected are those with dark green links on this map: [4]http://dns.openstreetmap.org/tile.openstreetmap.org.html In addition to new hardware, the rendering server also uses the new “openstreetmap-carto” stylesheets. These are a complete re-write of the XML stylesheets to use CartoCSS, making them easier for our cartographers to work with. Andy Allan’s great talk at State of the Map US described the reason for the stylesheet re-write: [5]http://stateofthemap.us/saturday.html#schedule/saturday/putting-the- carto-into-openstreetmap-cartography The map tiles will be slightly slower at medium-high zooms while the server builds up its cache. The style is designed to look the same as the current XML stylesheet. The “openstreetmap-carto” stylesheet is maintained here: [6]https://github.com/gravitystorm/openstreetmap-carto Big Thank you to #osm-dev for helping draft this announcement. Kind regards Grant Slater Part of the OSM Sysadmin Team References 1. mailto:openstreet...@firefishy.com 2. mailto:talk-au@openstreetmap.org 3. mailto:nzopen...@googlegroups.com 4. http://dns.openstreetmap.org/tile.openstreetmap.org.html 5. http://stateofthemap.us/saturday.html#schedule/saturday/putting-the-carto-into-openstreetmap-cartography 6. https://github.com/gravitystorm/openstreetmap-carto ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] New tile rendering server (Experimental)
On 23 July 2013 15:08, David Clark dbcl...@fastmail.com.au wrote: Sorry I don't really understand this, how will this affect me and what I see? Hopefully you shouldn't see any difference. :-) It is a large behind the scenes change on how we produce the default map tiles (view) for OpenStreetMap.org The old map stylesheet was a mass of difficult to understand XML. The new map stylesheet is completely re-written in a much cleaner CartoCSS syntax. Easier to maintain and improve, it is also easier to customise it for other projects. Andy Allan's talk explains it better than I could to: http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013/video/68093876 We have also changed the server infrastructure used for rendering the map tiles. The old server was becoming very complicated to maintain and administer due to the many layers of complexity, code, and undocumented hacks built up over time. The new server is setup using an automated devops system (opscode chef). The chef cookbook we wrote is here: http://git.openstreetmap.org/chef.git/tree/HEAD:/cookbooks/tile Regards Grant ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-br] Nova página inicial do OpenStreetMap
Na verdade essa página não irá substituir a homepage do openstreetmap.org. Será apenas uma página para a qual haverá um link no email que os usuários recebem quando se cadastram no site e também a página para a qual serviços que usam os dados do OSM (como foursquare e flickr) irão linkar quando os usuários relatarem problemas no mapa. The welcome page is the landing page for newly confirmed accounts as well as a place where third party data consumers like Foursquare, MapBox, or Craigslist can direct users who have spotted a problem with the map and want to get started fixing it. Penso que a página inicial do OpenStreetMap continuará a mesma. abçs, wille On 23-07-2013 17:56, Vitor George wrote: Pessoal, O site do OpenStreetMap está passando por algumas mudanças, e que usou recentemente deve ter notado algumas mudança de design. Está acontecendo agora uma discussão sobre uma nova página inicial do OpenStreetMap. Esta já não terá um mapa, que ficará em segundo plano. Quem quiser participar da discussão, veja: https://github.com/openstreetmap/openstreetmap-website/pull/338 Abs, Vitor ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
TMC scheint mind. innerhalb OSM tot zu sein. Vgl. [1]. Und so oder so, scheint mir TMC doch reichlich kompliziert, unzugänglich und daher ungeeignet für diese Zwecke hier. Oder kannst du mir ein Beispiel geben, wie man die Neustadtstrasse, Landshut, mittels TMC für nächstes Wochenende sperren würde? LG, Stefan Hallo Stefan, TMC ist innerhalb OSM tot, weil es für den Normalmapper zu kompliziert und schwer nachvollziehbar ist. Solche komplexen Sachen, die nur von wenigen Experten so richtig verstanden werden, gehören von außerhalb integriert, ohne allzugroße Eingriffe in den OSM-Datenbestand. Blicken wir lieber in Richtung TPEG [1], dem TMC-Nachfolger für das Digitalradio. Dises System ist unabhängig vom Kartenmaterial und auch vom Übertragungskanal. Die ARD-Rundfunkanstalten stehen kurz vor dem Beta-Test und stellen dann auch die Meldungen z.B. als RSS-Feed zur Verfügung. Mit TPEG-Technologie dürfte es kein Problem sein, einzelne Straßen oder Parkplätze kurzfristig zu sperren, besetzte Parkhäuser oder auch die Preise an Tankstellen anzuzeigen. Grüße Joachim [1] http://de.wikipedia.org/wiki/TPEG ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
On 23/lug/2013, at 09:30, Joachim Kast osm...@dd1gj.de wrote: TMC ist innerhalb OSM tot, weil es für den Normalmapper zu kompliziert und schwer nachvollziehbar ist. Wenn ich das richtig in Erinnerung habe war das erste Schema komplett umständlich und unnötig kompliziert sowie kaum menschenlesbar*. Diese erste Schema ist das, was anfangs umgesetzt wurde, aber aufgrund der Unverständlichkeit nicht großartig gepflegt oder gewartet wurde, während der zweite Vorschlag ganz OK und relativ simpel war, aber der vorschlagenden Firma (?) irgendwie die Luft ausgegangen ist (?), so dass das bisher nicht umgesetzt wurde. http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme#Proposal:_Neues_Tagging-Schema_f.C3.BCr_TMC-Daten * so wurde im ursprünglichen Schema z.B. TMC:cid_58:tabcd_1 jedem einzelnen Objekttag vorangestellt, was einfach bedeutet Deutschland, erste (und einzige) Tabelle. Dadurch wurden die Tags kryptisch und lang ohne das etwas gewonnen worden wäre. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Joachim Vielen Dank für den Hinweis auf TPEG. Das kannte ich noch nicht. Ich befürchte aber, dass TPEG auch nicht viel einfacher ist als TMC. Die v.a. weil es sich - wie TMC - auf effiziente Übermittlung über Übertragungskanäle konzentriert. Hingegen gibt der Abschnitt Aufbau einer RTM Nachricht undder nachfolgende (aus deinem Link [1]) interessante Hinweise, um die Vollständigkeit der hier besprochenen Schemata zu prüfen. In die richtige Richtung geht hingegen: Eckhart's Hinweis Am 22. Juli 2013 08:07 schrieb Eckhart Wörner ewoer...@kde.org: ... • gesperrte Straßen: http://wiki.openstreetmap.org/wiki/Conditional_restrictions Ich kläre nun ab, inwiefern das meinen Vorschlag vom 22.07.2013, 22:36 +0200 ersetzt. LG, Stefan Am 23. Juli 2013 09:30 schrieb Joachim Kast osm...@dd1gj.de: TMC scheint mind. innerhalb OSM tot zu sein. Vgl. [1]. Und so oder so, scheint mir TMC doch reichlich kompliziert, unzugänglich und daher ungeeignet für diese Zwecke hier. Oder kannst du mir ein Beispiel geben, wie man die Neustadtstrasse, Landshut, mittels TMC für nächstes Wochenende sperren würde? LG, Stefan Hallo Stefan, TMC ist innerhalb OSM tot, weil es für den Normalmapper zu kompliziert und schwer nachvollziehbar ist. Solche komplexen Sachen, die nur von wenigen Experten so richtig verstanden werden, gehören von außerhalb integriert, ohne allzugroße Eingriffe in den OSM-Datenbestand. Blicken wir lieber in Richtung TPEG [1], dem TMC-Nachfolger für das Digitalradio. Dises System ist unabhängig vom Kartenmaterial und auch vom Übertragungskanal. Die ARD-Rundfunkanstalten stehen kurz vor dem Beta-Test und stellen dann auch die Meldungen z.B. als RSS-Feed zur Verfügung. Mit TPEG-Technologie dürfte es kein Problem sein, einzelne Straßen oder Parkplätze kurzfristig zu sperren, besetzte Parkhäuser oder auch die Preise an Tankstellen anzuzeigen. Grüße Joachim [1] http://de.wikipedia.org/wiki/TPEG ___ 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] Einführung eines neuen Tags (globaleID)
Am Mon, 22 Jul 2013 16:43:25 +0200 schrieb fly lowfligh...@googlemail.com: Hat sich das denn jetzt aufgeklärt oder geht das weiter ? taoxue hat vorhin mit mir Kontakt aufgenommen und ich habe dazu geraten, die Sache hier in der Liste zu besprechen. Ich denke, dass wir akzeptable Lösungen finden können, aber die Sachen müssen jetzt in der Liste geklärt werden. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Masi Finde deine Überlegungen interessant, v.a. der Teil Am 23. Juli 2013 00:13 schrieb Masi Master masi-mas...@gmx.de: ... Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von Routern nicht mehr berücksichtigt werden und aufgrund des Datums können alle überfälligen Baustellen aus der Datenbank gelöscht werden. Ok. Aber warum zwingend mit Relationen? Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch, versteht sich) Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags. Stimmt. Die langen Tags sind problematisch. Aber immer noch das kleinere Übel als Tags, die voneinander abhängig sind. Könnte man z.B. eine temporäre Sperrrung nicht so erfassen - gemäss Eckharts Hinweis auf das bereits existierende [1]? motor_vehicle:conditional=no @ (2014-07-27..2014-07-28) LG, Stefan [1] http://wiki.openstreetmap.org/wiki/Conditional_restrictions Am 23. Juli 2013 00:13 schrieb Masi Master masi-mas...@gmx.de: Am 22.07.2013, 20:25 Uhr, schrieb Frank fr...@fotodrachen.de: Am 22.07.2013 08:07, schrieb Eckhart Wörner: Hallo Alexander, Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner: Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche neuen Erkenntnisse? • gesperrte Straßen: http://wiki.openstreetmap.org/wiki/Conditional_restrictions • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen • zusätzliche amenities: opening_hours? Eckhart Ich denke, es ging Alexander eher um die Frage, ob man die temporären Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen sollte. Es wäre zwar nett, wenn die Karte auch während des Ausnahmezustandes Stadtfest aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich. Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend eingerichtet wurden. Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie. Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann wochenlang mit diesen Sonder-Anpassungen herum. Auch andere Auszüge werden nicht täglich aktualisiert. Ich denke, die OSM-Datenbank sollte nur den Normalzustand wiedergeben und nicht den temporären Ausnahmezustand. Dies kann evtl. auf einer Webseite oder in Flyern durch Overlays dargestellt werden. Das Problem ist doch, dass das zeitliche Sperren nicht funktioniert und zu lange in der Datenbank bestehen bleibt (oft wird die Sperrung vergessen aus OSM herauszunehmen) Angenommen eine Straße hat das Tagging motorcycle=no + mofa=yes. Nun kommt einer und will die Straße mit access=no sperren. Funktioniert natürlich nicht für Mofas und alle anderen (vorher überflüssigen) *=yes Tags werden zum Verhängnis. date_on date_off geht genausowenig, da nicht klar ist, auf welche Tags es sich bezieht. Eine mögliche Lösung ist eine Baustellen- oder Sperrungs-Relation, die alle access tags der Wege nicht beachtet und mit access=no überschreibt. Gleichzeitig kann die Relation weitere access tags aufnehmen, zB Freigabe für Fußgänger und Radfahrer, oder Freigabe für Anwohner. Bei der Relation MUSS aber mit angegeben werden, von wann - und noch wichtiger - BIS wann gesperrt ist. Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von Routern nicht mehr berücksichtigt werden und aufgrund des Datums können alle überfälligen Baustellen aus der Datenbank gelöscht werden. Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch, versteht sich) Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags. Falls das Enddatum unbekannt ist, sollte/muss eine Schätzung angegeben werden, damit die Mapper nach der Frist die Baustelle nochmal überprüfen/aktualisieren können. So, das war meine bisherige Überlegung. Aber vielleicht hat jemand noch einen besseren Vorschlag? ___ 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] Wasserturm verschwunden
dieterdreist wrote Wo? Bisher hieß es immer, das ist zwar eine Abweichung von üblichen GIS Standards, aber in osm dürfen sie das, weil es bequemer für den Mapper ist. Ja, leider :( Es ist ja historisch bedingt und mag für den Mapper bequem sein, aber für jemanden, den mit GIS an die Auswertung drangeht, ist es ein Graus. Bin sowohl Mapper als auch Auswerter und schlage mich permanent damit herum, nicht-GIS-konforme Konstrukte so hinzubiegen (*), dass GIS-Software damit klar kommt. Aus diesem Grunde begrüße ich jede Aktion in Richtung GIS Standard und hoffe sehr auf api 0.7, falls die überhaupt mal kommen sollte. Genaugenommen ist die Datenstruktur von OSM ein propertiäres System - und das in einer Open World. Wir sind zwar Open für jedermann und mächtig stolz drauf, nur kann die Open World nicht viel damit anfangen. Gruss walter *) natürlich nicht in der DB sondernmit - unnötigen und teilweise sehr komplexen - Konvertierungen im Rahmen der Auswertungen. Derzeit suche ich eine Unverträglichkeit bei Multipolygonen, die meinen Postgresql/PostGIS-Server *abrauchen* läßt (Server Restart!), wenn er bestimmte MP fressen soll. :( - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Wasserturm-verschwunden-tp5770618p5771037.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft auf OSM zu setzen. Das betrifft folgende Produkte · Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern beiliegen und die an den Haltestellen aushängen sollen aus den OSM Daten errechnet und im VRR Layout dargestellt werden. · Die Haltestellenumgebungspläne, die von einigen Betrieben erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen aus OSM Daten erzeugt werden. · Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen aus OSM Daten berechnet werden · Die interaktiven Karten der VRR App, dieselben wie die aus efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca. 1.000.000 mal heruntergeladen) · Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten (dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten gezeichnet werden (siehe auchefa.vrr.de und die Apps) · Die Fußwege zu den Haltepunkten und bis zum Gleis der Schienenverkehre sollen auf OSM Daten geroutet werden · Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen · Das Fußwegrouting soll barrierefreie Wege suchen können (wird weiter unter erklärt) Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem auch der Qualität und der Detailreichtum der OSM Daten hat den VRR begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere Datenmaterialien. Das Datenmaterial, das wir in OSM vorfinden hat vor allem bezüglich der Wege (Straßen und Schienenwege) aus ausgezeichnete Qualität. Einige Daten sind allerdings noch unvollständig für unsere Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam mit der OSM Gemeinde. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das? Gehen wir von drei typischen Benutzern aus: Nutzer 1 ist Student, Pendler und in Turnschuhen unterwegs. Er kommt immer knapp vor der Zugabfahrt. Er geht schnellen Schrittes durch den Bahnhof und nimmt die Treppen hinauf zum Bahnsteig, damit er nirgends warten muss. Nutzer 2 ist der Reisende mit Koffer, oder die/der Frau/Mann mit Kinderwagen. Der Nutzer kann nur mit großer Mühe die Treppen nutzen und sucht Wege über Rolltreppen zum Bahnsteig. Nutzer 3 kommt im Rollstuhl. Er ist auf Aufzüge und Rampen angewiesen um zum Bahnsteig zu kommen, er braucht entsprechende Wege. Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen von Plattformen gefunden: · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner Platz/Hohe Straße) · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist, eignet sich bei Seitenbahnsteigen (Beispiel, ….) · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München Ost) Keine der drei Modellierungsarten ist unsere Erfindung, statt der gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten (Multipolygonen), das ist aber noch komplizierter und das haben wir noch nirgends gesehen. Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil,
Re: [Talk-de] Wasserturm verschwunden
Am 23. Juli 2013 11:27 schrieb Walter Nordmann pil...@hotmail.com: Es ist ja historisch bedingt und mag für den Mapper bequem sein, aber für jemanden, den mit GIS an die Auswertung drangeht, ist es ein Graus. Bin sowohl Mapper als auch Auswerter und schlage mich permanent damit herum, nicht-GIS-konforme Konstrukte so hinzubiegen (*), dass GIS-Software damit klar kommt. in diesem Fall muss der Konverter eben einen zusätzlichen inner Way schaffen, der die beiden sich berührenden Ways ersetzt. Das ist schon aufwendiger als wenn man das nicht machen muss, aber zumindest bisher war es so, dass das halt so ist in OSM. Wann das geändert wurde und von wem weiss ich nicht, ggf. ist das ein Fall von Wiki-Fiddling? Genaugenommen ist die Datenstruktur von OSM ein propertiäres System - und das in einer Open World. Wir sind zwar Open für jedermann und mächtig stolz drauf, nur kann die Open World nicht viel damit anfangen. gibt ja Möglichkeiten, zwischen den Systemen zu konvertieren. proprietäres System lasse ich nicht gelten für OSM, egal wie genau man es nimmt ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar
Moin Dietmar, Die grafischen Auswertungen funktionieren scheinbar nicht mehr: http://regio-osm.de/hausnummerauswertung/grafikdarstellung/anzeige.html?ort=K%C3%B6ln Die *.osm Datei kann nicht geladen werden, für München das selbe. Grüße, Malte ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo, Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Tracy (taoxue) Inhaltlich kann und will ich nichts beitragen, aber aus meiner Sicht fällt das Eintragen dieser Daten unter die Import Guidelines [1]. Deshalb, aber auch wenn man das nicht so sieht, wäre es sinnvoll, die Änderungen an der OSM-Datenbank unter einem (oder mehreren) dafür vorgesehenen Account zu machen, dessen Bezeichnung zum Ausdruck bringt, worum es geht, mit einer kurzen Beschreibung des Projekts in der Profilbeschreibung und ggf. einer Wiki-Seite. Das würde Mappern, die auf eure Changes stoßen, ungemein helfen und auch manche etwas ungehalten wirkende Beiträge auf der Liste verhindern. Gruß Rainer [1] http://wiki.openstreetmap.org/wiki/Import/Guidelines ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar
Hallo Malte, jetzt gehen sie wieder. Ich hatte gestern abend und heute vormittag neue Auswertungen durchgeführt und die Dateinamen in falsche Umlautschreibweise abgelegt, derzeit gehen Aktualisierungen noch nicht automatisch. Viele Grüße Dietmar Am 23.07.2013 11:59, schrieb Malte Blättermann: Moin Dietmar, Die grafischen Auswertungen funktionieren scheinbar nicht mehr: http://regio-osm.de/hausnummerauswertung/grafikdarstellung/anzeige.html?ort=K%C3%B6ln Die *.osm Datei kann nicht geladen werden, für München das selbe. Grüße, Malte ___ 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] Wasserturm verschwunden
dieterdreist wrote gibt ja Möglichkeiten, zwischen den Systemen zu konvertieren. proprietäres System lasse ich nicht gelten für OSM, egal wie genau man es nimmt ;-) Klar gib es Möglichkeiten - ich mache das ja auch, damit ich nachher z.B. mit QGIS was mit dem Zeug anfangen kann. (*) Das klappt aber eigentlich nur, da OSM-ler Insiderwissen haben und die Datenstrukturen beherrschen. Außenstehende haben da erhebliche Probleme. Und das bezeichne ich nun mal als Propertiäres System. Selbst MS hat inzwischen eingesehen, dass sowas wie das Open-Document-Format Sinn macht um sich der Welt zu öffnen. Gruss walter *) Ich nutze das Snapshot-/Osmosis-Schema der DB und kann/will auf die zum Rendern optimierten Vorarbeiten von osm2pgsql gerne verzichten. ps: Der Vergleich hinkt vielleicht ein wenig: Alle bauen Autos mit 4 Rädern - OSM-Autos haben 5 ;) - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Wasserturm-verschwunden-tp5770618p5771052.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar
Hallo Dietmar, sehe ich mir die Berliner Str. in Westhoven an, sagt die grafische Auswertung, dass 251 Hausnr. fehlen. Soviele Häuser gibt es da gar nicht. Kann es sein, dass die Hausnummer von einer anderen Berliner Str. in Köln kommen? Viele Grüße Johannes Am 23. Juli 2013 12:13 schrieb Dietmar ostr...@diesei.de: Hallo Malte, jetzt gehen sie wieder. Ich hatte gestern abend und heute vormittag neue Auswertungen durchgeführt und die Dateinamen in falsche Umlautschreibweise abgelegt, derzeit gehen Aktualisierungen noch nicht automatisch. Viele Grüße Dietmar Am 23.07.2013 11:59, schrieb Malte Blättermann: Moin Dietmar, Die grafischen Auswertungen funktionieren scheinbar nicht mehr: http://regio-osm.de/**hausnummerauswertung/**grafikdarstellung/anzeige.* *html?ort=K%C3%B6lnhttp://regio-osm.de/hausnummerauswertung/grafikdarstellung/anzeige.html?ort=K%C3%B6ln Die *.osm Datei kann nicht geladen werden, für München das selbe. Grüße, Malte __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Tracy, Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Das ist super ;) [...] Einige Daten sind allerdings noch unvollständig für unsere Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam mit der OSM Gemeinde. Das klingt gut. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Das klingt gut - aber nach Import, deshalb bitte die Import-Richtlinien berücksichtigen, wenn ihr nicht jede Haltestelle selbst kontrolliert dabei. Eine Alternative ist oft, die Daten öffentlich und für die Nutzung freigegeben zu hinterlegen, damit man verteilt die Haltestellen anhand dessen überprüfen kann. [...] Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Fast richtig. Ein Aufzug muss nicht zwingend ein way sein, um darauf route zu können. Beispiel: .x-' .x und ' seien Nodes, und jeweils dazwiscchen ways. x sei ein Aufzug und als solcher getagged (auf einem Node. trägt außerdem level=0, x trägt level=1 (was jeweils das Stockwerk angibt). Das Routing mit Berücksichtigung des Aufzugs ist hier problemlos möglich. Ebene Wege, Treppen, Rolltreppen und Rampen sind üblicherweise ways in OSM, Aufzüge aber nicht, weil sie kaum eine horizontale Ausdehnung haben. Technisch ist das aber kein Problem auch im Routing zu berücksichtigen. Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen von Plattformen gefunden: · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner Platz/Hohe Straße) stimmt, und sollte für euch kein Problem darstellen. · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist, eignet sich bei Seitenbahnsteigen (Beispiel, ….) auch das sollte kein Problem sein zu nutzen. · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München Ost) Falsch: Wieso sollte das Splitten notwendig sein? Die Plattform ist die von den Gleisen (z.B.) 2 und 3. Die linke Seite bietet den Zustieg zu Gleis 2, die rechte zu Gleis 3. Es bleibt aber erstmal trotzdem ein Bahnsteig. Wieso man diesen horizontal aufsplitten muss, verstehe ich nicht. Wenn ich zu GLEIS (!) 2 route (da fährt der Zug ab), dann route ich (so machen das bei Adressen auch alle gängigen Router) zum nächsten Punkt, der erreichbar ist. Das ist in diesem Fall der Bahnsteig 2/3, und da die linke Seite. Wo ist das Problem? Warum muss dafür der Bahnsteig gesplittet werden? und vor allem: Warum in den Rohdaten? Keine der drei Modellierungsarten ist unsere Erfindung, statt der gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten (Multipolygonen), das ist aber noch komplizierter und das haben wir noch nirgends gesehen. Ich find auch kein Beispiel; logisch wäre es aber meines Erachtens schon, und es würde mit Multipolygonen auf ein etabliertes OSM-Schema zurückgreifen, ohne dass neue Erfindungen mit falschen Daten gemacht werden müssten. Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil, dass man in der Mitte Aussparungen lassen kann. In diesen Aussparungen können dann Treppen, Rolltreppen oder Aufzüge münden, die meist aus dem Fußgängertunnel kommen. Damit wir wissen, welche Teile zu einer Plattform gehören fassen wir diese Teile in einer Relation zusammen. Also trennt ihr erst um dann wieder per Relation zu verbinden... Selbst wenn ihr trennen müsstet (was ich bezweifle), wäre die Relation unnötig, denn die lässt sich einfach aus der Geometrie herleiten (die beiden Bahnsteige sind miteinander verbunden über eine gemeinsame Kante). Meine Empfehlung (darf gerne von anderen noch kommentiert werden) wäre: Eine Plattform ist eine Plattform und kein Gleis. Eine Plattform gehört z.B. zu zwei, manchmal auch zu drei oder mehr Gleisen, und das ist erstmal gar kein Problem. Ein Gleis ist ein Gleis und hat eine Nummer. Wenn ein Zug auf Gleis 2
[Talk-de] Tag designation (war: Einführung eines neuen Tags (globaleID))
Tracy Kasperczyk writes: Objekt: Tunnel (Type: Fläche) - designation = Unterführung Dieser Tag ist ganz sicher falsch. Es gibt wohl vermehrt im deutschsprachigen Raum Fälle wo das mit description verwechselt wurde. Designation bezieht sich vor allem auf UK Wegerecht. Siehe auch das Wiki. http://wiki.openstreetmap.org/wiki/DE:Key:designation Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo, da habt ihr euch ja einiges vorgenommen. Leider stoßt ihr bei einigen Sachen in Bereiche vor, wo sich die OSM-Community noch nicht wirklich einig ist. Ich bin mir nicht sicher, wie man da am besten zu einer Klärung kommt. Aber versuchen wir es erst mal mit ein paar konkreten Hinweisen auf dieser Liste: Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Objekt: Rolltreppe (Type: way) [...] Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Escalator Es gibt ein alternatives Proposal, das im Gegensatz zu dem von euch verwendeten approved ist. Es beseitigt auch ein paar Probleme bei der Angabe der Richtung, die fürs Routing ja evtl. auch relevant ist: http://wiki.osm.org/Proposed_features/Escalators_and_Moving_Walkways Objekt: Tunnel (Type: Fläche) - area = yes [...] - building = yes (es handelt sich um ein Indoor-Elment und soll in der Karte angezeigt werden) Einen Tunnel als building = yes zu kennzeichnen halte ich für sehr ungewöhnlich und sicher keine etablierte Praxis. Ich würde eher zu area:highway = footway für diese Fläche raten (unter Annahme, dass der bestehende Way für den Tunnel als highway = footway erfasst ist). Der Schlüssel area:highway ist zwar bisher nur ein Vorschlag, aber das hat vor allem damit zu tun, dass Flächenerfassung von Straßen und Wegen bei uns generell noch in den Kinderschuhen steckt. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hi, zunächst einmal: Ich finde es großartig, dass sich da etwas zu entwickeln scheint (ein Hoch auf den VRR :-) ) Ich habe den Thread nur überflogen. Falls das Folgende also schon erwähnt wurde oder nicht passt, einfach ignorieren ... Ich möchte hier kurz einen Querverweis machen auf einen aktuellen Thread im OSM-Forum, wo es um ein paar Ideen bzgl. des ÖPNV-Schemas geht [1]. Der User Weide hat hier eine Vorversion [2] zu etwas erarbeitet, was mal ein Proposal zu einem überarbeiteten public_transport-Schema werden könnte. Die meisten der Punkte betreffen ÖPNV-Routen, aber es gibt auch Ideen/Ergänzungen z.B. zu platform. Möglicherweise gibt es hier zumindest an einigen Punkten Synergien? Es wäre schade, wenn diese beiden Arbeiten parallel existieren würden ohne voneinander Notiz zu nehmen ... Grüße Gerhard (Seoman) [1] http://forum.openstreetmap.org/viewtopic.php?pid=349000#p349000 [2] http://wiki.openstreetmap.org/wiki/User:Weide Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft auf OSM zu setzen. Das betrifft folgende Produkte · Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern beiliegen und die an den Haltestellen aushängen sollen aus den OSM Daten errechnet und im VRR Layout dargestellt werden. · Die Haltestellenumgebungspläne, die von einigen Betrieben erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen aus OSM Daten erzeugt werden. · Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen aus OSM Daten berechnet werden · Die interaktiven Karten der VRR App, dieselben wie die aus efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca. 1.000.000 mal heruntergeladen) · Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten (dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten gezeichnet werden (siehe auchefa.vrr.de und die Apps) · Die Fußwege zu den Haltepunkten und bis zum Gleis der Schienenverkehre sollen auf OSM Daten geroutet werden · Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen · Das Fußwegrouting soll barrierefreie Wege suchen können (wird weiter unter erklärt) Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem auch der Qualität und der Detailreichtum der OSM Daten hat den VRR begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere Datenmaterialien. Das Datenmaterial, das wir in OSM vorfinden hat vor allem bezüglich der Wege (Straßen und Schienenwege) aus ausgezeichnete Qualität. Einige Daten sind allerdings noch unvollständig für unsere Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam mit der OSM Gemeinde. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das? Gehen wir von drei typischen Benutzern aus: Nutzer 1 ist Student, Pendler und in Turnschuhen unterwegs. Er kommt immer knapp vor der Zugabfahrt. Er geht schnellen Schrittes durch den Bahnhof und nimmt die Treppen hinauf zum Bahnsteig, damit er nirgends warten muss. Nutzer 2 ist der Reisende mit Koffer, oder die/der Frau/Mann mit Kinderwagen. Der Nutzer kann nur mit großer Mühe die Treppen nutzen und sucht Wege über Rolltreppen zum Bahnsteig. Nutzer 3 kommt im Rollstuhl. Er ist auf Aufzüge und Rampen angewiesen um zum Bahnsteig zu kommen, er braucht entsprechende Wege. Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). Wir brauchen also alle
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 23.07.2013 13:27, schrieb Peter Wendorff: Hallo Tracy, Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Das ist super ;) [...] Einige Daten sind allerdings noch unvollständig für unsere Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam mit der OSM Gemeinde. Das klingt gut. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Das klingt gut - aber nach Import, deshalb bitte die Import-Richtlinien berücksichtigen, wenn ihr nicht jede Haltestelle selbst kontrolliert dabei. Eine Alternative ist oft, die Daten öffentlich und für die Nutzung freigegeben zu hinterlegen, damit man verteilt die Haltestellen anhand dessen überprüfen kann. [...] Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Fast richtig. Ein Aufzug muss nicht zwingend ein way sein, um darauf route zu können. Beispiel: .x-' .x und ' seien Nodes, und jeweils dazwiscchen ways. x sei ein Aufzug und als solcher getagged (auf einem Node. trägt außerdem level=0, x trägt level=1 (was jeweils das Stockwerk angibt). Das Routing mit Berücksichtigung des Aufzugs ist hier problemlos möglich. Ebene Wege, Treppen, Rolltreppen und Rampen sind üblicherweise ways in OSM, Aufzüge aber nicht, weil sie kaum eine horizontale Ausdehnung haben. Technisch ist das aber kein Problem auch im Routing zu berücksichtigen. Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen von Plattformen gefunden: · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner Platz/Hohe Straße) stimmt, und sollte für euch kein Problem darstellen. · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist, eignet sich bei Seitenbahnsteigen (Beispiel, ….) auch das sollte kein Problem sein zu nutzen. · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München Ost) Falsch: Wieso sollte das Splitten notwendig sein? Die Plattform ist die von den Gleisen (z.B.) 2 und 3. Die linke Seite bietet den Zustieg zu Gleis 2, die rechte zu Gleis 3. Es bleibt aber erstmal trotzdem ein Bahnsteig. Wieso man diesen horizontal aufsplitten muss, verstehe ich nicht. Wenn ich zu GLEIS (!) 2 route (da fährt der Zug ab), dann route ich (so machen das bei Adressen auch alle gängigen Router) zum nächsten Punkt, der erreichbar ist. Das ist in diesem Fall der Bahnsteig 2/3, und da die linke Seite. Wo ist das Problem? Warum muss dafür der Bahnsteig gesplittet werden? und vor allem: Warum in den Rohdaten? Keine der drei Modellierungsarten ist unsere Erfindung, statt der gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten (Multipolygonen), das ist aber noch komplizierter und das haben wir noch nirgends gesehen. Ich find auch kein Beispiel; logisch wäre es aber meines Erachtens schon, und es würde mit Multipolygonen auf ein etabliertes OSM-Schema zurückgreifen, ohne dass neue Erfindungen mit falschen Daten gemacht werden müssten. Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil, dass man in der Mitte Aussparungen lassen kann. In diesen Aussparungen können dann Treppen, Rolltreppen oder Aufzüge münden, die meist aus dem Fußgängertunnel kommen. Damit wir wissen, welche Teile zu einer Plattform gehören fassen wir diese Teile in einer Relation zusammen. Also trennt ihr erst um dann wieder per Relation zu verbinden... Selbst wenn ihr trennen müsstet (was ich bezweifle), wäre die Relation unnötig, denn die lässt sich einfach aus der Geometrie herleiten (die beiden Bahnsteige sind miteinander verbunden über eine gemeinsame Kante). Meine Empfehlung (darf gerne von anderen noch kommentiert werden) wäre: Eine Plattform ist eine Plattform und kein Gleis. Eine Plattform gehört z.B. zu zwei, manchmal auch zu drei oder mehr Gleisen, und das ist
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
On 07/23/2013 11:40 AM, Tracy Kasperczyk wrote: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. [...] Objekt: Aufzug (Type: way) - highway = elevator - level = -1,0 Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Elevator Tags die schon vorhanden sind werden nicht von uns gelöscht. Sollte man den Elevator nicht evtl. als Node taggen? Die meisten gehen kerzegerade nach oben, was auf einer 2d-karte schlecht darstellbar ist. Die Option way würde ich beibehalten, da es ein paar Fahrstühle gibt, die schrägen Hochfahren (was aber wohl die Ausnahme sein dürfte) Gebäude mit weiteren Flächen: Objekt: Tunnel (Type: Fläche) - area = yes - tunnel = yes - level = ... - layer = ... - building = yes (es handelt sich um ein Indoor-Elment und soll in der Karte angezeigt werden) - designation = Unterführung Es werden die Fußwege auf den Tunnelflächen ebenfalls, erstellt bzw. wenn diese schon vorhanden sind, dann werden diese nicht gelöscht bzw. verändert. Wie bereits von einigen angesprochen, handelt es sich bei Tunneln nicht wirklich um Gebäude (ansonsten müssten wir auch jede Brücke und jede Straße als solches kennzeichnen, was ziemlich unübersichtlich wird. Besser wäre es highway=footway zu nehmen. Sollte es sich wirklich um eine Unterführung handeln, dann mit tunnel=yes. Bei Unterführungen, die abgeschlossen sind und wie ein innerer Bahnhof wirken, wie im neuen Erfurter Hauptbahnhof, wäre wohl eher indoor=yes angebracht. Aber darüber kann man streiten. in meiner Gegend hat sich ziemlich herauskristalisiert, dass man zwar Flächen von Verkehrsflächen angeben kann, aber immer zusätzlich einen Way in der Mitte zeichnet, der das Routing ermöglicht. Ansonsten können die meisten Router nur am Rand der Fläche Routen. Sprich, wenn ihr einen Tunnel als Area einzeichnet, dann legt in der Mitte noch einen Way an. Und ganz wichtig. Verbindet den Way auch zu den (Roll-)Treppen und Aufzügen! Alternativ zu den Flächen könnte man auch überlegen dem Tunnelway ein Attribut mitzugeben, dass aussagt, wie breit der Tunnel ist, oder ihr erfindet, ähnlich dem Flussufer, ein Polygonattribut für Verkehrsflächenumrandungen. Bitte gebt immer an, ob Radfahren in den Unterführungen erlaubt ist oder nicht! Dann könnte man Radfahrer evtl. an den nächsten mit Rad zugänglichen Zugangspunkt am Bahnhof leiten, ohne ihn durch den ganzen Bahnhof zu jagen [...] just my 2 cents, Andreas -- Andreas Neumann http://stadtplan-ilmenau.de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar
Hallo Johannes, Am 23.07.2013 13:18, schrieb jotpe: Hallo Dietmar, sehe ich mir die Berliner Str. in Westhoven an, sagt die grafische Auswertung, dass 251 Hausnr. fehlen. Soviele Häuser gibt es da gar nicht. Kann es sein, dass die Hausnummer von einer anderen Berliner Str. in Köln kommen? Ja stimmt. Es gibt eine weitere Berliner Straße im Nordosten Kölns, die sich über die Bezirke Mülheim, Höhenhaus und Dünnwald erstreckt. In der Spalte Hausnummern nur OSM werden noch zuviele Einträge angezeigt, hier die schon erfassten, die aber in den anderen Bezirks-Listen stehen, also nicht nur in OSM existieren. Ich muß da noch eine kleine Strukturänderung der DB vornehmen, dann ist der Fehler hoffentlich bald weg. Ich versuche, nach der Beseitigung Bescheid zu geben, wenn ich's nicht vergesse ;) Danke und viele Grüße Dietmar Viele Grüße Johannes Am 23. Juli 2013 12:13 schrieb Dietmar ostr...@diesei.de: Hallo Malte, jetzt gehen sie wieder. Ich hatte gestern abend und heute vormittag neue Auswertungen durchgeführt und die Dateinamen in falsche Umlautschreibweise abgelegt, derzeit gehen Aktualisierungen noch nicht automatisch. Viele Grüße Dietmar Am 23.07.2013 11:59, schrieb Malte Blättermann: Moin Dietmar, Die grafischen Auswertungen funktionieren scheinbar nicht mehr: http://regio-osm.de/**hausnummerauswertung/**grafikdarstellung/anzeige.* *html?ort=K%C3%B6lnhttp://regio-osm.de/hausnummerauswertung/grafikdarstellung/anzeige.html?ort=K%C3%B6ln Die *.osm Datei kann nicht geladen werden, für München das selbe. Grüße, Malte __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://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] Hausnummernauswertung in einer ersten Version verfügbar
Hallo Markus, ich habe Deinen Post nicht vergessen, sondern wollte warten, ob sich noch jemand meldet und hier ruft, war aber nicht ;) Es sollte dann wohl einer von uns beiden eine Lösung erstellen und würde möglichst dem Anderen einen Service anbieten, diesen für sich zu nutzen. Nimm bitte initialen Kontakt mit mir auf über OSM PM Useraccount okilimu, dann können wir das weitere per Mail ausmachen. Viele Grüße Dietmar aka okilimu Am 20.07.2013 10:41, schrieb Markus Semm: Hallo, Zur SOTM im September planen wir eine neue Version des Keypad-Mapper 3, die u.a. eine Liste fehlender Hausnummern pro Strasse in der Umgebung des aktuellen Standorts des Mappers enthalten wird. Dabei haben wir dasselbe Problem wie Bernd, dass es Hausnummern in der Realität schlicht nicht gibt, die eigentlich ins Schema passen würden, also z.B. 1,3,7 statt 1,3,5,7 auf einer Strassenseite. Aktuell planen wir, eine eigene Datenbank vorzuhalten, die außerhalb von OSM solche Fälle vermerkt, damit nicht jeder Mapper immer wieder in die selbe Falle läuft und nach der Hausnummer sucht. Nachdem Dietmar auch auf solche Daten angewiesen ist für eine zuverlässige Anzeige und sicherlich auch weitere Software in der Zukunft macht es Sinn, diese Information an zentraler Stelle zu sammeln. Hat jemand eine Idee, wo man diese Information am Besten ablegen könnte? Cheers Markus -Ursprüngliche Nachricht- Von: Bernd Weigelt [mailto:weigelt.be...@web.de] Gesendet: Samstag, 20. Juli 2013 08:41 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar Am 19.07.2013 22:48, schrieb Dietmar: Fehler (davon gibts noch eine Menge) und Verbesserungswünsche (da aber bitte viel Geduld mitbringen) melden. Hallo Dietmar gute Arbeit, vielen Dank dafür. Mir ist aufgefallen, dass es einige Hausnummer als fehlend angezeigt werden, obwohl ist die gar nicht gibt Z.B. In Köln-Mülheim die Juliusstraße, die geraden Hausnummern, die dort angemäckelt werden, sind nicht vorhanden. Bei der 9f bin ich mir nicht ganz sicher, aber ich glaube , die ist auch false positive. Bei vielen anderen Straßen ist es ähnlich Ansonsten ist das eine sehr gute Arbeitshilfe Bernd ___ 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] Wasserturm verschwunden
Am 23.07.2013 12:25, schrieb Walter Nordmann: Das klappt aber eigentlich nur, da OSM-ler Insiderwissen haben und die Datenstrukturen beherrschen. Außenstehende haben da erhebliche Probleme. Und das bezeichne ich nun mal als Propertiäres System. Das ist aber eine sehr merkwürdige Definition, weil nach dieser alles proprietär ist. Proprietär wäre es in meinen Augen, wenn das Format geheim ist. Das ist es bei OSM aber nicht. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserturm verschwunden
Henning Scholland wrote Das ist aber eine sehr merkwürdige Definition, weil nach dieser alles proprietär ist. Proprietär wäre es in meinen Augen, wenn das Format geheim ist. Das ist es bei OSM aber nicht. Ist eventuell etwas zu hart formuliert. Dieser Auszug aus http://de.wikipedia.org/wiki/Propriet%C3%A4r trifft meiner Meinung für OSM zu: Traditionell werden im IT-Bereich solche Dateiformate, Protokolle usw. aber auch Hardware als proprietär bezeichnet, die nicht allgemein anerkannten Standards entsprechen, also sozusagen „hauseigene“ Entwicklungen sind (Beispiele sind die Cisco VoIP-Telefone mit Skinny-Protokoll und die Software Skype). Dass das OSM-Schema nicht zum Schutz vor irgendwas stehen soll, ist klar. Es ist schlicht veraltet. Gruss walter aber alles Diskutieren bringt uns eh nicht weiter - Api 0.7 ist nicht in Sicht, also bleibt alles beim Alten - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Wasserturm-verschwunden-tp5770618p5771120.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Tracy Kasperczyk schrieb: · Gesplittete Flächen, notwendig bei Mittelbahnsteigen Nein. Notwendig für EURE Daten, aber generell nicht notwendig, und auch nicht erwünscht. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-07-23T19:56:12+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen
Am 22.07.2013 07:16, schrieb Wilhelm Spickermann: Wenn mein Name oben drüber steht und dann nur Text kommt, der nicht von mir ist, dann ist das irreführend. Sorry, ich hatte das Verrutschen um eine Einzug übersehen. Ich entschuldige mich dafür. Aber: Stephan hatte das Ganze sehr allgemein zitiert und auf den ganzen Thread Bezug genommen = etwas mehr Gelassenheit würde der ganzen Diskussion gut tun... Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Tunnel sind oft schon in den Daten vorhanden. Die sind für uns als Wegelemente sehr hilfreich. Allerdings wollen wir auch Karten für den Untergrund zeichnen, wenn sehr breite Tunnels nur als Strich daherkommen ist das irreführend. Wir brauchen also zusätzlich Flächen. -1, absolut dagegen. Wir malen keine Karten mit einem Malprogramm sondern wir erfassen die Topologie! Da was schon immer so und sollte auch so bleiben. Wenn, dann gebt z.B. für einen Weg eine Breite mittels width == xxx an. Wir sind schon seit einiger Zeit mit der Münchner OSM Gruppe in Kontakt und haben viel gelernt. :-) Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 24.07.2013 um 00:39 schrieb Michael Kugelmann michaelk_...@gmx.de: -1, absolut dagegen. Wir malen keine Karten mit einem Malprogramm sondern wir erfassen die Topologie! Da was schon immer so und sollte auch so bleiben. Wenn, dann gebt z.B. für einen Weg eine Breite mittels width == xxx Wir erfassen ja nicht nur einen Graphen, auch wenn der ziemlich nützlich ist. M.E. Ist der Wunsch legitim, auch unterirdische Plätze und Verkehrsräume von öffentlichen Gebäuden mit ihren Grenzen aufzunehmen und nicht nur als linearen Graph, mit einem Malprogramm sollte man das nicht verwechseln, allerdings ist mit derzeitiger Editor-Technik mehr als ein Stockwerk übereinander eigentlich nicht effizient bearbeitbar oder verständlich, von daher ist der Einwand auch nicht völlig unberechtigt. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] nochmal temporäre Sperrungen: Ablaufdatum? (Was: Einführung eines neuen Tags (globaleID))
Auch bei OSM-Daten haben Navis nicht ständig eine aktuelle Karte, sondern z.B. alle paar Monate neu generierte Offline-Daten. Das ist prinzipiell schneller möglich als bei anderen Anbietern, aber das heißt nicht, dass es schneller aktualisiert wird. Wenn dann eure 3-Tage-Wartung der Rolltreppe im Kartenmaterial von Max Mustermanns Navi für die nächsten 6 Monate festgelegt ist, ist das Mist. Da wir das Problem wohl mit steigender Frequenz bekommen: Warum temporäre Sperrungen nicht mit Ablaufdatum (selbst wenn das noch geraten ist) versehen? Oder zumindest mit einem temporär-Tag. Dann kann der Extraktor, der die Daten für sein Medion-, Navit oder was auch immer zieht, die Dinger gleich abfiltern und so rendern, als ob nix wäre, wenn er schon weiss, dass er (und seine Anwendung) keinen regelmäßigen Datenabgleich hinbekommt. (Wobei ich natürlich immernoch Bauchschmerzen habe, so ein Mappen für den Medion zu betreiben, nur weil die keine sinnvollen Aktualisierungszyklen hinbekommen mit OSM-Daten.) -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Zunächst einmal an die Community. Im Allgemeinen wünschen wir Quellen für Importe. Bezogen auf die geografischen Einordnung ist dies aber in diesem Falle möglicherweise schwierig, wenn diese Daten überhaupt erst mit Hilfe von OSM Werkzeugen erstmals im geografischen Umfeld erfasst werden. Wir haben hier möglicherweise eine bisher nie oder kaum dagewesene Situation, dass OSM die Erstveröffentlichungsquelle ist und damit eine andere Quelle nicht zur Verfügung steht. Dann müssten wir uns im Rahmen dieses Imports überlegen, wie die für Importe notwendige Zusicherung, diese Daten unter der OSM Lizenz veröffentlichen zu dürfen, bewirkt werden kann. Ich denke, hier sollten wir unsere Data-Working-Group mit ihren entsprechenden Erfahrungen mit größeren Importen um Mithilfe bitten. Tracy Kasperczyk kasperc...@mentzdv.de wrote: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Sehr gut. :-) Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft auf OSM zu setzen. Das betrifft folgende Produkte Wenn der VRR der zentrale Koordinator für NRW ist, dürfte ihm nicht entgangen sein, dass Marcel Hövelmann vom Verkehrsverbund Rhein Sieg sowie Thomas Reincke vom Aachener Verkehrverbund aus ähnlichen Beweggründen wie ihr, schon Jahre eine gedeihliche Zusammenarbeit mit OSM pflegen. Ist Euch das bekannt? Hier der Vortrag der beiden auf unserer D-A-CH Konferenz namens FOSSGIS 2011: http://ftp5.gwdg.de/pub/misc/openstreetmap/FOSSGIS2011/FOSSGIS2011-191-de-oepnv_vrs_aav.webm Hier die neueste OSM Anwendung des VRS, die übrigens immer weiter in den Bereich des VRR, insbesondere der Rheinbahn hineinreicht. Zum Beispiel findet man dort den U-Bahnhof Heinrich-Heine-Allee in Düsseldorf: http://www.vrsinfo.de/fahrplan/haltestellen-und-linieninformationen.html Von daher wäre es vielleicht nicht das Schlechteste, mit den beiden Herren Kontakt aufzunehmen. Sie sind daneben auch OSM-Community erfahren. · Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern beiliegen und die an den Haltestellen aushängen sollen aus den OSM Daten errechnet und im VRR Layout dargestellt werden. · Die Haltestellenumgebungspläne, die von einigen Betrieben erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen aus OSM Daten erzeugt werden. Zur Info für die Community: So sehen die Umgebungspläne der Rheinbahn heute aus, die im Wesentlichen nur für die inneren Stadtteile Düsseldorfs existieren: http://www.rheinbahn.de/fahrplan/karten/Seiten/haltestellen.aspx In den peripheren Stadtteilen Düsseldorfs und in fast allen umliegenden Städten kann der Fahrgast nicht auf solche Pläne zurückgreifen. Selbst die Umsteigepunkte mit vielen Linien sind in deren Plänen derzeit nur durch einen gemeinsamen Punkt gekennzeichnet. · Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen aus OSM Daten berechnet werden · Die interaktiven Karten der VRR App, dieselben wie die aus efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca. 1.000.000 mal heruntergeladen) · Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten (dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten gezeichnet werden (siehe auchefa.vrr.de und die Apps) · Die Fußwege zu den Haltepunkten und bis zum Gleis der Schienenverkehre sollen auf OSM Daten geroutet werden · Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen · Das Fußwegrouting soll barrierefreie Wege suchen können (wird weiter unter erklärt) Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem auch der Qualität und der Detailreichtum der OSM Daten hat den VRR begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere Datenmaterialien. Sehr gut. Ich bin sicher, dass sehr viele in der Community genau dafür mappen, dass ihre Daten entsprechend nützlich werden können - insbesondere was die in anderen Karten nicht zu findende Detailliertheit an Fuß- und Radwegen angeht. Weitere Datenelemente die wir brauchen, sind die oben erwähnten Haltepunkte auf den Schienen oder die Haltepunkte der Busse vor dem Bahnhof. Dies Punkte brauchen wir um einen Weg auf die Karte zeichnen zu können. Dort ist Anfang oder Ende des Wegs im Fahrzeug und der Übergang auf den Fußweg. Das sind bekannte OSM Objekte ( http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position) Insbesondere bei den Bussen ist mir nicht klar, wozu ihr die stop_position braucht. Ein Bus hält etwa am Haltestellenschild bzw. an der Mitte der Plattform (public_transport=platform) auf seiner in OSM enthaltenen Route. Warum fällt ihr nicht einfach das Lot
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Michael Kugelmann michaelk_...@gmx.de wrote: Allerdings wollen wir auch Karten für den Untergrund zeichnen, wenn sehr breite Tunnels nur als Strich daherkommen ist das irreführend. Wir brauchen also zusätzlich Flächen. -1, absolut dagegen. Wir malen keine Karten mit einem Malprogramm sondern wir erfassen die Topologie! Da was schon immer so und sollte auch so bleiben. Hmm http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver aber auch http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank Machen wir damit nicht das Eine, ohne das Andere zu lassen? Wenn, dann gebt z.B. für einen Weg eine Breite mittels width == xxx an. Ginge auch. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: · Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten (dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten gezeichnet werden (siehe auchefa.vrr.de und die Apps) als Overlay oder als Verknüfung zu den OSM-Daten? Ich Route die Linienwege auf der OSM-Karte. Die dabei entstehenden Fahrwege sind jedoch von OSM unabhängig. Eine Verknüpfung findet nicht statt. Wenn ein neuer Kreisverkehr eingerichtet wird oder der Straßenverlauf verfeinert wird, bekomme ich das nicht mit. Das wird im Rahmen der regelmäßigen Durcharbeitung des Bestandes korrigiert - oder eben auch nicht. bei einer technischen Lösung sähe ich einen erheblichen Mehraufwand bei einem nur marginalen Mehrnutzen. Extrem wird es bei den Eisenbahnen, wo inzwischen an vielen Stellen jedes Gleis eingezeichnet ist. Eigentlich müsste man dann wirklich den genauen Fahrweg über jede Weiche prüfen und darstellen. Diesen Aufwand treibe ich nicht. · Die Fußwege zu den Haltepunkten und bis zum Gleis der Schienenverkehre sollen auf OSM Daten geroutet werden · Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen · Das Fußwegrouting soll barrierefreie Wege suchen können (wird weiter unter erklärt) Dazu brauche ich m.E. keine Integration der ÖV-Daten in OSM. Wenn es ungefähr zueinander passt, reicht das völlig aus. Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem auch der Qualität und der Detailreichtum der OSM Daten hat den VRR begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere Datenmaterialien. Diese Gründe waren für uns vor über drei Jahren ebenfalls ausschlaggebend. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Schön, aber wozu? Ich würde mir den Linienverlauf als Layer besorgen und mit OSM abgleichen, ob er dort fahrbar ist. Busspuren müssen dort rein, wo sie baulich eine eigene Fahrbahn sind. Das wird wahrscheinlich fast überall der Fall sein. Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das? Ist das so sinnvoll? Wichtig sind die Ausgänge einer U-Bahn-Station. Die müssen innerhlb des Haltestellenmodells erfasst sein. Die Wege innerhalb des Bauwerks wird festgelegt und durch eine Zeit sowie ggf. die Arten der Einschränkungen in der Nutzbarkeit festgelegt. Die Zeiten hängen von der zurückgelegten Strecke, der Zahl der Stufen sowie ggf. technischen Parametern, wie Warte- und Fahrzeit eines Aufzuges ab. Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Einmalig, bei der Erstellung. Aber nicht on the Fly bei jeder Verbindungsabfrage. Der VRR macht sich die Entscheidung, auf OSM zu setzen nicht leicht. Man ist immer noch besorgt, dass Daten, die in die Produktion der Fahrplanunterlagen und Karten gehen sich kurzfristig unkontrolliert ändern. Wir bitte deshalb auch die OSM-Gemeinde hier Vorsicht walten zu lassen. Man kann immer mit uns Kontakt aufnehmen. Deshalb die eigenen Daten von den Kartendaten trennen. Es ist nicht nur so das der VRR in Zukunft auf OSM umstellen möchte, es werden sondern noch weitere Verkehrsverbünde und Betriebe diesem Beispiel folgen. Der VRR ist nicht der erste Verbund der das macht... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Thomas Reincke schrieb: Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Einmalig, bei der Erstellung. Aber nicht on the Fly bei jeder Verbindungsabfrage. Vor allem wird hier wieder „wir“ durch „man“ ersetzt, denn „man“ kann sehr wohl darüber routen. Dass das geht, zeigen diverse Routingprogramme, die ohne Probleme über Treppen und Aufzüge routen können. Der VRR macht sich die Entscheidung, auf OSM zu setzen nicht leicht. Man ist immer noch besorgt, dass Daten, die in die Produktion der Fahrplanunterlagen und Karten gehen sich kurzfristig unkontrolliert ändern. Wir bitte deshalb auch die OSM-Gemeinde hier Vorsicht walten zu lassen. Man kann immer mit uns Kontakt aufnehmen. Deshalb die eigenen Daten von den Kartendaten trennen. Das sage ich denen schon seit der ersten Mail :) Spezialdaten als eigenen Layer bereitstellen, und dort, wo es gewünscht ist, eben mit den Daten aus OSM zusammenfügen, und ausliefern. Das ist ja auch wesentlich stressfreier, da nicht unnötig Bahnhöfe gespalten, oder Aufzüge als Weg gemappt werden müssen. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-07-24T07:31:50+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Riserva naturale
Ciao, a tal proposito vorrei segnalare questo layer http://www.eea.europa.eu/data-and-maps/data/ds_resolveuid/29430BDF-9AFB-4F1A-A529-7B4EF6D680D7 Dove sono individuate tutte le aree protette in Europa dai grandi parchi alle riserve locali, con nome, tipo, leggi, codici di identificaizione, ecc. In più viene costantemente aggiornato con le nuove aree. Cosa ne pensate? sarebbe da fare un import nazionale almeno, se non coordinarsi a livello europeo. Saluti G Il 19 luglio 2013 22:28, Mario Pichetti mario.piche...@gmail.com ha scritto: Il 19/07/2013 16:56, Simone Saviolo ha scritto: Il giorno 19 luglio 2013 16:43, Andrea Musuruane musur...@gmail.com ha scritto: 2013/7/19 Simone Saviolo simone.savi...@gmail.com Ciao a tutti, un utente ha taggato come leisure=park una riserva naturale [1]. Qual è il tag corretto? Avevo avuto un problema analogo. La discussione mi ha portato a modificare l'area nel seguente modo: http://www.openstreetmap.org/browse/way/220274549/history Grazie, ho corretto. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it http://wiki.openstreetmap.org/wiki/IT:How_to_map_a#R ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing marittimo per Bastia
On 23/lug/2013, at 07:54, emmexx emm...@tiscalinet.it wrote: OSRM funziona impostando alcune regole che riguardano la velocita' media a seconda del tipo di strada (il valore di highway) piu' il valore di altri tag piu' alcune regole interne (penalita' per le svolte, semafori, ecc.). Uno dei fattori più importanti sono i limiti di velocità, una strada può essere primary ma comunque avere un limite di 60 (o anche meno), ed è importante per il routing di avere questi limiti taggati. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] corsia ciclabile spezzettata
In questo caso le way sono gia' presenti e devo solo aggiungere il tag cycleway=lane. Il problema e' che, mancando la continuita' della corsia ciclabile in alcuni punti, un operazione abbastanza semplice come, appunto, aggiungere il tag cycleway ad una way lunga un kilometro (ad esempio) si trasforma nella necessita' di spezzettare la way in corrispondenza di ogni incrocio. Oltretutto, per come sono fatte queste corsie ciclabili, bisogna spezzare una decina di metri prima dell'incrocio e 2-3 metri dopo. Ed essendo gli incroci in osm adimensionali (un punto) questo ha delle implicazioni quando si manipolano queste way cortissime. Hai delle foto? O si vede su Streetview? Volker ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] corsia ciclabile spezzettata
Il 07/23/2013 11:18 AM, Volker Schmidt scrisse: Hai delle foto? O si vede su Streetview? La ciclabile e' stata tracciata nelle scorse settimane, non c'e' su Streetview. Ecco alcune foto: http://www.emmexx.it/varie/ciclabili-marche/dsc02869.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02871.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02873.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02875.jpg (qui c'e' la continuita' ciclabile) http://www.emmexx.it/varie/ciclabili-marche/dsc02877.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02900.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02908.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02916.jpg (scusate le ho caricate in alta definizione) ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] corsia ciclabile spezzettata
Molto strano. Forse conviene contattare l'ufficio competente. L'unico caso che sembra simile a cose che ho già incontrato è dsc02873.jpghttp://www.emmexx.it/varie/ciclabili-marche/dsc02873.jpg(una situazione peraltro molto pericolosa) Volker 2013/7/23 emmexx emm...@tiscalinet.it Il 07/23/2013 11:18 AM, Volker Schmidt scrisse: Hai delle foto? O si vede su Streetview? La ciclabile e' stata tracciata nelle scorse settimane, non c'e' su Streetview. Ecco alcune foto: http://www.emmexx.it/varie/ciclabili-marche/dsc02869.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02871.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02873.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02875.jpg (qui c'e' la continuita' ciclabile) http://www.emmexx.it/varie/ciclabili-marche/dsc02877.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02900.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02908.jpg http://www.emmexx.it/varie/ciclabili-marche/dsc02916.jpg (scusate le ho caricate in alta definizione) ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] corsia ciclabile spezzettata
Il 07/23/2013 01:16 PM, Volker Schmidt scrisse: Molto strano. Forse conviene contattare l'ufficio competente. Ricordi di quale associazione faccio parte? ;-) Purtroppo non c'e' verso, si rifanno a regolamenti ministeriali, a disposizioni della Polizia Municipale. Abbiamo insistito con tutti, dall'assessore alla mobilita' in giu' ma quello che vedi nelle foto e' il risultato... :-( E non ho messo la foto in cui la corsia si interrompe per una ventina di metri per permettere alle auto che si recano presso un'officina di parcheggiare. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing marittimo per Bastia
Per le velocità penso che usi [1]. Come farà a capire se una strada è urbana o extraurbana ? Carlo, sono d'accordo con te che la cosa va valutata su entrambi i fronti, ma vediamola intanto dal punto di vista di OSM: mappiamo la realtà nel miglior modo possibile e vediamo se questo già aiuta. Ciao! Fabrizio [1] http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Italy Il giorno 23 luglio 2013 11:02, Martin Koppenhoefer dieterdre...@gmail.comha scritto: On 23/lug/2013, at 07:54, emmexx emm...@tiscalinet.it wrote: OSRM funziona impostando alcune regole che riguardano la velocita' media a seconda del tipo di strada (il valore di highway) piu' il valore di altri tag piu' alcune regole interne (penalita' per le svolte, semafori, ecc.). Uno dei fattori più importanti sono i limiti di velocità, una strada può essere primary ma comunque avere un limite di 60 (o anche meno), ed è importante per il routing di avere questi limiti taggati. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] corsia ciclabile spezzettata
2013/7/23 emmexx emm...@tiscalinet.it: Il 07/23/2013 01:16 PM, Volker Schmidt scrisse: Molto strano. Forse conviene contattare l'ufficio competente. Ricordi di quale associazione faccio parte? ;-) Purtroppo non c'e' verso, si rifanno a regolamenti ministeriali, a disposizioni della Polizia Municipale. Abbiamo insistito con tutti, dall'assessore alla mobilita' in giu' ma quello che vedi nelle foto e' il risultato... :-( E non ho messo la foto in cui la corsia si interrompe per una ventina di metri per permettere alle auto che si recano presso un'officina di parcheggiare. Secondo me per i casi più semplici ci sono due possibilità: - per una volta fregarsene un po' della realtà e dove ci sono interruzioni per i semafori far continuare la pista ciclabile - mantenere inalterata la realtà e collegare la pista ciclabile alla strada e poi farla ricominciare dopo il semaforo Per quello più complesso (e pericoloso) non capisco se continua o no, se continua utilizzerei la mia seconda proposta ciao maxx -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing marittimo per Bastia
Il 07/23/2013 01:34 PM, Fabrizio Carrai scrisse: Per le velocità penso che usi [1]. Come farà a capire se una strada è urbana o extraurbana ? Non lo capisce, questo e' il file di configurazione usato per calcolare i pesi degli archi per il calcolo dei percorsi: https://github.com/DennisOSRM/Project-OSRM/blob/master/profiles/car.lua Come si puo' capire abbastanza facilmente dal codiece vengono usati i tag highway e maxspeed, in linea di massima. Puo' essere che il file usato in produzione sia un po' piu' complesso ma non ho mai letto sul sito di OSRM di concetti come urbano ed interurbano. Ricordo invece un ticket in cui si parlava del problema dei diversi limiti di velocita' predefiniti nei vari paesi ma non ricordo venisse proposta una soluzione ne' riesco a trovare il ticket in questione. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing marittimo per Bastia
Il giorno 23 luglio 2013 13:34, Fabrizio Carrai fabrizio.car...@gmail.comha scritto: Per le velocità penso che usi [1]. Come farà a capire se una strada è urbana o extraurbana ? Carlo, sono d'accordo con te che la cosa va valutata su entrambi i fronti, ma vediamola intanto dal punto di vista di OSM: mappiamo la realtà nel miglior modo possibile e vediamo se questo già aiuta. Infatti: tagga il maxspeed! :-) (anch'io l'ho fatto poco, mi ci metto anch'io tra quelli che rompono il routing). Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] corsia ciclabile spezzettata
Am 23/lug/2013 um 14:09 schrieb Luca Delucchi lucadel...@gmail.com: - mantenere inalterata la realtà e collegare la pista ciclabile alla strada e poi farla ricominciare dopo il semaforo +1 ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing marittimo per Bastia
Aggiunto il maxspeed almeno sui trunk di variante, ma non dovrebbe aiutare la cosa, anzi...il limite è di 90 Km/h ed il default usato da OSRM era di 85. Aggiunto i maxspeed sulle primary e secondary in ambito cittadino. Credo che il tratto veloce su trunk dia un grosso contributo alla scelta del percorso che porta ad attraversare il centro. Ci vorrebbe un tag che definisce la velocità media che ci si aspetta su quel tratto, valore peraltro molto soggettivo e sicuramente variabile, quindi poco coerente con l'uso di OSM. Aggiunto qualche lanes, vediamo Fabrizio Il giorno 23 luglio 2013 14:33, Simone Saviolo simone.savi...@gmail.comha scritto: Il giorno 23 luglio 2013 13:34, Fabrizio Carrai fabrizio.car...@gmail.com ha scritto: Per le velocità penso che usi [1]. Come farà a capire se una strada è urbana o extraurbana ? Carlo, sono d'accordo con te che la cosa va valutata su entrambi i fronti, ma vediamola intanto dal punto di vista di OSM: mappiamo la realtà nel miglior modo possibile e vediamo se questo già aiuta. Infatti: tagga il maxspeed! :-) (anch'io l'ho fatto poco, mi ci metto anch'io tra quelli che rompono il routing). Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing marittimo per Bastia
Am 23.07.2013 um 13:34 schrieb Fabrizio Carrai fabrizio.car...@gmail.com: [1] http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Italy Forse sarebbe meglio avere lì una tabella come il Lussemburgo, e non un elenco di singole classi highway, che dite? Ciao, Martin___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing marittimo per Bastia
Il giorno 24 luglio 2013 01:06, Martin Koppenhöfer dieterdre...@gmail.comha scritto: Am 23.07.2013 um 13:34 schrieb Fabrizio Carrai fabrizio.car...@gmail.com : [1] http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Italy Forse sarebbe meglio avere lì una tabella come il Lussemburgo, e non un elenco di singole classi highway, che dite? Sì, anche perché è sbagliata: le strade extraurbane secondarie di default sono a 90, quindi quei 70 km/h per le unclassified extraurbane non è corretto. E poi anche le trunk urbane a 70 all'ora mi torna poco: forse si stava pensando ai viali urbani di scorrimento, che effettivamente sono a 70 km/h, però possono essere tranquillamente classificati come primary/secondary/tertiary su OSM. -- Giacomo Boschi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Riserva naturale
On Jul 23, 2013 10:50 AM, Giovanni Caudullo giovanni.caudu...@gmail.com wrote: Ciao, a tal proposito vorrei segnalare questo layer http://www.eea.europa.eu/data-and-maps/data/ds_resolveuid/29430BDF-9AFB-4F1A-A529-7B4EF6D680D7 Dove sono individuate tutte le aree protette in Europa dai grandi parchi alle riserve locali, con nome, tipo, leggi, codici di identificaizione, ecc. In più viene costantemente aggiornato con le nuove aree. Cosa ne pensate? sarebbe da fare un import nazionale almeno, se non coordinarsi a livello europeo. Si, l'unica cosa non ho visto la licenza dei dati... Saluti G Ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-dk] meget flittig tysker
Da jeg ikke fik entydigt positivt svar tilbage fra min tyske translatør, sendte jeg win32netsky videre til DWG. Se nedenfor - nu skulle der gerne være sat prop i :). Mvh. Rasmus Rasmus, thank you for writing to Data Working Group. Googling tells me that the French have had a similar problem with the same user, here: http://lists.openstreetmap.**org/pipermail/talk-fr/2011-**August/035072.htmlhttp://lists.openstreetmap.org/pipermail/talk-fr/2011-August/035072.html From what Jongleur says, I have reason to believe that win32netsky is somehow optimising for a use case - Garmin routing or reverse geocoding or so. That might explain why he adds post code boundaries - to be able to find a postcode for a given location, even if such a thing does not exist in Denmark. It seems that he has stopped his activity on the 20th - he has written that to Jongleur and he has also put it up on his user page. I'll send him another message asking him to only map in areas where he is able to communicate with the locals, and respect local customs. I will explicitly ask him to stop mapping in Denmark unless he feels able to address your concerns. I won't block him for now (because it looks like he might have stopped by himself) but if he goes against my request and contiues mapping, then please do inform me and I will block him. Best Frederik Ramm for the OSMF Data Working Group PS You can forward this message to the talk-dk list if you want. Med venlig hilsen Rasmus Vendelboe 2013/7/19 Rasmus Vendelboe r.vendelboe+...@gmail.com Hej allesammen, Det her er desværre en lidt kedelig besked... og egentligt bare andres maintaineres info. Vi har besøg af en meget meget flittig tysker[*] i Jylland - desværre med nogle knapt så gode edits[#] imellem en hel del gode brugbare tilføjelser. MichaelVL og jeg har begge forsøgt at kommunikere med ham om disse edits, men har været uden held og fået kilometervis af sort snak tilbage. Jeg bad ham og at slå fuld stop indtil vi forstod hinanden. Det skete ikke. Jeg burde have have gjort noget ved ham for flere måneder siden, men jeg havde hverken lyst eller kræfter til det. Nu skal det ske (og ved hjælp af en venlig person på talk-de) er han blevet gjort opmærksom på han skal her forbi eller se frem til at snakke med Data Working Group. Jeg skal bl.a. spørge ham hvorfor og hvad ideen er i, at han flytter vores kommunegrænser og samkører dem med andre ikke eksisterende grænser. Jeg håber da på han kommer med nogle gode indspil, men såfremt den sorte snak fortsætter, antager jeg da, at vi står sammen som dansk community og sender ham videre til DWG uden pjat. [*] http://www.openstreetmap.org/user/Win32netsky/edits [#] - Jeg ikke se hvilke kilder han bruger til at tegne efter. - Changeset beskrivelserne er ikke brugbare og ændringerne ofte overskueligt store. - Han flytter addresse data efter for godtbefindende. - Han har skadet relationer. - Fjerner huse uden begrundelse. - Tegner post code arealer (hvilket ikke findes i DK og derfor pr. definition ikke giver mening af inkludere i OSM) - samkører fantasi post code arealer med kommunegrænser og regionsgrænser - flytter på kommunegrænser og regionsgrænser uden begrundelse (så de ikke længere passer med adresse data) . Med venlig hilsen Rasmus Vendelboe (rasmusv) ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-se] Nybörjarmanual - skärmbild
Var precis inne på sidan och tyckte den såg ren och pedagogisk ut. Hittade nog (är inte så jätteduktig på svenska ;) ) ett par grammatiska fel och stavfel: Sidan 1.Konto: Under första rubriken Skapa konto står det redigera karta, låter bättre med redigera kartan, Under rubriken Bekräfta redigeringen står det öppna bekräftelsemailen antar att det är ett så öppna bekräftelsemailet Sidan 2. Taggar: Under sista rubriken Kartdetaljer står det vissa sak ska taggar tror jag blir bättre viss sak skall taggas Sedan tänkte jag att en förbättring skulle kunna vara att på sidan 1. Konto där det står Börja med att ta dig till OpenStreetMaps webbplats göra OpenStreetMaps webbplats till en länk dit. Samma sak på sida två under kapitlet map features. Sist har jag två funderingar på innehållet: 1. En linje beskrivs som att den inte får ha gemensam start och ändpunkt för då blir det en area. Det är ju lite fel att säga t.ex. en rondel kan ha samma start och ändpunkt och ändå inte behandlas som en area untan det styrs av taggarna. Mitt förslag är att ta bort det under linjen och under kapitlet för area säga att en linje med samma start och slutpunkt kan behandlas som en area. (detta kanske är lite onödigt men anars kanske en del när de börjar rita börjar dela upp rondeller i en massa segment när det inte behövs..). 2. Under taggar står det att elementen behöver ha en eller flera taggar. Detta stämmer typ. Fast inte om de tillhör ett högre element(de flesta noder i vägar är ju tagglösa och även linjer i hus med hål i så sitter ju oftast buildingtaggen på en relation istället) (återigen kanske onödigt att ta upp så här tidigt men kanske ändra ordet behöver till kan och sen inte nämna mer om när de inte behöver det?) MvH Tobias P.s. Hoppas du inte tar detta jag skrivit negativt, jag försöker bara ge lite feedback om vad jag tycker och jag tycker du/ni har gjort ett mycket bra jobb d.s. Den 23 juli 2013 20:36 skrev Peter Kindström peter.kindst...@abc.se: Hej! Och tack Joakim för skärmbilden! Jag lade upp den och hoppas den är tillräckligt rätt. Kan du annars kasta upp källkoden för sidan på t.ex. Github så man lätt kan fixa patchar för stavning och sånt? ;) Ja, min tanke är att lägga upp sidorna pǻ Github. Jag har redan konto där och dessutom är sidorna gjorda i Markdown, d.v.s en textfil med lite enkel formattering (Markdown Syntaxhttp://daringfireball.net/projects/markdown/syntax ). Tills vidare har jag gjort länkar direkt till markdown-filerna plus skapat en e-pub-fil (bara för jag hittade ett program som enkelt konverterade Markdown - E-pub. :-) ) Titta på Om-sidan. // Peter Kindström ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se
[Talk-es] New tile rendering server (Experimental)
Hi Spain Portugal, **Sorry for this email only being in English. I would appreciate it if someone could translate this message (or summary) for list members.** I have just switched the default OpenStreetMap.org “Mapnik style” map tiles for tile.openstreetmap.org for Spain and Portugal across to our new rendering server. The new rendering server has been tested and is now ready for production. We’re migrating traffic over region-by-region and Spain Portugal are the third region to go live (After Australia + New Zealand Mexico). In addition to new hardware, the rendering server also uses the new “openstreetmap-carto” stylesheets. These are a complete re-write of the XML stylesheets to use CartoCSS, making them easier for our cartographers to work with. Andy Allan’s great talk at State of the Map US described the reason for the stylesheet re-write: http://stateofthemap.us/saturday.html#schedule/saturday/putting-the-carto-into-openstreetmap-cartography The map tiles will be slightly slower at medium-high zooms while the server builds up its cache. The style is designed to look the same as the current XML stylesheet. The “openstreetmap-carto” stylesheet is maintained here: https://github.com/gravitystorm/openstreetmap-carto Big Thank you to #osm-dev for helping draft this announcement. Kind regards Grant Slater Part of the OSM Sysadmin Team ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] New tile rendering server (Experimental)
Traduzco el correo de Grant, por si no habláis el idioma de la pérfida Albión: --- El Martes, 23 de julio de 2013 11:10:35 Grant Slater escribió: He cambiado el estilo Mapnik por defecto de osm.org para las tiles que se sirven de España y Portugal desde nuestro nuevo servidor de render. El nuevo servidor de render ha sido probado y está listo para pasar a producción. Estamos migrando tráfico región por región, y España-Portugal es la tercera región en salir a la luz (después de Australia+Nueva Zelanda y México) Además de nuevo hardware, el servidor de render usa el nuevo estilo openstreetmap-carto. Estas hojas de estilo son una reescritura completa de las hojas de estilo en XML, pero usando CartoCSS, haciendo que a los cartógrafos les sea más fácil trabajar con ellas. La gran charla de Andy Allan en el State of the Map EEUU describe las razones tras la reescritura de las hojas de estilo: http://stateofthemap.us/saturday.html#schedule/saturday/putting-the-carto- into-openstreetmap-cartography Las tiles del mapa serán ligeramente más lentas a niveles de zoom medios y altos, hasta que el servidor construya la caché. El estilo está diseñado para tener el mismo aspecto que las hojas de estilo XML actuales. El estilo openstreetmap-carto está mantenido aquí: https://github.com/gravitystorm/openstreetmap-carto Mis agradecimientos a #osm-dev por ayudar a escribir esta novedad. Atentamente, Grant Slater Parte del equipo de sysadmins de OSM -- -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org Si los políticos empiezan a hacer el payaso quizás los payasos tengamos que empezar a hacer política. -- Leo Bassi. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] New tile rendering server (Experimental)
y ahora, en resumen, qué es lo que se cambia? El 23 de julio de 2013 13:01, Iván Sánchez Ortega i...@sanchezortega.esescribió: Traduzco el correo de Grant, por si no habláis el idioma de la pérfida Albión: --- El Martes, 23 de julio de 2013 11:10:35 Grant Slater escribió: He cambiado el estilo Mapnik por defecto de osm.org para las tiles que se sirven de España y Portugal desde nuestro nuevo servidor de render. El nuevo servidor de render ha sido probado y está listo para pasar a producción. Estamos migrando tráfico región por región, y España-Portugal es la tercera región en salir a la luz (después de Australia+Nueva Zelanda y México) Además de nuevo hardware, el servidor de render usa el nuevo estilo openstreetmap-carto. Estas hojas de estilo son una reescritura completa de las hojas de estilo en XML, pero usando CartoCSS, haciendo que a los cartógrafos les sea más fácil trabajar con ellas. La gran charla de Andy Allan en el State of the Map EEUU describe las razones tras la reescritura de las hojas de estilo: http://stateofthemap.us/saturday.html#schedule/saturday/putting-the-carto- into-openstreetmap-cartography Las tiles del mapa serán ligeramente más lentas a niveles de zoom medios y altos, hasta que el servidor construya la caché. El estilo está diseñado para tener el mismo aspecto que las hojas de estilo XML actuales. El estilo openstreetmap-carto está mantenido aquí: https://github.com/gravitystorm/openstreetmap-carto Mis agradecimientos a #osm-dev por ayudar a escribir esta novedad. Atentamente, Grant Slater Parte del equipo de sysadmins de OSM -- -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org Si los políticos empiezan a hacer el payaso quizás los payasos tengamos que empezar a hacer política. -- Leo Bassi. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] New tile rendering server (Experimental)
A efectos de usuario tiene pinta de que nada. Simplemente la página cargará las imágenes de un servidor más cercano (por lo que debería ir mejor, menos saturado, etc.) A efectos de desarrolladores, ahora las imágenes el nuevo servidor las genera usando el CartoCSS que debe ser más sencillo de manejar. PD: Por cierto, me gusta mucho el nuevo menú lateral con todo más integrado y elegante. =) El 23 de julio de 2013 13:04, Ricardo Sanz ricardosanz1...@gmail.comescribió: y ahora, en resumen, qué es lo que se cambia? El 23 de julio de 2013 13:01, Iván Sánchez Ortega i...@sanchezortega.esescribió: Traduzco el correo de Grant, por si no habláis el idioma de la pérfida Albión: --- El Martes, 23 de julio de 2013 11:10:35 Grant Slater escribió: He cambiado el estilo Mapnik por defecto de osm.org para las tiles que se sirven de España y Portugal desde nuestro nuevo servidor de render. El nuevo servidor de render ha sido probado y está listo para pasar a producción. Estamos migrando tráfico región por región, y España-Portugal es la tercera región en salir a la luz (después de Australia+Nueva Zelanda y México) Además de nuevo hardware, el servidor de render usa el nuevo estilo openstreetmap-carto. Estas hojas de estilo son una reescritura completa de las hojas de estilo en XML, pero usando CartoCSS, haciendo que a los cartógrafos les sea más fácil trabajar con ellas. La gran charla de Andy Allan en el State of the Map EEUU describe las razones tras la reescritura de las hojas de estilo: http://stateofthemap.us/saturday.html#schedule/saturday/putting-the-carto- into-openstreetmap-cartographyhttp://stateofthemap.us/saturday.html#schedule/saturday/putting-the-carto-into-openstreetmap-cartography Las tiles del mapa serán ligeramente más lentas a niveles de zoom medios y altos, hasta que el servidor construya la caché. El estilo está diseñado para tener el mismo aspecto que las hojas de estilo XML actuales. El estilo openstreetmap-carto está mantenido aquí: https://github.com/gravitystorm/openstreetmap-carto Mis agradecimientos a #osm-dev por ayudar a escribir esta novedad. Atentamente, Grant Slater Parte del equipo de sysadmins de OSM -- -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org Si los políticos empiezan a hacer el payaso quizás los payasos tengamos que empezar a hacer política. -- Leo Bassi. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Ander Pijoan Lamas Research Assistant, Deustotech Computer Science Engineer University of Deusto E-mail: ander.pij...@deusto.es Phone: +34 664471228 in: http://www.linkedin.com/profile/view?id=162888312 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] New tile rendering server (Experimental)
On Martes, 23 de julio de 2013 13:04:48 Ricardo Sanz escribió: y ahora, en resumen, qué es lo que se cambia? De cara al usuario habitual de OSM, nada. De cara al cartógrafo con trastorno obsesivo-compulsivo, el estilo gráfico del mapa por defecto de osm.org puede tener *mínimos* cambios. Esto puede ser un píxel más grande, nosequé está un poquito descuadrado, etc. De cara a los de sistemas y redes, ahora las tiles se cargan desde un servidor en Francia, en vez de desde el servidor principal en Londres. Y, como ha dicho Grant, el refresco de las tiles (el tiempo que pasa desde que cambian los datos hasta que cambia el mapa) puede ser algo más grande de lo habitual. De cara a los desarrolladores, ahora el estilo gráfico es mucho más cómodo de probar y trastear (por ejemplo, con tilemill). Antes, las 7000 líneas de XML eran infumables. -- -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] New tile rendering server (Experimental)
Una pregunta, los estilos por defecto que se usan osm.org, ¿en qué lista de correo o ámbito se discuten? ¿Talk o alguna más específica? ¿En ningún sitio? Saludos, César El 23 de julio de 2013 13:25, Iván Sánchez Ortega i...@sanchezortega.esescribió: On Martes, 23 de julio de 2013 13:04:48 Ricardo Sanz escribió: y ahora, en resumen, qué es lo que se cambia? De cara al usuario habitual de OSM, nada. De cara al cartógrafo con trastorno obsesivo-compulsivo, el estilo gráfico del mapa por defecto de osm.org puede tener *mínimos* cambios. Esto puede ser un píxel más grande, nosequé está un poquito descuadrado, etc. De cara a los de sistemas y redes, ahora las tiles se cargan desde un servidor en Francia, en vez de desde el servidor principal en Londres. Y, como ha dicho Grant, el refresco de las tiles (el tiempo que pasa desde que cambian los datos hasta que cambia el mapa) puede ser algo más grande de lo habitual. De cara a los desarrolladores, ahora el estilo gráfico es mucho más cómodo de probar y trastear (por ejemplo, con tilemill). Antes, las 7000 líneas de XML eran infumables. -- -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - ETC-SIA: http://sia.eionet.europa.eu/ Universitat Autònoma de Barcelona (SPAIN) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Semántica y rendering en OSM
Buenos días Al hilo de esto último que se está tratando en la lista acerca del renderizado, quería plantear alguna cuestión. Vengo preguntando algunas cosas últimamente a la lista porque estoy haciendo la tesis sobre la semántica en OSM. Mi idea es tratar el tema desde el punto de vista del usuario que usa los datos, es decir, tratar de conseguir de alguna manera ficheros OSM más limpios semánticamente. Veremos a dónde llego... Mi pregunta ahora (vuelvo a la carga, y gracias a todos los que me habéis venido iluminando últimamente) es sobre el renderizado en OSM, como una especie de ayuda-sin-querer a la homogeneización de tags que hace OSM para mostrar sus datos por medio de su web. Me he descargado algunas hojas de estilos [1], [2] usadas para diferentes renderizaciones de OSM y os quería hacer algunas preguntas: Si existen hojas de estilo oficiales de OSM, me refiero, las últimas versiones que se usen en los renderizados sobre todo por defecto, los que saca OSM en su web openstreetmap.org, el de mapnik y otros, por ejemplo en esto último de openstreetmap-carto que se está tratando. Y si conocéis más renderizados que se hayan hecho de OSM, pero siempre pensando en algo básico, no en una aplicación específica (de momento me interesa el caso general, luego ya iré viendo) y si estos estilos están formateados como SLD. Si estas hojas de estilo, bueno, los estilos decididos por ejemplo para el render por defecto de mapnik, son decididos unánimemente por la comunidad o cómo se decide qué estilo se asigna a cada tag. Si existe alguna wiki para discutir esto (he encontrado esta [3] pero no sé si hay más) y si esto va cambiando con el tiempo según se detectan cosas a mejorar o a incluir. Por ejemplo, me parece que la tag highway=bus_station tiene un símbolo de parada de autobús, pero las paradas que tienen solo la tag public_transport=stop_position no aparecen renderizadas en la web, es decir, no parece que a esa tag se le haya asignado el mismo estilo que a la anterior, siendo el mismo elemento, básicamente. Sabéis porqué pasa esto y si es solucionable? Me interesa especialmente cómo y porqué se decide cuando un mismo estilo o símbolo se asigna a más de una tag, sobre todo si son tags tipo clases (roads, building..), más que atributos (tunnel=yes, u otras de tipo más informativo). En algunas ocasiones esto parece que se hace porque dos tags son muy parecidas o lo mismo, como el caso de cemetery y grave_land, pero en otros casos parece más bien algo para generalizar, es decir, simbolizar igual school university y kindergarden aunque sean cosas diferentes, pero por ahorrar símbolos, o algo así. Si tenéis alguna idea de cómo se ha pensado esto, me vendría muy bien. También qué tags se deciden no renderizar y porqué, en el renderizado por defecto. Es por tema estético en el mapa? Me refiero, por si los símbolos se superponen, o por la importancia que se le de a las tags, y según eso se simbolizan o no? En este sentido, hay alguna clasificación de main tags o algo así, que siempre deban ir simbolizadas? A parte de lo que se indica en la wiki de Map Features, me refiero. ¿Sabéis qué pasa con las tags que están mal escritas? Me refiero a tags tipo higkway, highgway o cosas así, en lugar de la correcta highway, por ejemplo. Si esas entidades con tags erróneas se renderizan porque hay algún modo de asimilarlas a la tag buena o si directamente se desechan y por lo tanto la entidad no aparece renderizada, como si no existiera. Pues esto es todo, como siempre, gracias por vuestra ayuda experta! Y siento el correo larguísimo que me ha salido... saludos [1] http://wiki.openstreetmap.org/wiki/Stylesheet [2] https://github.com/mapnik/mapnik/wiki/StyleShare [3] https://trac.openstreetmap.org/query?component=mapnikstatus=!closedorder=c hangetimedesc=1max=500 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-ee] SotM Baltics: 3-4 August, Tartu: Call for Presentations
Who will go from Tallinn? I have an idea to take passengers (or being a passenger, doesn't matter). Accordingly, we can split the fuel cost. And it should be more interesting than driving alone :) Пятница, 21 июня 2013, 20:28 +04:00 от Vladimir Elistratov vladimir.elistra...@gmail.com: The State of the Map Baltics 2013 conference is calling for presentations: http://sotm-baltics.org/cfp.html The call for presentations ends on Sunday, 7th of July. All speakers who are yet to register can do it only for 11 Euro instead of regular registration price 21 Euro. ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-ee] SotM Baltics: 3-4 August, Tartu: Call for Presentations
I found that some people are planning to go on friday. I do not drink, so I will go on saturday :) I can share few places in my own car, or (if nobody wish) I can go with Margus (if he goes on saturday). Вторник, 23 июля 2013, 15:55 +03:00 от Margus Värton margusvar...@gmail.com: I am going from Tallinn using my own car. May well share few places in the car. - M - 2013/7/23 SviMik svi...@mail.ru Who will go from Tallinn? I have an idea to take passengers (or being a passenger, doesn't matter). Accordingly, we can split the fuel cost. And it should be more interesting than driving alone :) Пятница, 21 июня 2013, 20:28 +04:00 от Vladimir Elistratov vladimir.elistra...@gmail.com : The State of the Map Baltics 2013 conference is calling for presentations: http://sotm-baltics.org/cfp.html The call for presentations ends on Sunday, 7th of July. All speakers who are yet to register can do it only for 11 Euro instead of regular registration price 21 Euro. ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
[Talk-at] apropos indoor mapping
a Auch wenn die indoor ways im derzeitigen Zustand nicht korrekt bzw. a sinnvoll dargestellt werden, sind die Daten ansicht eine wertvoller a Beitrag zu osm. Es gibt bezüglich indoor mapping auch schon proposals a bzw. zugelassene tags[1]. http://derstandard.at/1373513423924/Google-startet-Indoor-Maps-nach-Oesterreich -- Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure. (Eric Allman) -- ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Rôtisserie ?
Même sans faire de science, je ne comprends pas l'obstination à vouloir prendre comme acquis ce qui n'est qu'une exception (jamais vue). Si science il y a les statistiques ont une importance avant de prendre en compte les cas ultraparticuliers (s'ils existent). La séparation des métiers de bouchers, rôtisseurs et aubergistes ça date de l'ancien régime. Le 23 juillet 2013 07:46, JB jb...@mailoo.org a écrit : ** L'article scientifique sur le tagguage des rôtisseries nous guette… Le 22.07.2013 23:22, Ab_fab a écrit : /o\ Le 22 juillet 2013 23:18, Philippe Verdy verd...@wanadoo.fr a écrit : S'il vendent les patates avec, ce que tu décrits c'est un vendeur de produits prêts à consommer. Je vois donc le poulet prédécoupé, servi en barquettes en plastique ou carton avec la dosette de mayo ou de ketchup. C'est un fast-food et plus une rôtisserie bouchère traditionnelle (qui jamais n'a de friteuse, sacrilège !). J'imagine même que les poulets ne sont mêmes pas rôtis mais prédécoupés (chicken wings, pilons, ou blancs panés), sortis encore congelés (peut-être même précuit) et fris en 5 minutes dans la même huile. Beurk ! Est-ce bien une rôtisserie avec ses tourne-broche qui rôtissent en 1 heure ? Si on arrive et que le rôtisseur prétend que ce sera prêt dans 5 minutes, je me méfierais, il vend du réchauffé ou de la friture. Dans une vraie rôtisserie; le boucher passe son temps à préparer les volailles (vidage, nettoyage, brûlage des restes de plumes au chalumeau, prédécoupage des pilons et des ailes, farçissage (pour ceux qui aiment ça, avec des fois ou mélange de chataignes, raisins et bière), ficelage, assasisonnement et brochage, mais les produits ne sortent pas du congé (on les choisis dans la vitrine avant, on ne peut pas rôtir une viande sortie du congé sans a moins 12 heures de décongélation avant au frigo, mais même ans ce cas, la préparation crûe hors assaisonnement farce et bardage se fait toujours avant congélation). Entrez dans une rôtisserie pour voir, si c'en est une, ne regardez pas que la vitrine extérieure. Le 22 juillet 2013 16:31, Sylvain Maillard sylvain.maill...@gmail.coma écrit : Je n'ai jamais été voir cette rôtisserie Lyonnaise (je bosse pas loin, j'y passerai un jour), mais je peux certifier que je connais au moins un autre exemple du même type à Marseille: une rôtisserie qui ne vent QUE des produits rôtis (et leur accompagnement de pommes de terres ... cuites elles aussi) ! aucune activité de viande froide dans ce lieu ... Le 22 juillet 2013 16:22, Philippe Verdy verd...@wanadoo.fra écrit : Ces poulets sont un poisson d'avril (regarde la date)... Puisqu'on parle de poisson, cette rôtisserie devrait être une poissonnerie. Mais si elle existe encore, ne te contente pas de la photo, et entre dedans et tu verras que le boucher prépare aussi des poulets à la commande, prêts à cuire, et que c'est même ce qui l'occupe la majorité du temps quand il ne s'occupe pas de sa rôtissoire. En entrant si tu dois attendre avant d'être servi, c'est que le boucher s'occupe justement de nettoyer, ficeler et farcir les commandes d'un autre client qui va partie avec ses plats prêts à cuire chez lui. J'insiste encore, je ne connais pas une seule rôtisserie qui ne vende QUE des produits déjà cuits (si: ceux pour la consommation sur place ou à emporter, avec frites et sodas, type KFC : le poulet ou la grillade n'est pas que cuit, il est aussi découpé prêt à consommer avec les doigts sans assiette ni couteaux, mais je n'appelle pas ça une rôtisserie mais bien un fast-food). Le 22 juillet 2013 16:08, Jean-Marc Liotier j...@liotier.org a écrit : On 22/07/2013 13:47, Philippe Verdy wrote: Le 22 juillet 2013 13:20, Yannick VOYEAUD yann...@voyeaud.org a écrit : 2) c'est l'activité unique donc c'est directement celle-ci qu'il faut tagguer. Une rôtisserie telle que je les ai vues un peu partout ne se limite pas aux poulets donc ce n'est pas l'animal qu'il faut indiquer car limitatif de l'offre. En effet souvent ils proposent des rôtis et/ou en Bretagne, entre autre, du lard (toujours cuit). Ce type d'établissement ne vends pas de produits crus. Ce n'est pas sa fonction primaire. Dernière affirmation totalement fausse. TOUTES les rôtisseries que j'ai vues (même en Bretagne) vendent aussi les produits crus, en vente directe et en commande, mais leur spécialité c'est de les vendre prêts à cuire (donc plumés, nettoyés, ficelées, bardés et farcis éventuellement). C'est bien une activité de boucherie. Je n'ai jamais vu un seul rôtisseur ne vendre que les produits cuits, il suffit de voir leurs présentoirs, on n'y voit pas que des poulets et rôtis en sac (même dans les hypermarchés). En voilà un bien connu, exemple du genre d'établissement qui ne vend que le poulet cuit et non cru: http://www.lhotellerie-restauration.fr/journal/restauration-snacking/2010-04/Humour-a-la-carte-a-la-Maison-Poulaga.htm Fast food - ou
Re: [OSM-talk-fr] Polygone géant du massif central
2013/7/22 Vincent de Château-Thierry v...@laposte.net Le 22/07/2013 22:55, Landry Breuil a écrit : Je confirme, le massif central est bien une entité a part entière, et certaines structures ont son emprise comme territoire de de compétences (je pense au CBNMC, le conservatoire botanique mais il y'en a d'autres.). Je me renseignerais pour récupérer la liste officielle des communes en faisant partie. Peut-etre peut on le transformer en relation englobant ces communes (comme les contours administratifs) au lieu d'un polygone détaché de toute autre géometrie ? Et en grattant un peu plus : http://www.data-publica.com/**opendata/2551--liste-des-** communes-du-massif-centralhttp://www.data-publica.com/opendata/2551--liste-des-communes-du-massif-central - une table excel Source DRAAF auvergne 2010 a recroiser avec d'autres ? Voilà un matériau intéressant : 4000 communes, rien que ça ! À comparer, visuellement, avec les cartes de la DATAR, au moins. Pour la mise en relation multipolygon, c'est jouable si toutes les limites des communes concernées sont là (à vérifier, au moins sur les depts 71 et 89, pas encore complets), et, bien sûr, s'il n'y a pas d'opposition au principe de tracer, ou plutôt construire cette limite. En fait, pas besoin de réinventer la roue.. je me suis rendu compte qu'au CRAIG on avait déja fait une couche emprise du massif central basée sur geofla (et du coup libre de droit evidemment). Donc on peut l'importer direct dans OSM pour mettre a jour ce polygone, si il a sa place dans la base. Mais a terme je pense qu'une relation englobant les communes serait plus appropriée... http://ids.craig.fr/geocat/apps/search/?uuid=55e9e1ac-066d-45e2-8801-cb5c46abd4f3 http://ids.craig.fr/wxs/public/wms (ou wfs) - couche CRAIG_2006_GEOFLA_MASSIF_CENTRAL Landry ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Polygone géant du massif central
Le 23/07/2013 00:06, Jérôme Amagat a écrit : mais là on ajoute la limite administrative et pas la naturel. Peut on ajouter des éléments naturels comme ici un massif, ou une plaine, plateau...? il y a une proposition pour la montagne : http://wiki.openstreetmap.org/wiki/Proposed_features/Mountains Pour ceux qui ne l'aurait pas vu, l'image of the week de la semaine dernière : http://wiki.openstreetmap.org/wiki/File:Maxbe-stubaier-beschriftung_en.png Ça vaut le coup d'avoir des polygones pour les massifs (au sens natural du terme), non ? Cordialement -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rôtisserie ?
On 23/07/2013 08:42, Philippe Verdy wrote: Même sans faire de science, je ne comprends pas l'obstination à vouloir prendre comme acquis ce qui n'est qu'une exception (jamais vue). Si science il y a les statistiques ont une importance avant de prendre en compte les cas ultraparticuliers (s'ils existent). J'avoue que mes observations sont parfaitement anecdotiques. J'attends avec impatience l'étude nationale qui s'impose ! La séparation des métiers de bouchers, rôtisseurs et aubergistes ça date de l'ancien régime. Attention à ce que tu dis - l'association va finir par avoir les corporations sur le dos... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Polygone géant du massif central
Pour ceux qui ne l'aurait pas vu, l'image of the week de la semaine dernière : http://wiki.openstreetmap.org/wiki/File:Maxbe-stubaier-beschriftung_en.png C'est intéressant de regarder la relation : http://www.openstreetmap.org/browse/relation/2127978 Elle est surtout constituée de tronçons de rivière. Après, cet exemple est beaucoup moins vaste que « Massif Central » . Cela pourrait aller pour un massif du type « Plateau des Millevaches ». Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Polygone géant du massif central
Le 23/07/2013 10:40, Vincent Calame a écrit : Pour ceux qui ne l'aurait pas vu, l'image of the week de la semaine dernière : http://wiki.openstreetmap.org/wiki/File:Maxbe-stubaier-beschriftung_en.png C'est intéressant de regarder la relation : http://www.openstreetmap.org/browse/relation/2127978 Elle est surtout constituée de tronçons de rivière. Oui, ça semble logique dans ce genre de paysage. Après, cet exemple est beaucoup moins vaste que « Massif Central » . Cela pourrait aller pour un massif du type « Plateau des Millevaches ». Je ne saisis pas bien la différence. On mappe les contours administratifs des pays aussi bien que ceux des communes et ça ne pose pas de problème. Pourquoi ce serait différent pour des massifs montagneux ou des zones naturelles d'une manière générale ? Je trouve ça bien que des toponymes comme Massif Central et Plateau des Millevaches existent dans OSM et aient une emprise. Le moteur de rendu pourra afficher l'un et/ou l'autre selon l'échelle de rendu. -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet adresses
Si on fait un point avec la norme AFNOR XPZ 10-011 de mai 1997 sur la normalisation des adresses en France, on peut essayer des dégager les clés OSM que l'on doit utiliser. L'adresse se gère sur 6 lignes avec, pour un particulier : ligne 1 : identité du destinataire (M. Mme Machin) ligne 2 : identification du point de remises (chez untel, CIDEX, ...) ligne 3 : identification de la construction (bâtiment, résidence, lotissement) ligne 4 : n° et libellé de la voie (numéro + type + libellé primaire, articles + mot directeur) ligne 5 : le lieu-dit ligne 6 : le code postal et la localité ligne 7 : Pays A partir de là, quelles clés on utilise ? voici ma proposition : addr:housename = nom du bâtiment, maison, résidence, lotissement (partie de ligne 3) addr:full = indication non normalisée 5ème maison sur la gauche après le chêne du village (partie de ligne 3) addr:housenumber = n° de la voie (partie de ligne 4) addr:street = nom de la voie (partie de ligne 4) addr:place = nom d'un territoire (Lieu-dit ?, ligne 5) addr:postcode = code postal (partie de ligne 6) addr:city = ville (partie de ligne 6) addr:country = Code pays (ligne 7 à défaut) addr:hamlet = hameau addr:suburb = banlieu (pas utilisé ici) addr:subdistrict = sousdistrict (pas utilisé ici) addr:district = district (pas utilisé ici) addr:province = province (pas utilisé ici) addr:state = état (pas utilisé ici) Qu'en pensez-vous ? - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Projet-adresses-tp5765218p5771046.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] balise des circuits vélo
Bonjour à tous, l'Association pour le Développement Touristique du Haut Vaucluse (ADTHV) m'a contacté aujourd'hui pour un projet qu'elle souhaite mener. Ils ont une application dont la prochaine évolution intégrera OpenStreetMap : escapado http://www.escapado.fr/ . Ils ont une base de données dans laquelle ils ont qualifié les panneaux indicateurs des circuits vélo de ce type http://www.provence-ventoux-comtat.com/images/panneau-signaletique-beaumes.jpg et de ce type http://www.direct-signaletique.com/I-Grande-3222-panneau-directionnel-de-position-pour-pistes-cyclables-dv21c.net.jpg . Ils souhaitent mettre ces données dans OSM. Est-ce que ce sont des données qui peuvent être versées dans OSM et qui seraient utiles et exploitables (je penses que oui). Si oui, quelles clés doit-on utiliser ? - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/balise-des-circuits-velo-tp5771048.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] balise des circuits vélo
Par ici pour les panneau indicateur d'itinéraire rando,vélo, etc. http://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost Le 23 juillet 2013 12:11, Tony Emery tony.em...@yahoo.fr a écrit : Bonjour à tous, l'Association pour le Développement Touristique du Haut Vaucluse (ADTHV) m'a contacté aujourd'hui pour un projet qu'elle souhaite mener. Ils ont une application dont la prochaine évolution intégrera OpenStreetMap : escapado http://www.escapado.fr/ . Ils ont une base de données dans laquelle ils ont qualifié les panneaux indicateurs des circuits vélo de ce type http://www.provence-ventoux-comtat.com/images/panneau-signaletique-beaumes.jpg et de ce type http://www.direct-signaletique.com/I-Grande-3222-panneau-directionnel-de-position-pour-pistes-cyclables-dv21c.net.jpg . Ils souhaitent mettre ces données dans OSM. Est-ce que ce sont des données qui peuvent être versées dans OSM et qui seraient utiles et exploitables (je penses que oui). Si oui, quelles clés doit-on utiliser ? - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/balise-des-circuits-velo-tp5771048.html Sent from the France mailing list archive at Nabble.com. ___ 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] Rôtisserie ?
En ce qui concerne les camionnettes qui font rôtissement (il y a eu une excellente émission dans capital dimanche dernier), il s'agit du même type de commerce que les pizza à emporter. D'ailleurs, un des patron disait qu'il proposait de la bouffe prête à emporter. Et je confirme qu'ils ne vendent que de la viande cuite (avec des patates, c'est presque obligatoire, toujours dixit ce patron). Donc, je dirais qu'il faut utiliser les mêmes tags que pour les camions à pizza (et à glace, et autres) et ajouter rotisserie quelque part Pour les boutiques en dur, s'il peut ne pas s'agir que de la seule activité du magasin, on pourrait préférer rotisserie=yes, comme ça on peut ajouter d'autres clés derrières. Enfin, je dis ça, je dis rien - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Rotisserie-tp5770598p5771054.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] balise des circuits vélo
Merci, c'est parfait. Du coup, ça vous semble pertinent qu'on les ajoute dans OSM ? - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/balise-des-circuits-velo-tp5771048p5771055.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] tag name sur highway
Bonjour, il me semble avoir vu passer, en son temps, un site permettant de contrler les tag:name manquants sur les highway. Je n'arrive plus retrouver son adresse. (mais peut tre ai-je tout simplement rv) :-) Auriez vous une ide ? Michel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] balise des circuits vélo
Bonjour, Am 23.07.2013 12:11, schrieb Tony Emery: Si oui, quelles clés doit-on utiliser ? Les panneaux de type Dv21 à eux seuls, comme dans tes exemples, ne servent qu'à indiquer une direction. Pour OSM ils ont donc la même importance que les panneaux D20, c'est à dire aucune. On ne taggue pas le fait qu'a un carrefour il faut tourner à droite si on veut aller à Paris, cette information se trouve dans la topologie du réseau et dans les attributs des routes. Quand ces panneaux sont utilisés pour signaler des vrais itinéraires, qui portent un nom et qui ont une certaine longueur et continuité, on les saisit comme relation avec type=route et network=lcn. Dans ce cas, les panneaux portent en général un logo et/ou une référence ou sont accompagné d'un petit panneau avec ce logo [1]. Rainer [1] http://www.bilder-hochladen.net/files/jl7r-r-02e7-jpg.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] balise des circuits vélo
Le 23 juillet 2013 12:57, Tony Emery tony.em...@yahoo.fr a écrit : Merci, c'est parfait. Du coup, ça vous semble pertinent qu'on les ajoute dans OSM ? Oui le balisage est important. Pour exemple, un souvenir de vacances www.openstreetmap.org/browse/node/2290817588 Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] balise des circuits vélo
Am 23.07.2013 12:51, schrieb Tetsuo Shima: Par ici pour les panneau indicateur d'itinéraire rando,vélo, etc. http://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost Cela indique qu'il y a un panneau qui donne la direction à prendre par les cyclistes pour se rendre à une certaine destination. Pour les rendus, en tout cas avec les outils de rendus existants, ça ne sert pas à grand chose. Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] balise des circuits vélo
Bonjour Le 23/07/2013 13:02, rainerU a écrit : On ne taggue pas le fait qu'a un carrefour il faut tourner à droite si on veut aller à Paris, Heu... : http://wiki.openstreetmap.org/wiki/Relation:destination_sign Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet adresses
Bonjour, m'est avis qu'il faut *justement* se libérer de l'adresse postale pour s'orienter finalement, comme le fait intrinsèquement Nominatim, vers des périmètres de plus en plus petits. La seule question qui reste est : faut-il accepter qu'un périmètre inférieure couvre plusieurs périmètres supérieurs == est-ce que ça se modélise avec un arbre ou un graphe ? La philosophie relaxée d'OSM oriente vers la liberté du graphe. Pour moi l'adresse n'est que la description d'un lieu, que ce soit une porte d'entrée, une boîte à lettre, l'accès à un service (limite privé / public) ou autre amenity. L'adresse postale pourrait se retrouver dans un champ spécifique, un peu comme addr:full, on aurait addr:postal:operateur car elle peut dépendre de l'opérateur de distribution du courrier (cf . CEDEX propre à La Poste). Ceci étant, même dans cette acceptation, ta proposition se tient, sauf que le lotissement *ne peut pas* être un élément du dernier niveau (housename / housenumber) mais doit se trouver dans addr:place, par exemple. mes 0.02 € A+ Le 23 juillet 2013 12:01, Tony Emery tony.em...@yahoo.fr a écrit : Si on fait un point avec la norme AFNOR XPZ 10-011 de mai 1997 sur la normalisation des adresses en France, on peut essayer des dégager les clés OSM que l'on doit utiliser. L'adresse se gère sur 6 lignes avec, pour un particulier : ligne 1 : identité du destinataire (M. Mme Machin) ligne 2 : identification du point de remises (chez untel, CIDEX, ...) ligne 3 : identification de la construction (bâtiment, résidence, lotissement) ligne 4 : n° et libellé de la voie (numéro + type + libellé primaire, articles + mot directeur) ligne 5 : le lieu-dit ligne 6 : le code postal et la localité ligne 7 : Pays A partir de là, quelles clés on utilise ? voici ma proposition : addr:housename = nom du bâtiment, maison, résidence, lotissement (partie de ligne 3) addr:full = indication non normalisée 5ème maison sur la gauche après le chêne du village (partie de ligne 3) addr:housenumber = n° de la voie (partie de ligne 4) addr:street = nom de la voie (partie de ligne 4) addr:place = nom d'un territoire (Lieu-dit ?, ligne 5) addr:postcode = code postal (partie de ligne 6) addr:city = ville (partie de ligne 6) addr:country = Code pays (ligne 7 à défaut) addr:hamlet = hameau addr:suburb = banlieu (pas utilisé ici) addr:subdistrict = sousdistrict (pas utilisé ici) addr:district = district (pas utilisé ici) addr:province = province (pas utilisé ici) addr:state = état (pas utilisé ici) Qu'en pensez-vous ? - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Projet-adresses-tp5765218p5771046.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name sur highway
Bonjour,
Tu peux utiliser le calque noname sur Osmose (appuyer sur le plus à droite)
:
http://osmose.openstreetmap.fr/fr/map/?zoom=12lat=45.04896lon=-0.0697layers=B0TFFitem=0level=1,2,3
Il est aussi possible de le mettre dans JOSM, peut-être avec :
tms:
http://layers.openstreetmap.fr/tiles/renderer.py/noname/{zoom}/{x}/{y}.png
--
Jean-Baptiste Holcroft
Le 23 juillet 2013 13:02, mides.map mides@gmail.com a écrit :
**
Bonjour,
il me semble avoir vu passer, en son temps, un site permettant de
contrôler les tag:name manquants sur les highway.
Je n'arrive plus à retrouver son adresse. (*mais peut être ai-je tout
simplement rêvé*) :-)
Auriez vous une idée ?
Michel
___
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] Rôtisserie ?
On 23/07/2013 12:54, Tony Emery wrote: Donc, je dirais qu'il faut utiliser les mêmes tags que pour les camions à pizza (et à glace, et autres) et ajouter rotisserie quelque part amenity=fast_food cuisine=rotisserie ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mémoire recherche IGN...
Le 22 juillet 2013 17:00, Christian Quest cqu...@openstreetmap.fr a écrit : Le mémoire de Carmen Brando et disponible sur http://recherche.ign.fr/labos/cogit/cv.php?prenom=Carmennom=Brando Ce travail de thèse porte sur l'édition collaborative de données géographiques et plus particulièrement sur la gestion de la qualité d'un tel contenu afin de permettre que des prises de décision s'appuient dessus. Talk-fr@openstreetmap.org Absolument génial, super intéressant, tout le monde devrait l'avoir lu ! Mais certes, 245 pages, et c'est pas du powerpoint... Moi j'ai raccourci et j'ai pratiquement rien lu de Coalla, où on arrive à du lourd, et j'attends de voir ce que tout cela va devenir. Pour le reste (c'est à dire le début, c'est à dire les 75 premières pages tout de même), excellentes approches, où les thèmes abordés sont remplis de pertinence, même si je ne suis pas toujours d'accord ou que j'aurais dit autrement mais je suis bien évidemment pas Docteur de l'Université Paris Est. Bravo pour aborder dans un même continuum IGN / OSM, super génial de tenir compte la problématique de l'usage final, hyper formidable pour la simplicité générale du vocabulaire employé, bravo bravo bravo pour questionner la qualité, etc. On avance. -- Les dérives de rue : Étude de main sur la terre artistique en pleine chaleurhttp://drivrsdu.fr/etude-de-main-sur-la-terre-artistique-en-pleine-chaleur/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name sur highway
Oups, j'avais oublié de regarder ce qu'il se passait du coté du LayerSwitcher,
je dois avoir besoin de vacances.
Toujours est il, merci pour le coup de pouce ;-)
Michel
Le 23 juillet 2013 13:54, Jean-Baptiste Holcroft jb.holcr...@gmail.com a
écrit :
Bonjour,
Tu peux utiliser le calque noname sur Osmose (appuyer sur le plus à
droite) :
http://osmose.openstreetmap.fr/fr/map/?zoom=12lat=45.04896lon=-0.0697layers=B0TFFitem=0level=1,2,3
Il est aussi possible de le mettre dans JOSM, peut-être avec :
tms:
http://layers.openstreetmap.fr/tiles/renderer.py/noname/{zoom}/{x}/{y}.png
--
Jean-Baptiste Holcroft
Le 23 juillet 2013 13:02, mides.map mides@gmail.com a écrit :
**
Bonjour,
il me semble avoir vu passer, en son temps, un site permettant de
contrôler les tag:name manquants sur les highway.
Je n'arrive plus à retrouver son adresse. (*mais peut être ai-je tout
simplement rêvé*) :-)
Auriez vous une idée ?
Michel
___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
