[talk-ph] Funny usability issue
Just sharing something that happened during one of my osm session with newbies. Using P2, asked one user to zoom in closer. He/she then tried clicking the big OSM logo in the upperleft corner of the website. ;) ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Fwd:[OSM-talk] Licence redaction ready to begin
Fyi, license redaction will start july 11, 2012. -- Forwarded message -- From: Richard Fairhurst rich...@systemed.net Date: Jul 10, 2012 4:48 AM Subject: [OSM-talk] Licence redaction ready to begin To: t...@openstreetmap.org, d...@openstreetmap.org, annou...@openstreetmap.org Hello all, I'm pleased to announce that the licence change bot is ready to get underway. Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL) - in other words, they will no longer be accessible. We are expecting to begin on _Wednesday_ (9th July) assuming a couple of final setup details are completed by then. The bot will run in the following order: 1. Ireland 2. UK 3. Western Europe 4. North America 5. Australia 6. rest of the world Once it is complete, we will be ready to distribute data under the ODbL and we'll advise of that with a separate announcement. The final pre-redaction dataset available under CC-BY-SA has now been generated at http://planet.openstreetmap.**org/planet-120704.osm.bz2http://planet.openstreetmap.org/planet-120704.osm.bz2. Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. Test runs have shown that the bot is functioning as we want it to, but we will of course be monitoring its progress. We are currently expecting it to take in the order of one month to complete; given the many variables I'm afraid we can't give a more precise steer yet, but we'll aim to keep everyone updated as it runs (via the announce@ and talk@ lists). There will be _no_ API outage and no other interruption to editing. When the bot is running in your area, please do save your edits frequently to minimise the likelihood of conflict. (Separate messages are going to talk-ie@ and talk-gb@ as the first two areas to be affected. Please do forward and translate this for your local mailing lists.) As you know we were expecting this to start just after 1st April and the complexity of the task incurred the delay. Thank you all very much for your patience in waiting for it to get underway. Thank you especially to those who have contributed to the code, whether by patches, suggestions or just helping to firm up the workings. Richard for the OSMF board __**_ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[OSM-talk] Funny usability issue
Just sharing something that happened during one of my osm session with newbies. Using P2, asked one user to zoom in closer. He/she then tried clicking the big OSM logo in the upperleft corner of the website. ;) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funny usability issue
On Mon, Jul 9, 2012 at 6:09 AM, maning sambale emmanuel.samb...@gmail.comwrote: Just sharing something that happened during one of my osm session with newbies. Using P2, asked one user to zoom in closer. He/she then tried clicking the big OSM logo in the upperleft corner of the website. ;) So use JOSM instead. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Licence redaction ready to begin
Hello all, I'm pleased to announce that the licence change bot is ready to get underway. Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL) - in other words, they will no longer be accessible. We are expecting to begin on _Wednesday_ (9th July) assuming a couple of final setup details are completed by then. The bot will run in the following order: 1. Ireland 2. UK 3. Western Europe 4. North America 5. Australia 6. rest of the world Once it is complete, we will be ready to distribute data under the ODbL and we'll advise of that with a separate announcement. The final pre-redaction dataset available under CC-BY-SA has now been generated at http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. Test runs have shown that the bot is functioning as we want it to, but we will of course be monitoring its progress. We are currently expecting it to take in the order of one month to complete; given the many variables I'm afraid we can't give a more precise steer yet, but we'll aim to keep everyone updated as it runs (via the announce@ and talk@ lists). There will be _no_ API outage and no other interruption to editing. When the bot is running in your area, please do save your edits frequently to minimise the likelihood of conflict. (Separate messages are going to talk-ie@ and talk-gb@ as the first two areas to be affected. Please do forward and translate this for your local mailing lists.) As you know we were expecting this to start just after 1st April and the complexity of the task incurred the delay. Thank you all very much for your patience in waiting for it to get underway. Thank you especially to those who have contributed to the code, whether by patches, suggestions or just helping to firm up the workings. Richard for the OSMF board ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence redaction ready to begin
We are expecting to begin on _Wednesday_ (9th July) 11th July. You knew what I meant really. :) Yours in a state of temporary temporal confusion Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence redaction ready to begin
On Mon, Jul 9, 2012 at 1:46 PM, Richard Fairhurst rich...@systemed.netwrote: Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL) - in other words, they will no longer be accessible. We are expecting to begin on _Wednesday_ (9th July) assuming a couple of final setup details are completed by then. 9 July is today (Monday). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence redaction ready to begin
On 07/09/2012 04:46 PM, Richard Fairhurst wrote: Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. What methods will still exist to get redacted data? * Old planet files (or other old copies of data) * Full history file? * Anything else? Just curious, --Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence redaction ready to begin
The OSMF has commited to keeping the last planet files (both normal and history) available on CC by-SA 2.0 terms. I haven't heard of any change in this policy so I assume it is still current. Simon PS: I personally consider that a big mistake, but then that is just me. Am 09.07.2012 23:00, schrieb Andrew Guertin: On 07/09/2012 04:46 PM, Richard Fairhurst wrote: Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. What methods will still exist to get redacted data? * Old planet files (or other old copies of data) * Full history file? * Anything else? Just curious, --Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Fwd: [OSM-talk] Licence redaction ready to begin
Ter info. -- Forwarded message -- From: Richard Fairhurst rich...@systemed.net Date: Mon, Jul 9, 2012 at 10:46 PM Subject: [OSM-talk] Licence redaction ready to begin Hello all, I'm pleased to announce that the licence change bot is ready to get underway. Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL) - in other words, they will no longer be accessible. We are expecting to begin on _Wednesday_ (11th July) assuming a couple of final setup details are completed by then. The bot will run in the following order: 1. Ireland 2. UK 3. Western Europe 4. North America 5. Australia 6. rest of the world Once it is complete, we will be ready to distribute data under the ODbL and we'll advise of that with a separate announcement. The final pre-redaction dataset available under CC-BY-SA has now been generated at http://planet.openstreetmap.**org/planet-120704.osm.bz2http://planet.openstreetmap.org/planet-120704.osm.bz2. Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. Test runs have shown that the bot is functioning as we want it to, but we will of course be monitoring its progress. We are currently expecting it to take in the order of one month to complete; given the many variables I'm afraid we can't give a more precise steer yet, but we'll aim to keep everyone updated as it runs (via the announce@ and talk@ lists). There will be _no_ API outage and no other interruption to editing. When the bot is running in your area, please do save your edits frequently to minimise the likelihood of conflict. (Separate messages are going to talk-ie@ and talk-gb@ as the first two areas to be affected. Please do forward and translate this for your local mailing lists.) As you know we were expecting this to start just after 1st April and the complexity of the task incurred the delay. Thank you all very much for your patience in waiting for it to get underway. Thank you especially to those who have contributed to the code, whether by patches, suggestions or just helping to firm up the workings. Richard for the OSMF board ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] Fwd: [OSM-talk] Licence redaction ready to begin
Here's the original announcement by Richard (note the tiny Freudian slip wrt the date). As soon as the bot starts running, I'll stop consuming diffs (that is syncing with the OSM database) for cleanmap et al. In other words remapping happening later will not get reflected in the data. I'll generate a final version of the road list I mentioned earlier on too. SImon Original-Nachricht Betreff:[OSM-talk] Licence redaction ready to begin Datum: Mon, 09 Jul 2012 21:46:43 +0100 Von:Richard Fairhurst rich...@systemed.net An: t...@openstreetmap.org, d...@openstreetmap.org, annou...@openstreetmap.org Hello all, I'm pleased to announce that the licence change bot is ready to get underway. Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL) - in other words, they will no longer be accessible. We are expecting to begin on _Wednesday_ (9th July) assuming a couple of final setup details are completed by then. The bot will run in the following order: 1. Ireland 2. UK 3. Western Europe 4. North America 5. Australia 6. rest of the world Once it is complete, we will be ready to distribute data under the ODbL and we'll advise of that with a separate announcement. The final pre-redaction dataset available under CC-BY-SA has now been generated at http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. Test runs have shown that the bot is functioning as we want it to, but we will of course be monitoring its progress. We are currently expecting it to take in the order of one month to complete; given the many variables I'm afraid we can't give a more precise steer yet, but we'll aim to keep everyone updated as it runs (via the announce@ and talk@ lists). There will be _no_ API outage and no other interruption to editing. When the bot is running in your area, please do save your edits frequently to minimise the likelihood of conflict. (Separate messages are going to talk-ie@ and talk-gb@ as the first two areas to be affected. Please do forward and translate this for your local mailing lists.) As you know we were expecting this to start just after 1st April and the complexity of the task incurred the delay. Thank you all very much for your patience in waiting for it to get underway. Thank you especially to those who have contributed to the code, whether by patches, suggestions or just helping to firm up the workings. Richard for the OSMF board ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[OSM-talk-ie] Licence redaction ready to begin
Hello all, This is a special heads-up to the British and Irish mailing lists that the licence change bot is ready to get underway, starting in our areas. Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL). We are expecting to begin on _Wednesday_ (11th July) assuming a couple of final setup details are completed by then. The bot will run with Ireland first of all, then the UK, then the rest of the world. Consequently please expect to see a few changes to your local area later this week. There will be _no_ API outage and no other interruption to editing, but please do save your edits frequently to minimise the likelihood of conflict. Once the bot has finished the UK we'll send a further message to both these areas. When the whole world is complete, we will be ready to distribute data under the ODbL and we'll advise of that with a separate announcement. The final pre-redaction dataset available under CC-BY-SA has now been generated at http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. Test runs have shown that the bot is functioning as we want it to, but we will of course be monitoring its progress. We are currently expecting it to take in the order of one month to complete the whole world; given the many variables I'm afraid we can't give a more precise steer yet, but we'll aim to keep everyone updated as it runs. As you know we were expecting this to start just after 1st April and the complexity of the task incurred the delay. Thank you all very much for your patience in waiting for it to get underway. Thank you especially to those who have contributed to the code, whether by patches, suggestions or just helping to firm up the workings. Richard for the OSMF board ___ Talk-ie mailing list Talk-ie@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ie
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 02:52:02AM +0200, Stephan Wolff wrote: Ich sehe durchaus die von den anderen Beteiligten genannten Probleme bei der Relationserstellung, -pflege und -auswertung. Insbesondere bleibt das Henne-Ei-Problem zwischen Softwareanpassung und Relationsnutzung. Trotzdem betrachte ich die Zusammenfassung mehrerer Teilobjekte in Relationen als Zukunftsmodell von OSM. Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen Objekten in der Art und Weise, wie Relationen das tun. Was wir brauchen sind Objekte, die der Mapper verstehen kann, die sein Bild der Welt umsetzbar machen. Abstrakte Punkte für POIs, abstrakte Linien für Straßen, das geht grad noch so. Aber das Konzept Multipolygon ist schon schwierig genug, wenn man es dann noch auf eine ungeeignete andere Abstraktion aufsetzt, also die Relationen, dann ist das nicht mehr handhabbar. Das zeigt die Praxis jeden Tag. Man könnte natürlich alles auf die Tools schieben und sagen, dass die Tools (also Editor, Renderer, usw.) halt diese Objekte, die ein User verstehen soll, auf Basis von Nodes, Ways, und Relations darstellen sollen. Das habe ich eine Weile auch gedacht, dass das funktioniert. Bei einfachen Objekten klappt das vielleicht. Nicht aber bei Relationen. Eine Relation, die so halber wie eine Multipolygon-Relation aussieht, aber kein gültiges Multipolygon erzeugt läßt sich nicht auf einem höheren Abstraktionsgrad als Multipolygon darstellen. Will man auf dem höheren Abstraktionsgrad arbeiten, so muss sichergestellt sein, dass die Relation darunter immer gültig ist, immer gewissen Strukturvorraussetzungen genügt. Das können wir aber nicht, weil einzig die zentrale OSM-Datenbank diese Gültigkeit sicherstellen könnte. Und die tut das nicht. Und wenn man den Schritt geht, dass man in höheren Abstraktionen denkt, die die Welt näher am User modellieren, dann gibt es eigentlich auch keinen Grund mehr, das auf Relationen aufzubauen, weil die komplex sind und schwierig und langsam zu verarbeiten. Dann sollte man besser eine Datenstruktur finden, die dem Modell angepasst ist und von der man sich sehr genau überlegt hat, wie man sie effizient verarbeiten kann. Ich sehe Relationen als eine Möglichkeit, Prototypen zu bauen. Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder ÖPNV-Linien-Objekte. Wir können mit Relationen uns solchen Objekten annähern und ausprobieren, wie sie vielleicht aussehen könnten. Aber irgendwann müssen wir den Schritt tun und sagen: Okay, diese Art der Relation ist so wichtig, dass wir ein echtes Objektmodell dafür machen müssen, das genau dieses Modell abbildet und definiert und sauber zu verarbeiten ist. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo Jochen, On 09.07.2012 08:49, Jochen Topf wrote: Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen Objekten in der Art und Weise, wie Relationen das tun. Menschen denken durchaus in Relationen. Wenn jemand sagt, dass der Laden X in der Hauptstrasse 47 liegt, dann meint er nichts anderes als: das Shop-Objekt mit name=X ist Mitglied der Building-Relation mit addr:street=Hauptstrasse und addr:housenumber=47. Nichtsdestotrotz, da gebe ich dir recht, haben die meisten Menschen Probleme, wenn es darum geht, diese Denkweise in Datenstrukturen umzusetzen. Relationen sind eine effiziente Methode der Datenmodellierung. Sie vermeiden Redundanz, sind änderungsfreundlich und für Anwendungen einfach zu verarbeiten. Nicht umsonst sind relationale Datenbanken seit Jahrzehnten beliebt und verbreitet. Die Alternative zu Relationen ist ein Bottom-Up-Ansatz, bei dem die gemeinsamen Eigenschaften an jedes Element gehängt werden und die Elemente über eine gemeinsame Kennung zusammengefasst werden. Darüber, dass wir das nicht wollen, herrscht sicher Konsens. Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder ÖPNV-Linien-Objekte. Das sind nichts anderes als Relationen mit fest vorgegebenen Eigenschaften und Regeln. So etwas kann und soll man in den Editoren realisieren. In der Datenbank sollten wir uns die Flexibilität des Relationskonzepts erhalten. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder ÖPNV-Linien-Objekte. Das sind nichts anderes als Relationen mit fest vorgegebenen Eigenschaften und Regeln. So etwas kann und soll man in den Editoren realisieren. In der Datenbank sollten wir uns die Flexibilität des Relationskonzepts erhalten. Aus meiner Sicht bedeutet die Einführung eines Multipolygon-Objekts nicht automatisch die Abschaffung der Relationen. Relationen sind so etwas wie eine eierlegende Wollmilchsau. Man kann fast alles damit modellieren. Im Umfeld von OSM, wo es keine genauen Reglen für die Modellierung (ich meine das Taggen) gibt, ist dies auf Dauer nicht handhabbar. Wenn man sich allein die unterschiedlichen Tagmöglichkeiten für Multipolygone anschaut (nur die Wege getaggt, nur das MP getaggt, beides getaggt, Wege getaggt aber unterschiedlich etc.), dann wird schnell klar, das jede Applikation hier Problem bekommen muss, da nicht wirklich klar ist, was denn nun gültig ist und was nicht. Die Umsetzung einer eierlegenden Wollmilchsau führt immer zu großen Problemen mit der Komplexität, wodurch das eigentliche Konzept nicht mehr handhabbbar ist. Also kann ich Jochens Sicht nur zustimmen: Relationen sind zur Zeit eine gute Variante um Modellierungen auszuprobieren. Auf Dauer muss man aber die wesentlichen Konzepte festlegen und in der Datenbank sicherstellen. Eine scheinbare Einschräkung, die sich aber lohnt. Dadurch können sich Editoren und andere Applikationen auf die Implementierung einer Variante festlegen und die wertvolle Ressource Zeit kann auf sinnvollere Tätigkeiten verwendet werden. WanMil Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 09:53:38AM +0200, Rainer Kluge wrote: On 09.07.2012 08:49, Jochen Topf wrote: Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen Objekten in der Art und Weise, wie Relationen das tun. Menschen denken durchaus in Relationen. Wenn jemand sagt, dass der Laden X in der Hauptstrasse 47 liegt, dann meint er nichts anderes als: das Shop-Objekt mit name=X ist Mitglied der Building-Relation mit addr:street=Hauptstrasse und addr:housenumber=47. Nichtsdestotrotz, da gebe ich dir recht, haben die meisten Menschen Probleme, wenn es darum geht, diese Denkweise in Datenstrukturen umzusetzen. Relationen sind eine effiziente Methode der Datenmodellierung. Sie vermeiden Redundanz, sind änderungsfreundlich und für Anwendungen einfach zu verarbeiten. Nicht umsonst sind relationale Datenbanken seit Jahrzehnten beliebt und verbreitet. Die Alternative zu Die Relationen, die wir bei OSM haben, haben NICHTS mit den Relationen zu tun, wie man sie von relationalen Datenbanken kennt. Die Relationen bei OSM sind eben keine effiziente Methode der Datenmodellierung, sie sind nicht änderungsfreundlich und sie sind nicht einfach zu verarbeiten. Relationen ist ein Bottom-Up-Ansatz, bei dem die gemeinsamen Eigenschaften an jedes Element gehängt werden und die Elemente über eine gemeinsame Kennung zusammengefasst werden. Darüber, dass wir das nicht wollen, herrscht sicher Konsens. Die Alternative zu Relationen sind neue Datenstrukturen, die genau das machen, was wir wollen. Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder ÖPNV-Linien-Objekte. Das sind nichts anderes als Relationen mit fest vorgegebenen Eigenschaften und Regeln. So etwas kann und soll man in den Editoren realisieren. In der Datenbank sollten wir uns die Flexibilität des Relationskonzepts erhalten. Wie ich beschrieben habe, funktioniert dieser Ansatz nicht. Du kannst nicht sicherstellen, dass alle Editoren die Daten immer in gültiger Weise editieren, solange das die zentrale Datenbank nicht macht. Dadurch wird jeder Editor und jeder User dieser Editoren aber immer mit der Möglichkeit konfrontiert, dass die Daten ungültig sind, was diese fest vorgegebenen Eigenschaften und Regeln angeht. Und damit sind die dann eben nicht fest vorgegebenen. Und damit haben wir das durcheinander, dass wir jetzt haben. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Sorry II
Am 08.07.2012 23:33, schrieb Jochen Topf: On Sun, Jul 08, 2012 at 09:37:10PM +0200, Jan Tappenbeck wrote: nachdem sich innerhalb eines Tages die Top-Anwendungsentwickler schon zu Wort gemeldet haben und sich im großen und ganzen Positiv geäußert haben muss ich eine ergänzende Frage stellen. Zu was genau haben sich die Top-Anwendungsentwickler (wer ist das?) positiv geäußert? Zu Relationen? Also ich lese die Diskussion eigentlich so, dass alle, die das schonmal gemacht haben, Relationen für schwierig in der Handhabung halten und dass man sie eher vermeiden sollte. Jochen Hallo Jochen, das war wohl etwas spät gestern Abend. Mit Top-Anwendungsentwicklern meine ich das sich nicht irgendwer dazu geäußert hat sondern diejenigen die primär schön etwas größeres mit Relationen auf die Beine gestellt haben. Positiv geäußert war dann wohl etwas daneben. Du hast recht - die meisten sehen in der Auswertung von Relationen harte Nüsse die geknackt werden müssen. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Vermutlich ist der richtige Ansatz genau das Zwischending: Relationen weiterhin erlauben, aber etablierte Relationentypen nach und nach in die API fest aufnehmen. Das viel berühmte freie Tagging-Schema ist klasse, funktioniert aber eben auch nur, solange die Freiheit sich darauf beschränkt, nicht standardisierte Bereiche nach bestem Wissen und Gewissen frei einzutragen; es ist eben nicht gleichzusetzen mit Anarchie. Wenn wir Relationen erlauben, ist das das äquivalent zum freien Tagging auf der Ebene der Datenstrukturen: Sie erlauben Dinge, die kaum möglich wären ohne: rollenbesetzte Bezüge zwischen verschiedenen Objekten in OSM nur über Tags abzubilden wäre ziemlich gruselig. Aber Standards sollten sich eben auch da bilden; und wenn diese soweit festliegen, dass sie zum allgemeinen Konsens gehören, dann spricht meines Erachtens nach nichts dagegen, diese auch fest in der API einzubauen. Für wäre dabei als erstes ein Flächentyp fällig, der Multipolygone und einfache Polygone unterstützt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kreuzungen finden mit Nominatim?
Hallo! Gibt es eine Möglichkeit, mit Nominatim die Kreuzung zweier Straßen zu finden? Danke Grüße Marian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 08:49, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 02:52:02AM +0200, Stephan Wolff wrote: Ich sehe durchaus die von den anderen Beteiligten genannten Probleme bei der Relationserstellung, -pflege und -auswertung. Insbesondere bleibt das Henne-Ei-Problem zwischen Softwareanpassung und Relationsnutzung. Trotzdem betrachte ich die Zusammenfassung mehrerer Teilobjekte in Relationen als Zukunftsmodell von OSM. Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen Objekten in der Art und Weise, wie Relationen das tun. Das glaube ich nicht. In OSM besteht eine Straße meist aus mehreren Objekten mit gleichem Namen und unterschiedlichen Eigenschaften. Kein Mensch würde sagen, dass es drei hintereinanderliegende Goethestraßen gibt. Fast jeder beschreibt eine Straße, deren Abschnitte sich z.B. in der erlaubten Geschwindigkeit unterscheiden. Das gleiche gilt für andere zusammengesetzte Objekte. Natürlich gibt es in OSM abstrakte Relationsobjekte (z.B. Abbiegerelationen) oder schlecht umsetzbare Konzepte (z.B. Buslinien mit mehreren Varianten). Aber um solche Relationen geht es in Jans Frage nicht. Was wir brauchen sind Objekte, die der Mapper verstehen kann, die sein Bild der Welt umsetzbar machen. +1 Man könnte natürlich alles auf die Tools schieben und sagen, dass die Tools (also Editor, Renderer, usw.) halt diese Objekte, die ein User verstehen soll, auf Basis von Nodes, Ways, und Relations darstellen sollen. Im idealen Renderer sollte es keinen Unterschied machen, wie ein Objekt OSM-intern angelegt ist. Ein Split eines Weges sollte keine Auswirkung auf die Darstellung des Namens haben. Eine Suche würde zu einem realen Objekt genau einen Treffer bei OSM liefern. Im idealen Editor könnten zusammengesetzte Objekte durch Vererbung der Tags fast transparent sein, so dass der Mapper bei Änderungen der Geometrie nichts von der internen Struktur sieht. Das ist alles natürlich sehr mühsam umzusetzten. Und wenn man den Schritt geht, dass man in höheren Abstraktionen denkt, die die Welt näher am User modellieren, dann gibt es eigentlich auch keinen Grund mehr, das auf Relationen aufzubauen, weil die komplex sind und schwierig und langsam zu verarbeiten. Dann sollte man besser eine Datenstruktur finden, die dem Modell angepasst ist und von der man sich sehr genau überlegt hat, wie man sie effizient verarbeiten kann. Wie würde sich die Datenstruktur von einer Relation unterscheiden? Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo, On 07/09/12 12:02, Peter Wendorff wrote: Vermutlich ist der richtige Ansatz genau das Zwischending: Relationen weiterhin erlauben, aber etablierte Relationentypen nach und nach in die API fest aufnehmen. Ja, das ist auch das, was vermutlich passieren wird. Ein spezieller Flaechen- und vielleicht sogar ein spezieller Routen-Datentyp in der API 0.7, dann fallen schonmal 90% aller Relationen raus, und wenn die sich mengenmaessig dann wieder aufrappeln, erfindet man wieder was neues... Ein Problem, das wir haben, ist leider, dass OSM aufgrund der immer groesseren Landschaft von Anwendungen immer statischer wird. Die Zeit, in der man mal eben von einem auf den andren Tag die API inkompatibel veraendern konnte, ist leider vorbei. Jeder neue Datentyp, den wir erfinden, muss in Dutzenden von Applikationen unterstuetzt werden, wenn es nicht ein Riesengejammer geben soll. Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein area oder route oder turnrestriction auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding ganz weg. Eventuell sollte man alle diese neuen Datentypen dann in irgendwas gleichartiges kapseln, so dass eine Software, die den Datentyp nicht versteht, nicht total aufgeschmissen ist *duck* Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 9. Juli 2012 12:50 schrieb Stephan Wolff s.wo...@web.de: Das glaube ich nicht. In OSM besteht eine Straße meist aus mehreren Objekten mit gleichem Namen und unterschiedlichen Eigenschaften. Kein Mensch würde sagen, dass es drei hintereinanderliegende Goethestraßen gibt. wirklich einfach ist das aber trotzdem nicht überall. Klar, wenn es sich um hintereinanderliegende Straßensegmente handelt, die z.B. wegen unterschiedlichem Belag oder einer Abbiegerestriktion etc. aufgesplittet wurden, dann würde ein Mensch die zusammenfassen. Habe aber hier in historischen Stadtkernen in letzter Zeit öfters den Fall erlebt, dass mehrere Straßen denselben Namen hatten, weil auch z.B. Stichstraßen denselben Namen bekommen hatten, oder weil sich die Straße geteilt und nach einigen Häusern wieder verbunden hat. Dreimal derselbe Name einer Straße an einer Kreuzung mit 3 Straßen kommt durchaus in der Realität vor und ist nicht mehr ganz eindeutig (eine Straße ist m.E. für einen Menschen linear, wenn Stiche oder Aufsplittungen vorkommen wird man nicht mehr unbedingt von *einer* Straße sprechen bzw. zumindest auf diesen besonderen Umstand hinweisen). Konkretes Beispiel: http://www.openstreetmap.org/browse/way/170356491 http://www.openstreetmap.org/browse/way/170431940 Im idealen Renderer sollte es keinen Unterschied machen, wie ein Objekt OSM-intern angelegt ist. Ein Split eines Weges sollte keine Auswirkung auf die Darstellung des Namens haben. +1, da wäre es wünschenswert, wenn Segmente von Straßen für die Darstellung des Namens im Renderer (bzw. der Datengrundlage) zusammengefügt würden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Jochen Topf joc...@remote.org wrote: Die Alternative zu Relationen sind neue Datenstrukturen, die genau das machen, was wir wollen. Das hatten wir ja auch beim Hacking WE im Umfeld Polygondatentyp diskutiert. Was wir eigentlich brauchen ist ein Datentyp für Flächen, Routen und Abbiegeregeln. Die bisherigen Relationen verführen die Leute IMO Dinge zu modellieren, die hinterher kein Mensch mehr auswerten kann. Gruss Sven -- This APT has Super Cow Powers. (apt-get --help on debian woody) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Frederik Ramm wrote: Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein area oder route oder turnrestriction auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding ganz weg. Das schließt aber nicht aus, dass man serverseitig eine gewisse Qualität von Relationen erzwingt. So könnte man z.B. bei Multipoligon-Relationen auf dem Server direkt deren Plausibilität prüfen und wenn das nicht hinhaut, dann direkt ablehnen. Genau so kann man die zunehmende Kreativität mit Relationen so etwas dämpfen. Was der Server nicht kennt, das kann auch nicht hochgeladen werden -- Fertig. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzungen finden mit Nominatim?
Hi Marian, soweit ich das beurteilen kann, klappt das (noch) nicht http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview Ich glaub die Leute von frankfurt-gestalten.de hatten mal ein ähnliches Problem, bin mir aber nicht sicher ob/wie die es gelöst hatten. Matthias Am 09.07.2012 12:32, schrieb Marian Steinbach: Hallo! Gibt es eine Möglichkeit, mit Nominatim die Kreuzung zweier Straßen zu finden? Danke Grüße Marian ___ 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] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 01:20:51PM +0200, Frederik Ramm wrote: Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein area oder route oder turnrestriction auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding ganz weg. Eventuell sollte man alle diese neuen Datentypen dann in irgendwas gleichartiges kapseln, so dass eine Software, die den Datentyp nicht versteht, nicht total aufgeschmissen ist *duck* Genau aus diesem Grund finde ich Relationen so wie sie sind eigentlich eine geniale Idee, einfach und flexibel. (Aauch in der Verarbeitung, wenn man sich mal eine Minute von osm2pgsql lösen kann.) Wir haben mit Relationen keine technisches Problem sondern ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung von Objekten in der DB explizit mit Relationen modeliert werden müsse und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich dass OSM eine spatiale DB ist und keine relationale. Anstatt also zu überlegen, was man den Leuten alles verbieten müsste, sollten wir die Mapper besser darüber aufklären, warum ihre Relationsmania überflüssig und gefährlich ist. Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen sollte ist die: ist die Relation wirklich nötig oder ist es möglich, meine Information auch in Form von einfachen Tags und geografischen Beziehungen in der DB unterzubringen. Die Antwort auf diese Frage ist eindeutig, dass es möglich ist, und damit sollte die Sache erledigt sein. Ähnliches gilt für Anwendungen, die hier in letzter Zeit diskutiert wurden. (Ich denke mit Schaudern an den Thread zum Eisenbahn-Tagging.) Redundanz ist kein Argument für Relationen. Ich weiss nicht, wie man es anders in einer spatialen Datenbank verarbeiten kann ist kein Argument für Relationen. Ich kann die Daten so leichter runterladen ist kein Argument für Relationen. Das einzige relevante Argument ist: es geht nicht anders[1]. Und das sollten wir allen Mappern klar machen. Wie es eine ungeschriebene on the ground-Regel gibt, sollten wir eine vermeide Relationen-Regel einführen und so oft wie möglich zitieren. Wenn wir es schaffen mehr Selbstdisziplin zu üben und Relationen auf eine Handvoll klar definierter Anwendungsfälle zu begrenzen, braucht es keine Änderung an der API. Gruss Sarah [1] Und bevor man mich jetzt zu sehr beim Wort nimmt: das schliesst auch die Fälle ein, wo es zwar anders ginge, aber nur von hinten durch die Brust etc. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 04:26:26PM +0200, Manuel Reimer wrote: Frederik Ramm wrote: Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein area oder route oder turnrestriction auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding ganz weg. Das schließt aber nicht aus, dass man serverseitig eine gewisse Qualität von Relationen erzwingt. So könnte man z.B. bei Multipoligon-Relationen auf dem Server direkt deren Plausibilität prüfen und wenn das nicht hinhaut, dann direkt ablehnen. Genau so kann man die zunehmende Kreativität mit Relationen so etwas dämpfen. Was der Server nicht kennt, das kann auch nicht hochgeladen werden -- Fertig. Das Problem ist hier wieder die Komplexität und ungeeignete Datenhaltung der Relationen. Es wäre für den Server mit erheblichem Aufwand verbunden, Multipolygon-Relationen auf Korrektheit zu prüfen, genauso wie das für jeden anderen auch schwierig ist. Das dem zentralen Server aufzubürden ist sehr problematisch. D.h. wir brauchen m.E. erst eine bessere Datenstruktur, die leichter auf Korrektheit geprüft werden kann. Insbesondere muss diese Datenstruktur die Eigenschaft haben, dass es eine genau definierte Liste an Operationen gibt, die auf ihr ausgeführt werden kann. Und der Server kann sicherstellen, dass die Datenstruktur als ganzes korrekt bleibt, wenn nur diese Operationen ausgeführt werden. Und das *ohne* dass jedesmal die gesamten Daten neu überprüft werden müssen. Sowas müßte sich machen lassen, aber ich glaube nicht, dass das basierend auf Relationen geht. Das ganze ist daher so wichtig, weil wir sehr große Objekte haben (Grenze von Russland z.B.). Der Stand der Dinge heute ist so, dass das Verschieben eines Nodes in Sibirien die gesamte Grenze ungültig machen kann. Und das läßt sich nur prüfen, wenn man das gesamte Ding betrachtet. Davon müssen wir wegkommen, wenn wir jemals robusten Datenstrukturen haben wollen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 9. Juli 2012 16:18 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Das hatten wir ja auch beim Hacking WE im Umfeld Polygondatentyp diskutiert. Was wir eigentlich brauchen ist ein Datentyp für Flächen, Routen und Abbiegeregeln. das kann man ja gerne machen und damit den Großteil der Relation sozusagen erschlagen (im Prinzip ist ein Datentyp da doch auch nur ein Spezialfall einer Relation, oder?). Die bisherigen Relationen verführen die Leute IMO Dinge zu modellieren, die hinterher kein Mensch mehr auswerten kann. Menschen können bestimmte Relationen viel eher auswerten als Computerprogramme, insbesondere, wenn man anfängt, sich mehr Rollen auszudenken, um damit verschiedene Objekte untereinander in Beziehung zu setzen. Aufgrund der Kenntnis der Verhältnisse in der realen Welt kann man sich da sicher meist irgendwas zusammenreimen. Ein kaum genutzter Relationstyp (oder role eines members) ist so ähnlich wie ein seltenes tag: nur wenige wenn überhaupt werden das auswerten, es kann aber trotzdem eine coole Spezialanwendung geben, die gerade das nutzt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 16:43, schrieb Sarah Hoffmann: Wir haben mit Relationen keine technisches Problem sondern ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung von Objekten in der DB explizit mit Relationen modeliert werden müsse und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich dass OSM eine spatiale DB ist und keine relationale. Das ist eine sehr freie Interpretation von OSM. Zu den Geodaten gehört es auch, die in der realen Welt bestehenden Zusammengehörigkeit von Objekten abzubilden. Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen sollte ist die: ist die Relation wirklich nötig oder ist es möglich, meine Information auch in Form von einfachen Tags und geografischen Beziehungen in der DB unterzubringen. Warum sollte man immer Tags gegenüber Relationen bevorzugen? Oft sind verschiedene Datenmodelle möglich. Ich würde für jeden Einzelfall eine Abwägung der Vor- und Nachteile vornehmen. Die Antwort auf diese Frage ist eindeutig, dass es möglich ist, und damit sollte die Sache erledigt sein. Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 13:34, schrieb Martin Koppenhoefer: Dreimal derselbe Name einer Straße an einer Kreuzung mit 3 Straßen kommt durchaus in der Realität vor und ist nicht mehr ganz eindeutig (eine Straße ist m.E. für einen Menschen linear, wenn Stiche oder Aufsplittungen vorkommen wird man nicht mehr unbedingt von *einer* Straße sprechen bzw. zumindest auf diesen besonderen Umstand hinweisen). Natürlich ist es nicht immer eindeutig, ob eine Sache zu Kategorie A oder B gehört, ob zwei Dinge eigenständig sind oder zusammengehören. Aber man sollte beide Fälle in den Daten ausdrücken können. Zusammentreffende Straßen mit gleichem Namen würde ich meist als eine verzweigte Straße und nicht als mehrere Straßen interpretieren. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote: Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland ermitteln. Warum sollte das nicht gehen? Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 19:17, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote: Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland ermitteln. Warum sollte das nicht gehen? Weil in der Datenbank nicht drinsteht, welche ways zur selben Straße gehören. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 08:01:51PM +0200, Stephan Wolff wrote: Am 09.07.2012 19:17, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote: Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland ermitteln. Warum sollte das nicht gehen? Weil in der Datenbank nicht drinsteht, welche ways zur selben Straße gehören. Klar, die haben dann einen gemeinsamen Node. Außer in dem seltenen Fall, dass eine Straße eine Unterbrechung hat. Will man das auch noch richtig erfasssen, dann muss man ggf. über die Nähe gehen. Wobei sich bei sowas dann schon die Frage stellt, ob man das als eine Straße oder als mehrere verstehen will. Das hängt dann von der genauen Fragestellung ab. Auf jeden Fall ist das viel verlässlicher als einer Relation, die jemand vielleicht richtig angelegt hat oder auch nicht. Wenn jemand ausversehen eine Relation falsch angelegt hat, z.B. zwei Relationen statt eine, dann bekommste mit Relationen falsche Daten und würdest daher eh den Weg über die Nodes bzw. die Nähe gehen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 20:31, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 08:01:51PM +0200, Stephan Wolff wrote: Am 09.07.2012 19:17, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote: Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland ermitteln. Warum sollte das nicht gehen? Weil in der Datenbank nicht drinsteht, welche ways zur selben Straße gehören. Klar, die haben dann einen gemeinsamen Node. Selbst diese einfache Heuristik erfordert schon viel Programmier- und Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen. Schon bei Straßen mit zwei Richtungsfahrbahnen oder Straßen mit Kreisverkehr scheitert die Heuristik. Außer in dem seltenen Fall, dass eine Straße eine Unterbrechung hat. Will man das auch noch richtig erfasssen, dann muss man ggf. über die Nähe gehen. Das wird niemand mehr programmieren. Der übliche OSM-Ansatz ist es doch, Daten von Ortskundigen erfassen zu lassen und explizit in die Datenbank zu schreiben. Gerade bei Straßen als namensgebendes Objekte von OSM sollte es ein Ziel sein, diese als Gesamtobjekt für die unterschiedlichsten Fragestellungen auswertbar zu machen. Wenn die Tools noch nicht so weit sind, kann man übergangsweise mit den tagbasierten Daten arbeiten :-)) Wobei sich bei sowas dann schon die Frage stellt, ob man das als eine Straße oder als mehrere verstehen will. Das hängt dann von der genauen Fragestellung ab. Bei getrennten Richtungsfahrbahnen, Unterbrechungen durch Kreisverkehre oder durch spätere Umbauten bleibt es eine Straße. Auf jeden Fall ist das viel verlässlicher als einer Relation, die jemand vielleicht richtig angelegt hat oder auch nicht. Falsche Daten führen natürlich immer zu falschen Ergebnissen. Falsche Relationen fallen genauso auf, wie falsche name-Tags. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hi, On 09.07.2012 21:28, Stephan Wolff wrote: Selbst diese einfache Heuristik erfordert schon viel Programmier- und Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen. Ja, aber schau Dir mal die aktuellen Nahverkehrsrelationen an und sag mir, welche OSM-Nutzer das durchfuehren kann ;) Der übliche OSM-Ansatz ist es doch, Daten von Ortskundigen erfassen zu lassen und explizit in die Datenbank zu schreiben. Ortskundige, die keinen Hintergrund in Informationstechnologie und Objektmodellierung haben, ja. Wir reden im Zeifel von Leuten, die lieber jede Zeile im OpenOffice mit 10 Leerstellen einruecken als einmal auf Format-Absatz-von links: 1cm zu gehen, wenn Du verstehst, was ich meine ;) Gerade bei Straßen als namensgebendes Objekte von OSM sollte es ein Ziel sein, diese als Gesamtobjekt für die unterschiedlichsten Fragestellungen auswertbar zu machen. Nein, das sollte nicht das Ziel sein, das hast Du Dir jetzt eben gerade ausgedacht, weil Du es gern so haettest. Es gibt m.E. keinen zwingenden Grund dafuer. Router oder Renderer koennen schlau genug sein, drei aneinanderstossende Goethestrassen als folgen Sie der Goethestrasse zu interpretieren. Und wenn in der Goethestrasse eine Luecke ist, dann darf man auch nicht mehr sagen folgen Sie Wozu also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat die Stadt? (Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not Objekte zu logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht zwingen, eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken, bloss weil ein Tempolimit kommt oder der Bus abbiegt...) Bei getrennten Richtungsfahrbahnen, Unterbrechungen durch Kreisverkehre oder durch spätere Umbauten bleibt es eine Straße. Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben nicht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 09:28:03PM +0200, Stephan Wolff wrote: Klar, die haben dann einen gemeinsamen Node. Selbst diese einfache Heuristik erfordert schon viel Programmier- und Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen. Schon bei Straßen mit zwei Richtungsfahrbahnen oder Straßen mit Kreisverkehr scheitert die Heuristik. Was Du da haben willst ist halt schon eine sehr spezielle Fragestellung. Da macht das auch nichts, wenn das etwas schwieriger ist. Und was ist, wenn morgen jemand kommt, der alle 30er-Zonen in Bayern zählen will oder alle Wege auf Friedhöfen im Ruhrgebiet. Willste dann auch immer neue Relationen einführen und die alle pflegen lassen? Auf jeden Fall ist das viel verlässlicher als einer Relation, die jemand vielleicht richtig angelegt hat oder auch nicht. Falsche Daten führen natürlich immer zu falschen Ergebnissen. Falsche Relationen fallen genauso auf, wie falsche name-Tags. Ja, aber falsche Ways sind schnell erkannt und gefixt. Falsche Relationen sind viel schwieriger zu erkennen und zu fixen. Damit wird es immer so sein, dass Du Dich auf die Relationen nicht verlassen kannst. Und daher gehste dann in der Praxis bei der Auswertung den aufwändigeren, aber robusteren Weg ohne die Relationen. Dann kannste die Dir die Relationen aber einfach sparen. Ein anderes Beispiel: In Multipolygon-Relationen sollte man eigentlich Rollen outer und inner vergeben. Aber das blicken die Leute nicht und machen es häufig falsch. Wenn man die Multipolygon-Relationen also auswerten will, dann ignoriert man einfach die Rollen und setzt die Multipolygone auch ohne diese Information zusammen. Das geht ganz gut. Auf jeden Fall geht es besser, als sich auf die Angaben der Mapper zu verlassen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ergänzende Frage - bevor diese vergessen wird...
Hi ! es wird ja viel diskuttiert und damit habe ich ja auch schon etwas erreicht. Aber bevor es aus dem Blick gerät - meine Frage nochmal.. Die HL-Frage gilt es jetzt noch zu klären. Gibt es vielleicht irgendwo schon jetzt ein Programm um die Daten der Relations/Proposed/Buildings auf die OSM-Objekte zu übertragen. Also File rein und ergänztes File wieder aus. Und das ganze Performant. Vielleicht ein C-Teil ??? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Flughafenkarte
hi ! es gab da einmal eine Flughafenkarte auf OSM-Basis die die Ebenen getrennt dargestellt hat. Weiß einer wo diese zu finden war, wenn es diese noch gibt. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fwd: [OSM-talk] Licence redaction ready to begin
Der redation-bot wird am Mittwoch (kleiner Freudischer von Richard beim Datum) anfangen zu laufen. Ankündigung siehe nachfolgend. Original-Nachricht Betreff:[OSM-talk] Licence redaction ready to begin Datum: Mon, 09 Jul 2012 21:46:43 +0100 Von:Richard Fairhurst rich...@systemed.net An: t...@openstreetmap.org, d...@openstreetmap.org, annou...@openstreetmap.org Hello all, I'm pleased to announce that the licence change bot is ready to get underway. Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL) - in other words, they will no longer be accessible. We are expecting to begin on _Wednesday_ (9th July) assuming a couple of final setup details are completed by then. The bot will run in the following order: 1. Ireland 2. UK 3. Western Europe 4. North America 5. Australia 6. rest of the world Once it is complete, we will be ready to distribute data under the ODbL and we'll advise of that with a separate announcement. The final pre-redaction dataset available under CC-BY-SA has now been generated at http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. Test runs have shown that the bot is functioning as we want it to, but we will of course be monitoring its progress. We are currently expecting it to take in the order of one month to complete; given the many variables I'm afraid we can't give a more precise steer yet, but we'll aim to keep everyone updated as it runs (via the announce@ and talk@ lists). There will be _no_ API outage and no other interruption to editing. When the bot is running in your area, please do save your edits frequently to minimise the likelihood of conflict. (Separate messages are going to talk-ie@ and talk-gb@ as the first two areas to be affected. Please do forward and translate this for your local mailing lists.) As you know we were expecting this to start just after 1st April and the complexity of the task incurred the delay. Thank you all very much for your patience in waiting for it to get underway. Thank you especially to those who have contributed to the code, whether by patches, suggestions or just helping to firm up the workings. Richard for the OSMF board ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 21:47, schrieb Frederik Ramm: Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben nicht. Genau das ist der Punkt. Schmeißen wir die Relationen weg, verprellen wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren Elementen nur noch in der Relation auftauchen. Mich hat bisher kein einziges Argument gegen Relationen überzeugt. Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für den restlichen OSM-Datenbestand. Ich sehe z.B. immer wieder nicht verbundene Nodes, versehentlich verschobene, etc. Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein spatiale DB ist. Es ist ein Mix - whatever works entscheidet, wer wie etwas modelliert. Natürlich bedeuten diese Freiheiten Komplexität in der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu zwingen, einheitlich zu mappen. Ein Einwirken auf jeden der dann nach Überlegung falsch mappt, wird denjenigen die Lust am Mappen verderben. Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und der gleiche geografische Sachverhalt eben vielfältig modelliert werden kann. Warum begreifen wir das nicht weiterhin als Chance? Warum wird stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten gesucht, wie es Knoten und Weg nunmal sind? Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit zu bewahren und die Pflege zu vereinfachen. Sie können evtl. 50+ Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege nur den regional üblichen Namen halten. Auch mit Lookup-Tables/LUT versagt irgendwann der minimalistische Ansatz. Je nachdem, wieviel Information über eine Menge von Wegen oder Knoten gehalten werden soll. Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum dokumentiert und die Art ihrer Implementierung variiert. Die Live-DB, die Live-Toolchain verwendet sie nicht. Zudem wird mit der Auslagerung von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt nur nicht vom Menschen. Wenn wir schon so radikal sein wollen und so einen tollen Leitspruch wie vermeide Relationen gebären wollen, warum dann nicht gleich auch auf die Struktur way verzichten. Eigentlich reicht es doch, wenn wir alles auf dem Node taggen. Mapper machen nur Fehler, wenn sie sich mit der Komplexität eines way's auseinandersetzen sollen. (..) Weiterhin spielt die Arbeitsweise beim Mappen in diese Problematik. Ich würde weder diejenigen verprellen, die strukturiert arbeiten und sagen: Ich lege mir Bundesstraßenrelationen an, weil mir dann die Pflege dieses Netzes einfacher fällt., noch diejenigen, die in einem weißen Gebiet unstrukturiert alles mögliche anlegen und von Relationen gar nichts wissen und sie aufgrund des Datenstandes evtl. gar nicht brauchen. Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt sind, ist das mehr an Information und evtl. auch Redundanz eine Chance, gute QM-Tools zu bauen. Am Beispiel der Bundesstraßen z.B. könnte man die Argumente derjenigen aufgreifen, die meinen man könne den Verlauf der Bundesstraße auch programmatisch anhand des ref= zusammenbauen und braucht die Relation gar nicht und gegen das prüfen, was manuell gepflegt wird. In der Summe ergibt das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen kann: - versehentlich Relation beschädigen - versehentlich ref löschen Es ist unwahrscheinlich, das beides zeitgleich passiert. Gäbe es hingegen eine explizite Relation nicht, würde ein Fehler durch ein fehlendes ref Tag am way nicht auffallen - allein auf die Heuristik alle Wege, die sich einen Knoten teilen zu bauen, ist weltfremd und idealisiert imho viel zu stark. Hier wünscht sich der Informatiker die Welt herbei, wie sie sein sollte. Beispielsweise ist der Verlauf von Landesstraßen heute vielfach in Teilabschnitten durch Bundesstraßen ersetzt worden und dadurch fragmentiert. Weiterhin sehe ich nicht ein, weshalb, nur weil es für Routing und Rendering abkömmlich ist, auf den exotischeren Anwendungsfall wieviele Goethestraßen gibt es in X verzichtet werden sollte, wenn er mit etwas Grips und gutem Willen in der DB ohne viel Zauber und Zusatzarbeit modellierbar ist. Die Fragen, die sich hier viele stellen, ist doch eher, wieviel Relation ist gut? Wie kann vermieden werden, dass die Nutzung von Relationen, die spatiale Verwendbarkeit einer Auswertung auf einfacheren Ebenen wie Punkt / Weg schadet? Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ergänzende Frage - bevor diese vergessen wird...
komische Frage. Nah ja, ist schon entscheiden dass in Deutschland Relationen ersetzt werden? Ich habe nicht die ganze Diskussion gefolgt. Macht ihr wirklich einen Schritt rückwerts? Nur in Deutschland, oder alle deutschsprachige Gebiete? Oder sogar weltweit? Jedenfalls ist so ein Program relativ einfach zu schreiben. Was natürlich die Idee das Relationen schwierig auszuwerten sind, löscht.. Jo 2012/7/9 Jan Tappenbeck o...@tappenbeck.net Hi ! es wird ja viel diskuttiert und damit habe ich ja auch schon etwas erreicht. Aber bevor es aus dem Blick gerät - meine Frage nochmal.. Die HL-Frage gilt es jetzt noch zu klären. Gibt es vielleicht irgendwo schon jetzt ein Programm um die Daten der Relations/Proposed/Buildings auf die OSM-Objekte zu übertragen. Also File rein und ergänztes File wieder aus. Und das ganze Performant. Vielleicht ein C-Teil ??? Gruß Jan :-) __**_ 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] ergänzende Frage - bevor diese vergessen wird...
Am 09.07.2012 23:59, schrieb Jo: komische Frage. Nah ja, ist schon entscheiden dass in Deutschland Relationen ersetzt werden? Ich habe nicht die ganze Diskussion gefolgt. Macht ihr wirklich einen Schritt rückwerts? Nur in Deutschland, oder alle deutschsprachige Gebiete? Oder sogar weltweit? Jedenfalls ist so ein Program relativ einfach zu schreiben. Was natürlich die Idee das Relationen schwierig auszuwerten sind, löscht.. Hallo Jo, aber gibt es schon wo frei verfügbare Komponenten / Programme / Erläuterungen / Beispiele ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] aggiornamento firmware garmin
Qualcuno sa se è possibile e come fare ad aggiornare il firmware dei Garmin (nel mio caso 62sc) tramite linux? -- 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] access destination
2012/7/7 Fabri erfab...@gmail.com: con il tuo -1 sembra che non per te non va bene usare access=private per le strade di proprietà privata dietro un cancello Fabri, chiedo scusa, non mi spiego com'è successo. Facci un +1 dal -1 ;-) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Errore 403 scaricando i file .pbf delle regioni da gfoss.it
Non riesco a scaricare i file .pbf da http://download.gfoss.it/osm/osm/regioni/ mentre scarico quelli .bz2 senza problemi. -- Daniele Forsi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Errore 403 scaricando i file .pbf delle regioni da gfoss.it
Il 09 luglio 2012 17:00, Daniele Forsi dfo...@gmail.com ha scritto: Non riesco a scaricare i file .pbf da http://download.gfoss.it/osm/osm/regioni/ mentre scarico quelli .bz2 senza problemi. scusa c'era un problema di permessi -- Daniele Forsi -- 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] access destination
Paolo Pozzan wrote A voler invece essere pragmatici, basta copiare da ciò che fanno gli altri =) . Sia GMaps, che Nokia Maps, che Tuttocittà ti fanno correttamente evitare la via anche se sarebbe la strada più corta, ma se la imposti come destinazione te la fanno percorrere. Ciò equivale a un access=destination. Se poi uno vuol chiedere al comune, tanto meglio. Qualsiasi mappatore di OSM potrebbe citarti decine di errori trovati su Google Maps e simili... L'approccio pragmatico semmai potrebbe essere in questo senso: se nonostante sul cartello siano citati soltanto residenti e frontisti tu sai (per esperienza, perché hai chiesto, ecc.) che il transito dei visitatori, parenti o meno, è tollerato, usa pure destination. Ripeto però che dire di usare access=destination per qualunque strada riservata ai residenti in Italia è sbagliato, pensa ad esempio ai centri storici. Ciao, Gianluca -- View this message in context: http://gis.19327.n5.nabble.com/access-destination-tp5715280p5715750.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-lt] Miškų kvartalų numeriai, kvartalinės linijos, kvartaliniai stulpeliai
Sveiki, Neradau, kaip žymėti miškų kvartalų numerius Siūlau naudoti: landuse:forest name:miško-pavadinimas ref:kvartalo numeris Pvz: landuse:forest name:Pavėsgirė ref:199 Tiesa, taip žymint Mapnik surenderintam žemėlapyje kvartalų numerių nesimato: http://www.openstreetmap.org/?lat=54.77883lon=23.65077zoom=15layers=M Jei yra kitoks sprendimas, kurio neradau, prašau nukreipti tinkama linkme. Proskynos jau buvo aptartos: man_made=cutline/cutline=firebreak Tačiau dažnai proskynos, žyminčios miško kvartalus, būna nesuartos, apaugę krūmais, ugnies labai nestabdančios, tačiau pakankamai aiškiai matomos. Manau, kad tinkamesnis toks šių kvartalinių linijų žymėjimas: man_made:cutline/cutline=section Klausimas ta pačia tema - neradau, kaip žymimi kvartaliniai stulpeliai. Prašau nukreipti tinkama linkme :) -- Keisas (Gintaras Kasiulionis) ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Miškų kvartalų numeriai, kvartalinės linijos, kvartaliniai stulpeliai
Pritarčiau nuomonei, kad reikia vengti „miško-miške“ (jau vien todėl, kad pasidarys labai sudėtinga žymėti miškus, šiuo metu net administracines ribas (ryšius) pastoviai tenka taisyti, nes potlachininkai pastoviai jas netyčia gadina). Bet, žiūrint į ateitį, kaip realiai oficialiai skirstomi miškai? Gal bet kokiu atveju oficialus skirstymas turi hierarchiją? -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Miškų kvartalų numeriai, kvartalinės linijos, kvartaliniai stulpeliai
2012/7/9 Aidas Kasparas a.kaspa...@gmc.lt: On 2012.07.09 12:45, Gintaras Kasiulionis wrote: Sveiki, Neradau, kaip žymėti miškų kvartalų numerius Siūlau naudoti: landuse:forest name:miško-pavadinimas ref:kvartalo numeris ... Iš wikio pastudijavimo man susidarė įspūdis, kad miško kvartalų žymėjimas nėra išvystytas. Taigi, jei esi miškininkas profesionalas, bijau, kad gausi pramyninėti naujus takus. Deja, tai greičiausiai reikš, kad visiškai standartinėmis priemonėmis ir paslaugomis pasinaudoti nepavyks, o teks kažką adaptuoti. Manau, kad kolektyvas kažkiek galės padėti tame, bet reikėtų, kad papasakotum, kokio tikslo sieki. Neesu miškininkas profesionalas. Jeigu toks būčiau, norėčiau suvesti informaciją, vienareikšmiškai identifikuojančią mišką, su tik popieriuje egzistuojančiais unikaliais miško plotų numeriais (plačiau http://www.amvmt.lt/Misku_kadastras/Bendra_informacija.aspx?MID=0AMID=408 ) Tikslas paprastas - įvesti kvartalų numerius (jie unikalūs tik vieno miško ribose), nes šiuos numerius, kaip ir teisingai pastebėjai žemiau, galima rasti miške ant stulpelių. Tai padėtų lengviau susiorentuoti žemėlapį turinčiam žmogui - radęs stulpelį tikslai žinotų, kuriame miško taške yra. Kas man nepatiko pasiūlytame žymėjime, kad gaunasi baisiai daug plotelių su tuo pačiu pavadinimu. Alternatyva būtų žymėti visą mišką su name: Pavėsgirė, o viduje kvartalus su ref: 199. Aišku, tas reikštų, kad mes turim mišką miške ir mane užmėtys akmenais dėl didžiausios OSM nuodėmės -- taginimo dėl renderinimo, bet... kažkokio kitokio standartinio kelio objektų agregacijai aš neradau :-//. Bet kuriuo atveju, reikia palaukti kitų nuomonių, ar taip daryti būtų blogai, ar labai labai blogai. Dėl to, kad gaunasi daug plotelių su tuo pačiu pavadinimu, ir padariau tik mažą plotelį bendruomenės vertinimui. Gal geriau visai nerašyti pavadinimo, o surasti tinkamus kitus laukus. Negerai daryti mišką miške. http://wiki.openstreetmap.org/wiki/Cutline paaiškinama, kad didelių plotų skaldymas į mažesnius palengvina skaičiavimus dėl mažesnio sudėtingumo objektų. Dar mačiau numirusį pasiūlymą tag'ui section ir nedokumentuotą boundary:forest (su keliais šimtais žymėjimų). Gal galima būtų vystyti tuos, bet tada reikės generuoti savo kaladėles žemėlapių rodymui. Tačiau tada galima pasidaryti visiškai taip, kaip pats nori. Savo kaladėlių gamyba rodymui man kol kas kaip kosmosas. Artimiausiu metu neplanuoju naudoti nestandartinių priemonių. ... Klausimas ta pačia tema - neradau, kaip žymimi kvartaliniai stulpeliai. Prašau nukreipti tinkama linkme :) Jei aš gerai prisimenu, ką kažkada viena ausimi girdėjau, tai tie stulpeliai statomi pagal kažkokią griežtą sistemą ir tampriai susiję su kvartalų numeriais. Tai, jei pavyktų parodyti kvartalus, ar bebūtų prasmė dar atskirai žymėti stulpelius? Ar yra interesas būtinai nurodyti konkrečią vietą (metro tikslumu), kur tas stulpelis patrauktas, pridėti dar kažkokią papildomą info prie stulpelio? Sutinku - tai būtų perteklinė informacija. Nepiešiam stulpelių :) -- Aidas Kasparas -- Gintaras Kasiulionis ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Miškų kvartalų numeriai, kvartalinės linijos, kvartaliniai stulpeliai
2012/7/9 Tomas Straupis tomasstrau...@gmail.com: Pritarčiau nuomonei, kad reikia vengti „miško-miške“ ... Bet, žiūrint į ateitį, kaip realiai oficialiai skirstomi miškai? Gal bet kokiu atveju oficialus skirstymas turi hierarchiją? Oficiali miškų skirstymo herarchija ( http://www.amvmt.lt/Misku_kadastras/Bendra_informacija.aspx?MID=0AMID=408 ) nesusijusi su miške nurodytais kvartalais. Miške esantys kvartalai unikalūs tik to miško ribose. Kol kas tikslas sužymėti tai, ką galima pamatyti gyvai. Ant LR Vyriausybės nutarimų Nr.1154 ir Nr.1308 priedų nurodyta (C) Valstybinė miškotvarkos tarnyba. Kadangi neesu išstudijavęs teisės, tai į atvirą projektą neplanuoju perkelti (C) pažymėtų dokumentų turinio. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt -- Gintaras Kasiulionis ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Miškų kvartalų numeriai, kvartalinės linijos, kvartaliniai stulpeliai
Šiaip Pavėsgirės (http://osm.org/go/0lH2QNM0--) situacija labai panaši į kitus „grupinius“ žymėjimus. Tarkim „Pravalo tvenkinių kompleksas“: http://www.openstreetmap.org/?lat=55.0789lon=25.7203zoom=14layers=M Nors ir pavadinimas pažymėtas ant ryšio, o ne kiekvieno atskiro tvenkinio komponento, kiekvienas komponentas gauna „atskirą“ pavadinimą... Nelabai gražu, nes turim geroką informacijos perteklių. Gal postgis'as (ar osm2pgsql) nepalaiko poligonų, sudarytų iš kelių atskirų komponentų? P.S. Proskynas standartinis mapnik stilius žymi. Trūksta „ref“? -- Tomas Straupis ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
[Talk-dk] Fwd: [Announce] Licence redaction ready to begin
Til orientering for de der ikke følger Announce listen. Der er en tastefejl - processen starter 11. juli. Original Message Subject: [Announce] Licence redaction ready to begin Date: Mon, 09 Jul 2012 21:46:43 +0100 From: Richard Fairhurst rich...@systemed.net To: t...@openstreetmap.org, d...@openstreetmap.org, annou...@openstreetmap.org Hello all, I'm pleased to announce that the licence change bot is ready to get underway. Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL) - in other words, they will no longer be accessible. We are expecting to begin on _Wednesday_ (9th July) assuming a couple of final setup details are completed by then. The bot will run in the following order: 1. Ireland 2. UK 3. Western Europe 4. North America 5. Australia 6. rest of the world Once it is complete, we will be ready to distribute data under the ODbL and we'll advise of that with a separate announcement. The final pre-redaction dataset available under CC-BY-SA has now been generated at http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. Test runs have shown that the bot is functioning as we want it to, but we will of course be monitoring its progress. We are currently expecting it to take in the order of one month to complete; given the many variables I'm afraid we can't give a more precise steer yet, but we'll aim to keep everyone updated as it runs (via the announce@ and talk@ lists). There will be _no_ API outage and no other interruption to editing. When the bot is running in your area, please do save your edits frequently to minimise the likelihood of conflict. (Separate messages are going to talk-ie@ and talk-gb@ as the first two areas to be affected. Please do forward and translate this for your local mailing lists.) As you know we were expecting this to start just after 1st April and the complexity of the task incurred the delay. Thank you all very much for your patience in waiting for it to get underway. Thank you especially to those who have contributed to the code, whether by patches, suggestions or just helping to firm up the workings. Richard for the OSMF board ___ Announce mailing list annou...@openstreetmap.org http://lists.openstreetmap.org/listinfo/announce ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
[Talk-es] Fwd: [OSM-talk] Licence redaction ready to begin - Retirada de elementos a raíz del cambio de licencia
Buenas, Acabo de recibir desde la lista talk que el bot para ir retirando los elementos incompatibles con la OBbL (del orden del 1% del total) es ya funcional y va a empezar a funcionar esta semana (probablemente el día 11). El bot va a seguir el siguiente orden: 1. Irlanda 2. Reino Unido 3. Oeste de Europa 4. Norte América 5. Australia 6. El resto del mundo Cuando acabe la información de la base de datos podrá ser distribuida bajo la ODbL. La ultima versión guardada bajo CC-BY-SA en http://planet.openstreetmap.org/planet-120704.osm.bz2 Monitorizaran el proceso para asegurase de que va bien. Mientras dure el proceso NO habrá ningún parón en el funcionamiento de la API ni ningún problema en las ediciones. Simplemente cuando el bot este funcionando en nuestra área, guarda tus ediciones frecuentemente para minimizar la probabilidad de conflictos entere ediciones. Esta es la traducción aproximada y resumida del comunicado de Richard Fairhurst de la OSMF board. Tenéis el original en inglés un poco más abajo. Un saludo. -- Forwarded message -- From: Richard Fairhurst rich...@systemed.net Date: 9 July 2012 22:46 Subject: [OSM-talk] Licence redaction ready to begin To: t...@openstreetmap.org, d...@openstreetmap.org, annou...@openstreetmap.org Hello all, I'm pleased to announce that the licence change bot is ready to get underway. Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL) - in other words, they will no longer be accessible. We are expecting to begin on _Wednesday_ (9th July) assuming a couple of final setup details are completed by then. The bot will run in the following order: 1. Ireland 2. UK 3. Western Europe 4. North America 5. Australia 6. rest of the world Once it is complete, we will be ready to distribute data under the ODbL and we'll advise of that with a separate announcement. The final pre-redaction dataset available under CC-BY-SA has now been generated at http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. Test runs have shown that the bot is functioning as we want it to, but we will of course be monitoring its progress. We are currently expecting it to take in the order of one month to complete; given the many variables I'm afraid we can't give a more precise steer yet, but we'll aim to keep everyone updated as it runs (via the announce@ and talk@ lists). There will be _no_ API outage and no other interruption to editing. When the bot is running in your area, please do save your edits frequently to minimise the likelihood of conflict. (Separate messages are going to talk-ie@ and talk-gb@ as the first two areas to be affected. Please do forward and translate this for your local mailing lists.) As you know we were expecting this to start just after 1st April and the complexity of the task incurred the delay. Thank you all very much for your patience in waiting for it to get underway. Thank you especially to those who have contributed to the code, whether by patches, suggestions or just helping to firm up the workings. Richard for the OSMF board ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Atentamente, Suárez ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] OGD (Wien) nützen
Am 6. Juli 2012 17:57 schrieb Andreas Labres l...@lab.at: On 06.07.12 12:11, Boris Cornet wrote: Äh, nein, so würde ich das nicht sehen. Doch, so war meiner Erinnerung nach schon das Ergebnis der Podiumsdiskussion schon so in etwa: Kaum mehr Importe, wenn, nur unter größter Bedachtnahme und in leeren Gebieten. Kannst Du ein konkretes Beispiel nennen, welcher Import wo noch /denkbar/ wäre? Mir fällt da auch nach oftmaligem Nachdenken nix ein. Der OGD Wien Datensatz der noch auf Bearbeitung wartet sind die Straßenampeln, vor allem die Straßenampeln mit Akustikkennung, weil es die Basis für blindengerechte Routinganwendungen bieten würde. Nachdem aber in OSM schon sehr viele Wiener Ampeln eingetragen sind, müsste man auch bei diesem Datensatz eine Möglichkeit zum finden einen semi manuellen Abgleich durchzuführen. Ein anderer Kandidat sind Kindergärten, wo eventuell auch noch der eine oder andere nicht in OSM eingetragen ist, weil er sich an einem etwas versteckten Ort befindet. cu andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] geoimage.at in JOSM
Hi, die standard-WMS Url im JOSM für Geoimage.at MaxRes liefert zur Zeit nur Fehler. Fühlt sich hier wer dafür zuständig? MfG David ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at in JOSM
Hallo! die standard-WMS Url im JOSM für Geoimage.at MaxRes liefert zur Zeit nur Fehler. Fühlt sich hier wer dafür zuständig? Ich erhalte ServiceExceptionReached counter limit/ServiceException Das heißt wohl, dass wir einen neuen Schlüssel bräuchten … Grüße Simon ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at in JOSM
Hallo! Und das wiederum heißt. dass der Besitzer des Schlüssels eine Limitausweitung beantragem muss. Wem »gehört« der öffentliche Schlüssel? :-) Simon ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Mittwoch!
Hi! Ich wollt mich nur kurz melden und euch sagen das Mittwoch für mich leider nicht geht. Ich bin grad mit Arbeit eingedeckt worden und fahre Donnerstag aber für ne Woche weg. Leider keine Chance die Neuigkeiten Agit zu Präsentieren .. Wobei ich aber ehrlich gesagt auch nicht gewusst hätte was ich dazu sagen soll .. Markus hat im WIKI eigentlich alles dazu schon gesagt.. Sollte jemand einen Blick in den Tagungsband der agit werfen wollen so stelle ich ihn gerne zur Verfügung.. Ansonsten bin ich das nächste mal dann wieder dabei. @Stefan: Meine Hoffnung auf einen OSM-Kurs gebe ich nicht auf ;) lg Werner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mittwoch!
On 09.07.12 19:14, Werner Macho wrote: Ich wollt mich nur kurz melden und euch sagen das Mittwoch für mich leider nicht geht. Ich bin grad mit Arbeit eingedeckt worden und fahre Donnerstag aber für ne Woche weg. Leider keine Chance die Neuigkeiten Agit zu Präsentieren .. Wobei ich aber ehrlich gesagt auch nicht gewusst hätte was ich dazu sagen soll .. Alles klar. Danke! Ich werde die Ankündigung im Wiki dann gleich auf 18:30 beim Wieden Bräu ändern... BTW, falls jemand früher dort ist, könnte im Garten zwei Tische besetzen... sie nehmen im Garten keine Reservierungen an... Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
Ich möchte hier einen Datensatz einwerfen, mit dem ich mich in letzter Zeit ein wenig auseinandergesetzt habe und einen *manuellen *Import davon anstrebe: Der Baumkataster der Stadt Wien. Ein paar Analysen zur Abdeckung und Filterung von bereits eingetragenen Bäumen habe ich bereits gemacht und werde sie bekannt machen, wenn ich wieder Zugriff darauf habe (bin unterwegs). Auch mit deren Aufbereitung habe ich bereits begonnen. Die Integration des Baumkatasters macht schon alleine deswegen für mich Sinn, weil dort die botanisch korrekten Baumnamen als auch Maße eingetragen sind. Außerdem umfasst dieser Kataster nur die öffentlichen Bäume - das heißt, der Großteil aller Bäume würde sowieso noch fehlen. Insofern würde dies meiner Meinung nach ein weiteres Erfassen eher triggern als verhindern. ! Es würden keinerlei bestehende Bäume überschrieben werden ! Beste Grüße, Markus Am 9. Juli 2012 09:01 schrieb Andreas Trawoeger atra...@kartenwerkstatt.at : Am 6. Juli 2012 17:57 schrieb Andreas Labres l...@lab.at: On 06.07.12 12:11, Boris Cornet wrote: Äh, nein, so würde ich das nicht sehen. Doch, so war meiner Erinnerung nach schon das Ergebnis der Podiumsdiskussion schon so in etwa: Kaum mehr Importe, wenn, nur unter größter Bedachtnahme und in leeren Gebieten. Kannst Du ein konkretes Beispiel nennen, welcher Import wo noch /denkbar/ wäre? Mir fällt da auch nach oftmaligem Nachdenken nix ein. Der OGD Wien Datensatz der noch auf Bearbeitung wartet sind die Straßenampeln, vor allem die Straßenampeln mit Akustikkennung, weil es die Basis für blindengerechte Routinganwendungen bieten würde. Nachdem aber in OSM schon sehr viele Wiener Ampeln eingetragen sind, müsste man auch bei diesem Datensatz eine Möglichkeit zum finden einen semi manuellen Abgleich durchzuführen. Ein anderer Kandidat sind Kindergärten, wo eventuell auch noch der eine oder andere nicht in OSM eingetragen ist, weil er sich an einem etwas versteckten Ort befindet. cu andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Fwd: [OSM-talk] Licence redaction ready to begin
Für alle, die Talk-de nicht mitlesen: ODbL-Umstellung beginnt diesen Mittwoch. Vg, Martin Original-Nachricht Betreff:[OSM-talk] Licence redaction ready to begin Datum:Mon, 09 Jul 2012 21:46:43 +0100 Von:Richard Fairhurst rich...@systemed.net An:t...@openstreetmap.org, d...@openstreetmap.org, annou...@openstreetmap.org Hello all, I'm pleased to announce that the licence change bot is ready to get underway. Starting this week, we will be 'redacting' the contributions (less than 1%) from the live database that are not compatible with the new Contributor Terms and Open Database Licence (ODbL) - in other words, they will no longer be accessible. We are expecting to begin on _Wednesday_ (9th July) assuming a couple of final setup details are completed by then. The bot will run in the following order: 1. Ireland 2. UK 3. Western Europe 4. North America 5. Australia 6. rest of the world Once it is complete, we will be ready to distribute data under the ODbL and we'll advise of that with a separate announcement. The final pre-redaction dataset available under CC-BY-SA has now been generated at http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has been redacted, any attempt to access it from the API or the site's 'browse' pages will return a response to that effect. Test runs have shown that the bot is functioning as we want it to, but we will of course be monitoring its progress. We are currently expecting it to take in the order of one month to complete; given the many variables I'm afraid we can't give a more precise steer yet, but we'll aim to keep everyone updated as it runs (via the announce@ and talk@ lists). There will be _no_ API outage and no other interruption to editing. When the bot is running in your area, please do save your edits frequently to minimise the likelihood of conflict. (Separate messages are going to talk-ie@ and talk-gb@ as the first two areas to be affected. Please do forward and translate this for your local mailing lists.) As you know we were expecting this to start just after 1st April and the complexity of the task incurred the delay. Thank you all very much for your patience in waiting for it to get underway. Thank you especially to those who have contributed to the code, whether by patches, suggestions or just helping to firm up the workings. Richard for the OSMF board ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-de mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-ca] Help needed to double-check a recent changeset in Montreal
I have been mapping some bus stops, and I used ref for the stop number, not the route number. I usually added the route numbers of that stop in the notes tag, but by looking at http://openptmap.org/ I see there's an example in Montreal, on rue du Parc, and it uses a relation for the bus route: http://wiki.openstreetmap.org/wiki/FR:Relation:route It seems you can add individual points as well as ways to the route, but I don't know how it would render the points. I would try creating the route with the route number as an attribute, then add the bus stops with ref=stop number to the relation. The openptmap is updated every day, so I'd say try it and let us know how it goes :) 2012/7/6 Fabian Rodriguez magic...@member.fsf.org Hi, It's been a while since I've edited maps directly, I am still using Potlatch 1 as I am more familiar with it. Could someone in Montreal check my edits and advise accordingly? http://www.openstreetmap.org/browse/changeset/12130831 I am particularly interested in the bus stop. The documentation at the OpenStreetMap wiki[1] indicates that the bus rout # should be in ref=XX, but our bus stops also have a unique identifier to get schedules, etc. and I see those identifiers in ref=X in other tags nearby. Which should I use? There are also new tags that are recommended (ie. bus=yes). Should I put both older and newer recommended tags? [1] http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop Thanks for any help. Cheers, Fabian Rodriguez Montreal, Quebec, Canada http://openstreetmap.magicfab.ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk-fr] Outil de notification par mail de suppression des données
Bonjour, L'outil LizWatch ne possède aps encore de système de notification par email. Le code n'est pas encore OpenSource car nous n'avons pas encore pris le temps de le publier (généralisation du système d'installation et de configuration). René-Luc Le 08/07/2012 11:52, Arthur Lutz a écrit : Bonjour, René-Luc : L'outil LizWatch semble en effet adapté (j'ai pas trouvé la notif email mais j'imagine qu'il faut s'authentifier). Vous annonciez sur votre blog en décembre 2011 http://www.3liz.com/blog/rldhont/index.php?post/2011/12/09/375-lizwatch-un-outil-cartographique-de-suivi-des-evolutions-d-openstreetmap que vous alliez publier le code source (je présume en licence logiciel libre). Est-ce que ca été fait ? Est-ce que c'est dans les cartons ? Etienne : l'URL de itoworld m'amène sur une page de login. As-tu une autre URL ? Vincent : un flux RSS serait peut-être une piste, par exemple avec un truc à la yahoo pipes pour effectuer un filtre et ensuite un rss2email (ou directement dans un lecteur RSS). A suivre. Arthur 2012/7/8 Etienne Trimaille etienne.trimai...@gmail.com mailto:etienne.trimai...@gmail.com ItoWorld permet d'avoir un flux RSS des modifications sur une zone précise : http://www.itoworld.com/main Le 8 juillet 2012 09:48, Vincent Pottier vpott...@gmail.com mailto:vpott...@gmail.com a écrit : Le 06/07/2012 14:59, Arthur Lutz a écrit : Bonjour, [...] Des contributeurs OSM m'ont parlé d'outils permettant de surveiller pour la modification, je ne sais pas si c'est similaire ou adapté à mon besoin. Il s'agit probablement du flux RSS du genre http://www.openstreetmap.org/browse/changesets/feed?bbox=5.9145%2C47.2033%2C6.1566%2C47.2807 Le flux est surchargé par les modifications qui n'ont pas grand chose à voir avec la zone concernée : un changesest avec un point en Sibérie et un en Argentine apparaîtra dans le flux pourtant limité à une petite zone. Ça le rend inexploitable. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- http://arthur.lutz.im ___ 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] Tutoriel Leaflet/OpenLayers ?
Rigolo, je voulais voir comment marchait OL et je me suis fixé ce même objectif : afficher plusieurs POI sur un fond OSM avec des logos choisis et un descriptif en popup. Un mix de ces 2 exemple fait le job : http://openlayers.org/dev/examples/dynamic-text-layer.html http://openlayers.org/dev/examples/osm.html C'est le plus simple, il suffit de mettre les POI (lat/lon/desc ...) dans un petit fichier texte et ca marche, très suffisant pour un nombre raisonnable de points. J'en suis pas encore au bout mais c'est sympa. Le 9 juillet 2012 07:24, Romain MEHUT romain.me...@gmail.com a écrit : Merci pour vos réponses, je fais suivre... Romain Le 8 juillet 2012 20:32, Vincent Pottier vpott...@gmail.com a écrit : S'il s'agit de quelques points, un fichier suffit, pas besoin d'une base de donnée. Dans ce cas, les exemples du wiki devraient faire l'affaire. http://wiki.openstreetmap.org/wiki/FR:OpenLayers -- FrViPofm __ 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
Re: [OSM-talk-fr] Tutoriel Leaflet/OpenLayers ?
Bonjour, J'avais fait ça il y a quelques mois pour essayer: http://crcentreapnee.free.fr/carte Cordialement, Cedric Le 09/07/2012 09:42, Eric a écrit : Rigolo, je voulais voir comment marchait OL et je me suis fixé ce même objectif : afficher plusieurs POI sur un fond OSM avec des logos choisis et un descriptif en popup. Un mix de ces 2 exemple fait le job : http://openlayers.org/dev/examples/dynamic-text-layer.html http://openlayers.org/dev/examples/osm.html C'est le plus simple, il suffit de mettre les POI (lat/lon/desc ...) dans un petit fichier texte et ca marche, très suffisant pour un nombre raisonnable de points. J'en suis pas encore au bout mais c'est sympa. Le 9 juillet 2012 07:24, Romain MEHUT romain.me...@gmail.com mailto:romain.me...@gmail.com a écrit : Merci pour vos réponses, je fais suivre... Romain Le 8 juillet 2012 20:32, Vincent Pottier vpott...@gmail.com mailto:vpott...@gmail.com a écrit : S'il s'agit de quelques points, un fichier suffit, pas besoin d'une base de donnée. Dans ce cas, les exemples du wiki devraient faire l'affaire. http://wiki.openstreetmap.org/wiki/FR:OpenLayers -- FrViPofm __ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto: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
Re: [OSM-talk-fr] Tutoriel Leaflet/OpenLayers ?
J'en suis aussi un peu là, j'essayais d'introduite les bulles de l'exemple dynamic-text-layer.htmlhttp://openlayers.org/dev/examples/dynamic-text-layer.htmlqui sont un peu plus propres mais pour l'instant je bataille un peu là dessus :) Le 9 juillet 2012 09:52, Cedric Viou cedricdumezv...@gmail.com a écrit : Bonjour, J'avais fait ça il y a quelques mois pour essayer: http://crcentreapnee.free.fr/carte Cordialement, Cedric Le 09/07/2012 09:42, Eric a écrit : Rigolo, je voulais voir comment marchait OL et je me suis fixé ce même objectif : afficher plusieurs POI sur un fond OSM avec des logos choisis et un descriptif en popup. Un mix de ces 2 exemple fait le job : http://openlayers.org/dev/examples/dynamic-text-layer.html http://openlayers.org/dev/examples/osm.html C'est le plus simple, il suffit de mettre les POI (lat/lon/desc ...) dans un petit fichier texte et ca marche, très suffisant pour un nombre raisonnable de points. J'en suis pas encore au bout mais c'est sympa. Le 9 juillet 2012 07:24, Romain MEHUT romain.me...@gmail.com mailto:romain.me...@gmail.com a écrit : Merci pour vos réponses, je fais suivre... Romain Le 8 juillet 2012 20:32, Vincent Pottier vpott...@gmail.com mailto:vpott...@gmail.com a écrit : S'il s'agit de quelques points, un fichier suffit, pas besoin d'une base de donnée. Dans ce cas, les exemples du wiki devraient faire l'affaire. http://wiki.openstreetmap.org/wiki/FR:OpenLayers -- FrViPofm __ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto: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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tutoriel Leaflet/OpenLayers ?
C'est peut être le plus simple pour des données externes à OpenStreetMap ... ... Mais pour la mise en valeur de données issues d'OSM (comme celles retournées par les requêtes overpass API), le plus simple est d'utiliser les fonctions d'affichage dans OpenLayers, pour des données directement au format .osm. http://wiki.openstreetmap.org/wiki/OpenLayers_osm_file_example Récupérer des données dans un fichier .osm et en faire un fichier texte .csv reste bien entendu possible, mais ça nécessite quelques étapes de nettoyage (avec un tableur par exemple). Pas forcément très simple, en particulier quand on veut garder des descriptions secondaires (pour affichage dans un pop-up par exemple). A moins que quelque chose m'échappe Le 9 juillet 2012 09:42, Eric eric...@sfr.fr a écrit : Rigolo, je voulais voir comment marchait OL et je me suis fixé ce même objectif : afficher plusieurs POI sur un fond OSM avec des logos choisis et un descriptif en popup. Un mix de ces 2 exemple fait le job : http://openlayers.org/dev/examples/dynamic-text-layer.html http://openlayers.org/dev/examples/osm.html C'est le plus simple, il suffit de mettre les POI (lat/lon/desc ...) dans un petit fichier texte et ca marche, très suffisant pour un nombre raisonnable de points. J'en suis pas encore au bout mais c'est sympa. Le 9 juillet 2012 07:24, Romain MEHUT romain.me...@gmail.com a écrit : Merci pour vos réponses, je fais suivre... Romain Le 8 juillet 2012 20:32, Vincent Pottier vpott...@gmail.com a écrit : S'il s'agit de quelques points, un fichier suffit, pas besoin d'une base de donnée. Dans ce cas, les exemples du wiki devraient faire l'affaire. http://wiki.openstreetmap.org/wiki/FR:OpenLayers -- FrViPofm __ 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 -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Noms des cantons sur la carte mapnik
Le 9 juil. 2012 à 01:28, Philippe Verdy a écrit : Le 9 juillet 2012 01:00, Christian Rogel christian.ro...@club-internet.fr a écrit : Les préfets regardent de plus en plus passer les trains ou, plus exactement, les contrats conclus entre les Régions et l'Etat. Tu y vas fort. Les préfectures sont très concernées justement dans le processus électoral. Elles fournissent des moyens d'organisation, de contrôle, de communication, des services de collecte d'informations, enregistrent et contrôlent les données, et les recueillent les doléances en cas d'irrégularités, s'assurent que toutes les mairies ont les moyens suffisants pour le matériel électoral, elles organisent les mises sous plis et envois vers les électeurs, elles enregistrent les listes électorales comme aussi les candidatures en tant qu'intermédiaire de base avec les commission électorales. Elles ont du personnel employé les jours de scrutin, qu'elles payent (même s'il y a des contributions demandées aussi aux collectivités concernées). Etc. Beaucoup de texte à rallonge et pas beaucoup de pertinence et de cohérence. Tu fonctionnes comme une machine qui cracherait tout son savoir sur un sujet , dès qu'on introduit une pièce (mot). Et, si elles sont moins avenantes, les machines sont moins approximatives. ;-) Parmi les perles : les cantons n'ont plus de services dédiés : en fait, ils n'en ont jamais eu. A qui fera-t'on croire qu'un processus électoral intermittent entraînerait de rechercher un point-chef-lieu, car c'était ce qui était soulevé? En résumé : division administrative avec service de gestion au quotidien localisable : 1 point et un barycentre créé division électorale (comme l'a toujours été le canton, même si la gendarmerie et la justice le prenaient, autrefois, comme aire d'action) : pas de point. L'affichage du barycentre est un peu (plus) inutile, mais que peut-on y faire? Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation d'OSM, sur le théme du vélo urbain
On sam., 2012-07-07 at 10:39 +0200, Ludovic CHEVALIER wrote: Sinon, le réseau de L'Heureux Cyclage maintient une carte des ateliers de mécanique vélo, participatifs et solidaires ici: http://www.heureux-cyclage.org/Les-ateliers-velo-dans-le-monde.html Vélo en Ville est déjà sur cette carte à ma connaissance. Il ne va pas sans dire que nous serions prêt à collaborer avec OSM pour importer/synchroniser notre référencement dans la base OSM. Un petit coup de pouce là dessus serait le bienvenu. Intéressant, ça mériterait presque d'en faire un sujet dédié ;) Il faudrait préciser un peu comment vous êtes organisés au niveau technique. Il faudra aussi décider si vous voulez importer ou synchroniser, ça n'a pas les mêmes implications techniques. 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] Tutoriel Leaflet/OpenLayers ?
Dans mon cas, c'est effectivement plutot des données externes: je regardais si je pouvais proposer à l'Office du Tourisme de mon petit village une carte sur leur site avec les POI locaux (2 restos, 3 artisans...) avec les sites web spécifiques de chacun dans une bulle. Donc ca me semblait plus souple d'avoir un petit fichier de données indépendant dont ils pourraient eux même gérer les mises à jour. Et ca me parait aussi plus simple, au moins dans un premier temps. Le 9 juillet 2012 10:19, Ab_fab gamma@gmail.com a écrit : C'est peut être le plus simple pour des données externes à OpenStreetMap ... ... Mais pour la mise en valeur de données issues d'OSM (comme celles retournées par les requêtes overpass API), le plus simple est d'utiliser les fonctions d'affichage dans OpenLayers, pour des données directement au format .osm. http://wiki.openstreetmap.org/wiki/OpenLayers_osm_file_example Récupérer des données dans un fichier .osm et en faire un fichier texte .csv reste bien entendu possible, mais ça nécessite quelques étapes de nettoyage (avec un tableur par exemple). Pas forcément très simple, en particulier quand on veut garder des descriptions secondaires (pour affichage dans un pop-up par exemple). A moins que quelque chose m'échappe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger la petit patrimoine
quand à moi, je ne sais pas trop. pour l'instant j'importe les piscines car elles sont dans le cadastre, pour le reste, je ne me suis jamais vraiment posé la question ... Le 6 juillet 2012 21:27, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 06/07/2012 09:20, Eric a écrit : Euh ... j'ai peur de comprendre certains messages de ce fil : vous êtes en train de dire que les biens privés situés sur des propriétés privées (hors le bâti) peuvent être tagués ? Là, à mon avis, on va très loin et ca s’écarte complétement de la finalité du projet et on adopte une philo très inquiétante à laquelle je n’adhère pas du tout. Non, ce n'est pas le sens de mon intervention (pour les autres, chais pas). Pour ma part je ne taggue pas les piscines privées. Ni les ruchers. Néanmoins, décider de ne pas étiqueter un objet de l'environnement au prétexte que c'est dangereux m'interpelle. Du genre (entendu de mes propres yeux) : c'est dangereux de mettre les banques car des cambrioleurs (etc.)... -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Noms des cantons sur la carte mapnik
2012/7/7 Rainer Kluge rklug...@web.de: Je demande seulement votre avis sur le rendu des cantons, et les political_divisions en général, sur ce type de carte. Et il n'y pas que les political_divisions. J'ai aussi remarqué que les noms des diocèses s'affichaient sur Mapnik, un peu n'import où, parfois en pleine forêt... De manière générale, je pense que Mapnik devrait mieux gérer les noms des relations de type multipolygon : tenir compte de la présence de l'admin_centre ou mieux localiser l'affichage du nom (et ne pas se contenter du barycentre). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tutoriel Leaflet/OpenLayers ?
Le 09/07/2012 10:36, Eric a écrit : Dans mon cas, c'est effectivement plutot des données externes: je regardais si je pouvais proposer à l'Office du Tourisme de mon petit village une carte sur leur site avec les POI locaux (2 restos, 3 artisans...) avec les sites web spécifiques de chacun dans une bulle. Donc ca me semblait plus souple d'avoir un petit fichier de données indépendant dont ils pourraient eux même gérer les mises à jour. Et ca me parait aussi plus simple, au moins dans un premier temps. Alors un fichier .csv avec ligne d'entêtes de colonnes, entretenu dans un tableur ( libreoffice, bien-sûr ;-) ) serait une bonne option, quoi qu'il soit difficile pour certains de récupérer les coordonnées géographiques des POIs pour les inclure dans une ligne. Mais il n'existe pas, à ma connaissance, de format natif CSV dans OpenLayers [1]. Il me semble qu'Étienne Chove avait écrit une classe pour traiter les datatables. Était-ce pour Osmose ? Bingo ! [2] De fait, ça crée aussi une classe layer.DynPois. De mon côté, je me suis fait un petit framework qui traite du geojson. Un exemple [3] C'est un peu complexe au départ. Il y a des dépendances à des classes externes (XRegExp et Render) pour traiter l'écriture de l'info des POIs. Il faut traiter les styles. Mais le résultat est sympa. Et pour moi, facile à réutiliser et adapter [4]. Bien sur, le code est GPL, mais il est un peu brut de décoffrage. Bref, je crois que, quelque soit la solution, il faut mettre les mains dans le cambouis. Le sujet pourrait basculer en dev-fr... [1] http://dev.openlayers.org/docs/files/OpenLayers/Format-js.html [2] http://osmose.openstreetmap.fr/map/DynPoi.js [3] http://frvipofm.net/aep/carte/carte.html [4] http://frvipofm.net/aep/tz/carte.html (remarquer, dans le coin bas-droite, le petit triangle pour jQuery.resizable) -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tutoriel Leaflet/OpenLayers ?
Le 09/07/2012 11:20, Vincent Pottier a écrit : Le 09/07/2012 10:36, Eric a écrit : [...] En fait, ce serait sympa et probablement utile qu'on fasse un assistant de création de cartes web+POIs à la MapOSMatic On a déjà pas mal d'éléments épars. Un projet pour après l'été... Des volontaires ? -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tutoriel Leaflet/OpenLayers ?
Ben si, il y a peut être un truc que j'ai pas bien compris mais OpenLayers. Layer.Text fait ca tout bien et très simplement je pense : http://dev.openlayers.org/apidocs/files/OpenLayers/Layer/Text-js.html En tous cas, je l'ai utilisé et c'est nickel. Alors un fichier .csv avec ligne d'entêtes de colonnes, entretenu dans un tableur ( libreoffice, bien-sûr ;-) ) serait une bonne option, quoi qu'il soit difficile pour certains de récupérer les coordonnées géographiques des POIs pour les inclure dans une ligne. Mais il n'existe pas, à ma connaissance, de format natif CSV dans OpenLayers [1]. Il me semble qu'Étienne Chove avait écrit une classe pour traiter les datatables. Était-ce pour Osmose ? Bingo ! [2] De fait, ça crée aussi une classe layer.DynPois. De mon côté, je me suis fait un petit framework qui traite du geojson. Un exemple [3] C'est un peu complexe au départ. Il y a des dépendances à des classes externes (XRegExp et Render) pour traiter l'écriture de l'info des POIs. Il faut traiter les styles. Mais le résultat est sympa. Et pour moi, facile à réutiliser et adapter [4]. Bien sur, le code est GPL, mais il est un peu brut de décoffrage. Bref, je crois que, quelque soit la solution, il faut mettre les mains dans le cambouis. Le sujet pourrait basculer en dev-fr... [1] http://dev.openlayers.org/**docs/files/OpenLayers/Format-**js.htmlhttp://dev.openlayers.org/docs/files/OpenLayers/Format-js.html [2] http://osmose.openstreetmap.**fr/map/DynPoi.jshttp://osmose.openstreetmap.fr/map/DynPoi.js [3] http://frvipofm.net/aep/carte/**carte.htmlhttp://frvipofm.net/aep/carte/carte.html [4] http://frvipofm.net/aep/tz/**carte.htmlhttp://frvipofm.net/aep/tz/carte.html(remarquer, dans le coin bas-droite, le petit triangle pour jQuery.resizable) -- FrViPofm __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Noms des cantons sur la carte mapnik
Et encore un commentaire malveillant pour simplement redire ce qjue j'ai dit en cherchant une contradiction là où il n'y en a pas. Vous savez ce que c'est la politesse et l'esprit de collaboration ? Parce que je répondais à un message qui est encore complètement faux : les préfectures ne se contentent pas regardent pas passer les trains. Leur rôle administratif est encore très important, en tant qu'interlocuteur direct et principal de l'Etat avec les collectivités, mais aussi en tant qu'organe exécutif ayant un pouvoir de régulation dans des tas de domaines liés à la sécurité du territoire, et toutes les attributions du ministère de l'Intérieur, et même celui du budget concernant les dotations aux collectivités. Et c'est indépendant du fait que les cantons n'ont plus en eux même une fonction administrative (ce que j'ai dit aussi mais ne change rien au fait qu'ils sont encore référencés comme unité de découpage légal du territoire, au moins pour définir les circonscriptions électorales, même s'il n'y a pas/plus d'unité administrative). Ton commentaire était clairement excessif. Celui que tu rajoute tourne en plus à l'insulte... Franchement pas cool. Le 9 juillet 2012 10:23, Christian Rogel christian.ro...@club-internet.fr a écrit : Le 9 juil. 2012 à 01:28, Philippe Verdy a écrit : Le 9 juillet 2012 01:00, Christian Rogel christian.ro...@club-internet.fr a écrit : Les préfets regardent de plus en plus passer les trains ou, plus exactement, les contrats conclus entre les Régions et l'Etat. Tu y vas fort. Les préfectures sont très concernées justement dans le processus électoral. Elles fournissent des moyens d'organisation, de contrôle, de communication, des services de collecte d'informations, enregistrent et contrôlent les données, et les recueillent les doléances en cas d'irrégularités, s'assurent que toutes les mairies ont les moyens suffisants pour le matériel électoral, elles organisent les mises sous plis et envois vers les électeurs, elles enregistrent les listes électorales comme aussi les candidatures en tant qu'intermédiaire de base avec les commission électorales. Elles ont du personnel employé les jours de scrutin, qu'elles payent (même s'il y a des contributions demandées aussi aux collectivités concernées). Etc. Beaucoup de texte à rallonge et pas beaucoup de pertinence et de cohérence. Tu fonctionnes comme une machine qui cracherait tout son savoir sur un sujet , dès qu'on introduit une pièce (mot). Et, si elles sont moins avenantes, les machines sont moins approximatives. ;-) Parmi les perles : les cantons n'ont plus de services dédiés : en fait, ils n'en ont jamais eu. A qui fera-t'on croire qu'un processus électoral intermittent entraînerait de rechercher un point-chef-lieu, car c'était ce qui était soulevé? En résumé : division administrative avec service de gestion au quotidien localisable : 1 point et un barycentre créé division électorale (comme l'a toujours été le canton, même si la gendarmerie et la justice le prenaient, autrefois, comme aire d'action) : pas de point. L'affichage du barycentre est un peu (plus) inutile, mais que peut-on y faire? Christian R. ___ 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] Tutoriel Leaflet/OpenLayers ?
Bonjour, De : Eric Ben si, il y a peut être un truc que j'ai pas bien compris mais OpenLayers. Layer.Text fait ca tout bien et très simplement je pense : http://dev.openlayers.org/apidocs/files/OpenLayers/Layer/Text-js.html En tous cas, je l'ai utilisé et c'est nickel. (je passe vers dev-fr) J'ai aussi eu recours à ça (y compris l'exemple OL :-) ) pour PlaceMaker avec les nodes place du GeoFLA. L'inconvénient que j'y ai trouvé est que je générais de nombreux fichiers txt qu'il fallait ensuite mettre à jour (au fil des points intégrés). J'ai modifié mon approche pour la version Bureaux de Poste[1], où ça n'est pas côté serveur un fichier qui est servi, mais une requête qui est executée en base. La réponse est un flux de type texte, qu'OpenLayers voit toujours comme une implémentation de OpenLayers.Layer.Text. Bien que non formellement libéré (faute d'un packaging digne de ce nom), j'ai tout ça à disposition de qui veux. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tutoriel Leaflet/OpenLayers ?
Le 09/07/2012 11:32, Eric a écrit : Ben si, il y a peut être un truc que j'ai pas bien compris mais OpenLayers.Layer.Text fait ca tout bien et très simplement je pense : http://dev.openlayers.org/apidocs/files/OpenLayers/Layer/Text-js.html En tous cas, je l'ai utilisé et c'est nickel. Bien vu ! Je n'avais pas repéré... Je cherchais dans les OpenLayers.Format... Je crois que je vais ré-écrire une partie de mon code ;-) La suite est sur dev-fr où Vincent (l'autre... un autre...) a déjà écrit. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Xapiviewer
Outil génialissime ! Et ça marche aussi pour les objets linéaires visiblement. J'ai fait le test avec les voies de détresse : http://osm.dumoulin63.net/xapiviewer/?zoom=10lat=43.40163lon=6.28964layers=0BTrequest=service%3Descape_laneicon=http%3A%2F%2Fimages.wikia.com%2Froutes%2Fimages%2F7%2F74%2FC26a.gif http://osm.dumoulin63.net/xapiviewer/?zoom=10lat=43.40163lon=6.28964layers=0BTrequest=service%3Descape_laneicon=http%3A%2F%2Fimages.wikia.com%2Froutes%2Fimages%2F7%2F74%2FC26a.gif Et avec les limitations de vitesse : http://osm.dumoulin63.net/xapiviewer/?zoom=15lat=50.59437lon=2.80933layers=0BTrequest=maxspeed%3D50icon=http%3A%2F%2Fimages1.wikia.nocookie.net%2F__cb20080413092910%2Froutes%2Fimages%2Fa%2Fa2%2FB14_50.gif http://osm.dumoulin63.net/xapiviewer/?zoom=15lat=50.59437lon=2.80933layers=0BTrequest=maxspeed%3D50icon=http%3A%2F%2Fimages1.wikia.nocookie.net%2F__cb20080413092910%2Froutes%2Fimages%2Fa%2Fa2%2FB14_50.gif -- View this message in context: http://gis.19327.n5.nabble.com/Xapiviewer-tp5715366p5715671.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] Noms des cantons sur la carte mapnik
Le 9 juil. 2012 à 11:33, Philippe Verdy a écrit : Et encore un commentaire malveillant pour simplement redire ce qjue j'ai dit en cherchant une contradiction là où il n'y en a pas. Vous savez ce que c'est la politesse et l'esprit de collaboration ? La politesse peut consister dans le fait de ne pas se laisser griser par l'usage du clavier. L'esprit de collaboration, c'est rester dans les limites de l'objet de la discussion. C'est lassant d'avoir à le redire. Parce que je répondais à un message qui est encore complètement faux : les préfectures ne se contentent pas regardent pas passer les trains. Leur rôle administratif est encore très important, en tant qu'interlocuteur direct et principal de l'Etat avec les collectivités, mais aussi en tant qu'organe exécutif ayant un pouvoir de régulation dans des tas de domaines liés à la sécurité du territoire, et toutes les attributions du ministère de l'Intérieur, et même celui du budget concernant les dotations aux collectivités. C'est les préfectures de région qui ont la main sur l'essentiel des crédits, généralement issus de contrats. C'est pour cela que je dis que les préfectures ordinaires ont peu de prises sur la vie au quotidien. Les préfets s'occupent beaucoup de la sécurité et de la santé publique : s'agissant de l'Etat, c'est un truisme, cela fait partie du minimum syndical de tout Etat digne de ce nom, de là à en faire la marque d'une activité en soi, c'est un peu exagéré, car leur travail est principalement le cadrage et la surveillance d'organismes qui se gèrent en grande partie eux-mêmes (procédures de sécurité) ou sur des injonctions venues de Paris ou des autorités de justice. Les cantons n'ont JAMAIS eu de rôle administratif. Pourquoi redire une chose fausse? Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Xapiviewer
Le lundi 9 juillet 2012 04:45:15 SylvainH a écrit : Outil génialissime ! Et ça marche aussi pour les objets linéaires visiblement. J'ai fait le test avec les voies de détresse : Et avec les limitations de vitesse : Oui. Je n'avais pas pensé à ces exemples. En fait, au début, j'affichais les polygones, mais ça rendait ces objets moins visibles (surtout pour les petits). Et finalement, ça peut effectivemente être plus pratique ainsi. Pour info, je ne fais pas grand chose pour ça, c'est l'utilisation de la stratégie cluster d'OpenLayers qui génère cet effet (bonne surprise). Je réfléchis à tout de même refléter l'hétérogénéité des objets, par exemple afficher les icônes plus gros pour les objets plus longs ou avec une plus grande aire. -- Nicolas Dumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Noms des cantons sur la carte mapnik
Le 9 juillet 2012 14:34, Christian Rogel christian.ro...@club-internet.fr a écrit : Le 9 juil. 2012 à 11:33, Philippe Verdy a écrit : Et encore un commentaire malveillant pour simplement redire ce qjue j'ai dit en cherchant une contradiction là où il n'y en a pas. Vous savez ce que c'est la politesse et l'esprit de collaboration ? La politesse peut consister dans le fait de ne pas se laisser griser par l'usage du clavier. L'esprit de collaboration, c'est rester dans les limites de l'objet de la discussion. C'est lassant d'avoir à le redire. C'est d'autant plus lassant de se faire insulter publiquement alors que je suis BEL ET BIEN resté dans le fil de discussion. Et que celui qui m'a répondu ainsi, en me reprochant mes longueurs (alors que c'est juste des phrases correctes en français, avec des sauts de lignes entre paragraphes traitant de points distincts) a envoyé un message aussi long que le mien, mais avec pourtant des raccourcis et phrases toutes faites (et même pas complètes), peu de poncutation, pas de paragraphes. Tout ça pour finalement ne rien répondre concernant les points pertinents que j'avais écrits. C'est juste des réponses sans rien lire, basées sur un conflit personnel que je n'ai pas sollicité, sur des principes préétablis et qui n'admettent jamais que quelqu'un d'autre qu'eux puisse répondre à n'importe quel message entrant (un tout petit nombre qui répondent à tout en cherchant systématiquement la contradiction même là où il n'y en a pas). En terme de volume, franchement il peut aussi se modérer car ses messages sont beaucoup trop nombreux. De toute façon je ne nomme personne, à eux de se reconnaître. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Noms des cantons sur la carte mapnik
Le 9 juillet 2012 14:34, Christian Rogel christian.ro...@club-internet.fr a écrit : Les cantons n'ont JAMAIS eu de rôle administratif. Pourquoi redire une chose fausse? Parce que ta réponse de principe ici est encore plus fausse ! Relis ce que j'ai écrit, j'ai pourtant bien précisé qu'actuellement les cantons n'avait pas/plus ce rôle. Et malgré tout ils gardent un rôle en tant qu'instrument de planification et gestion du territoire, justement par la/les administrations encore existantes et dans des lois bien actuelles (loi électorale mais pas seulement). Non seulement on me reproche d'être trop long (c'est faux : c'est les double interlignes entre paragraphes qui vous gênent ?), mais on en profite pour rajouter sur un ton détestable tout ce que je n'ai pas écrit. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger la petit patrimoine
Je m'excuse d'en remettre une couche concernant les piscines, car il y a vraiment une chose que je ne comprend pas dans l'argumentaire de ceux qui disent "mme si c'est visible sur Bing ou le cadastre, je ne les met pas parce que c'est priv". Mais alors pourquoi mettez vous les btiments privs dans OSM ? En tenant ce raisonnement, vous ne devriez mettre ni les piscines prives, ni les btiments privs. C'est quand mme trs trange en France cette paranoa sur les piscines, je n'arrive pas saisir d'o vient le problme... Pour en revenir aux ruchers, je suis par contre plutt d'avis de ne pas les mettre dans OSM, mme si en ce qui me concerne a pourrait m'tre bien utile, tant trs allergique aux piqres de ces petites btes ! Je trouve que cette information est trop volatile car certains ruchers sont souvent dplacs. Si en plus il y a des vols possibles, alors effectivement a pose un problme thique supplmentaire. Mais en tout cas le voleur, ce ne sera pas moi ! :-) Et puis bon on ne sait jamais : les gupes asiatiques consulteraient-elles OSM ? ;-) a+ Nicolas Le 05/07/2012 16:54, Pieren a crit: 2012/7/5 Eric eric...@sfr.fr Je vois quand meme une nuance de taille avec les autres exemples cits : on ne tague quand meme pas l'intrieur des proprietes prives ! (les piscines etant un contre exemple border-line). Pas border-line, compltement inside-line, oui. Ceux qui mappent les piscines argumentent sur le fait que c'est visible depuis le ciel (Bing) ou du cadastre. Ce qui "se voit depuis l'espace public" serait donc toujours lgitimement cartographiable (perso, je ne le fais pas pour les piscines). Si les ruches sont dans un espace priv clos, il n'y a aucune raison de les mapper car de toute faon, personne ne sera l pour les voir ( part les priopritaires), ni pour vrifier la pertinence de l'information (tout ce qu'on mappe doit tre "vrifiable", c'est une condition essentielle pour OSM; voir le wiki http://wiki.openstreetmap.org/wiki/Verifiability). Si les ruches sont sur terrain priv mais ouvert, ce qui est souvent le cas en France, cela redevient discutable (sinon, il faudrait aussi supprimer 99% des building dans OSM). Pieren ___ 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] Xapiviewer
Pour le linéaire court qui peut être considéré comme ponctuel à niveaux de zoom faible, cela va bien. Par contre, pour les limitations de vitesse du réseau routier, je trouve que ce que propose ITO est plus adapté http://www.itoworld.com/map/124#fullscreen Mais tous les goûts restent dans la nature :-) 2012/7/9 SylvainH nbelsylv...@aol.com Outil génialissime ! Et ça marche aussi pour les objets linéaires visiblement. J'ai fait le test avec les voies de détresse : http://osm.dumoulin63.net/xapiviewer/?zoom=10lat=43.40163lon=6.28964layers=0BTrequest=service%3Descape_laneicon=http%3A%2F%2Fimages.wikia.com%2Froutes%2Fimages%2F7%2F74%2FC26a.gif http://osm.dumoulin63.net/xapiviewer/?zoom=10lat=43.40163lon=6.28964layers=0BTrequest=service%3Descape_laneicon=http%3A%2F%2Fimages.wikia.com%2Froutes%2Fimages%2F7%2F74%2FC26a.gif Et avec les limitations de vitesse : http://osm.dumoulin63.net/xapiviewer/?zoom=15lat=50.59437lon=2.80933layers=0BTrequest=maxspeed%3D50icon=http%3A%2F%2Fimages1.wikia.nocookie.net%2F__cb20080413092910%2Froutes%2Fimages%2Fa%2Fa2%2FB14_50.gif http://osm.dumoulin63.net/xapiviewer/?zoom=15lat=50.59437lon=2.80933layers=0BTrequest=maxspeed%3D50icon=http%3A%2F%2Fimages1.wikia.nocookie.net%2F__cb20080413092910%2Froutes%2Fimages%2Fa%2Fa2%2FB14_50.gif -- View this message in context: http://gis.19327.n5.nabble.com/Xapiviewer-tp5715366p5715671.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 -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Noms des cantons sur la carte mapnik
2012/7/9 Philippe Verdy verd...@wanadoo.fr: C'est d'autant plus lassant de se faire insulter publiquement alors que je suis BEL ET BIEN resté dans le fil de discussion. La question de Rainer concernait: 1. les noms des cantons qui s'affichent un peu n'importe où 2. le double rendu des noms de communes (un pour le node, un pour la relation) Pour le 1., comme tu dis, Rainer, les données sont corrects. Après, leur affichage (ou pas) avec Mapnik est un problème de rendu. Mais je pense comme toi que c'est un problème gênant de rendu. Pour le 2., on modélise les communes avec un node place=* et une relation de type boundary. Le double affichage pourrait - là aussi - être supprimé mais c'est un travail à faire dans la chaîne de traitement des données pour Mapnik, dans osm2pqsql ou post-import par ex.. Il suffirait d'appliquer la règle suivante : si la relation porte un role admin_centre et que celui-ci pointer vers un noeud taggué place avec un name identique à la relation - ne pas afficher le nom de la relation. On teste si les noms sont identiques parce qu'on a vu quelques (rares) cas où le nom de la commune diffère du nom des agglomérations (par exemple, dans le cas des fusions). Voili, voila. Y-a-pu-ka Maintenant, ceux qui veulent discuter du rôle des cantons n'ont qu'à le faire sur le forum de www.millefeuilleadministratiffrancais.fr (et qui, depuis la création des métropoles, va se renommer www.milleetunefeuilleadministratiffrancais.fr) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger la petit patrimoine
Pour en revenir aux ruchers, je suis par contre plutôt d'avis de ne pas les mettre dans OSM... car cette information est trop volatile FORTUNE !!! Le 9 juillet 2012 16:29, Nicolas Moyroud nmoyr...@free.fr a écrit : ** Je m'excuse d'en remettre une couche concernant les piscines, car il y a vraiment une chose que je ne comprend pas dans l'argumentaire de ceux qui disent même si c'est visible sur Bing ou le cadastre, je ne les met pas parce que c'est privé. Mais alors pourquoi mettez vous les bâtiments privés dans OSM ? En tenant ce raisonnement, vous ne devriez mettre ni les piscines privées, ni les bâtiments privés. C'est quand même très étrange en France cette paranoïa sur les piscines, je n'arrive pas à saisir d'où vient le problème... Pour en revenir aux ruchers, je suis par contre plutôt d'avis de ne pas les mettre dans OSM, même si en ce qui me concerne ça pourrait m'être bien utile, étant très allergique aux piqûres de ces petites bêtes ! Je trouve que cette information est trop volatile car certains ruchers sont souvent déplacés. Si en plus il y a des vols possibles, alors effectivement ça pose un problème éthique supplémentaire. Mais en tout cas le voleur, ce ne sera pas moi ! :-) Et puis bon on ne sait jamais : les guêpes asiatiques consulteraient-elles OSM ? ;-) a+ Nicolas Le 05/07/2012 16:54, Pieren a écrit : 2012/7/5 Eric eric...@sfr.fr Je vois quand meme une nuance de taille avec les autres exemples cités : on ne tague quand meme pas à l'intérieur des proprietes privées ! (les piscines etant un contre exemple border-line). Pas border-line, complètement inside-line, oui. Ceux qui mappent les piscines argumentent sur le fait que c'est visible depuis le ciel (Bing) ou du cadastre. Ce qui se voit depuis l'espace public serait donc toujours légitimement cartographiable (perso, je ne le fais pas pour les piscines). Si les ruches sont dans un espace privé clos, il n'y a aucune raison de les mapper car de toute façon, personne ne sera là pour les voir (à part les priopriétaires), ni pour vérifier la pertinence de l'information (tout ce qu'on mappe doit être vérifiable, c'est une condition essentielle pour OSM; voir le wiki http://wiki.openstreetmap.org/wiki/Verifiability). Si les ruches sont sur terrain privé mais ouvert, ce qui est souvent le cas en France, cela redevient discutable (sinon, il faudrait aussi supprimer 99% des building dans OSM). Pieren ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://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
Re: [OSM-talk-fr] Comment tagger la petit patrimoine
2012/7/9 Nicolas Moyroud nmoyr...@free.fr: Mais alors pourquoi mettez vous les bâtiments privés dans OSM ? En tenant ce raisonnement, vous ne devriez mettre ni les piscines privées, ni les bâtiments privés. Peut-être parce que les piscines privées sont souvent invisibles depuis l'espace public et qu'elles donnent des informations sur le niveau de vie de ses propriétaires. Alors que la présence ou la surface d'un bâtiment ne donne pas d'indication aussi claire (même si, par recoupement, on peut deviner les niveaux de fortunes par la surface et la localisation du bâti privé). Le problème n'est pas tant le bâti tout seul ou la piscine toute seule ou l'adresse toute seule ou le nombre d'étages tous seuls mais l'accumulation de données personnelles auquel il ne manque que le nom des personnes (sauf lorsqu'ils sont ajouté pour les professions libérales). Je trouve que cette information est trop volatile car certains ruchers sont souvent déplacés. Je pense qu'il y a consensus ici pour ne parler que des ruchers permanents. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Noms des cantons sur la carte mapnik
Et j'avais parlé aussi du nom lui-même des cantons (la plupart sont nommés canton de xxx le préfixe étant inutile et surchargeant la carte pour rien puisqu'aucaun moteur de rendu ne sait abréger un tel nom, mais pourra toujours ajouter si nécessaire la mention canton à partir des attributs existants dans la relation de type-=boundary. Seulement voilà, au lieu de répondre à ça (c'était parfaitement dans le droit fil du sujet), on m'insulte publiquement et on invente des raisons de me contredire uniquement sur ce que je n'ai PAS marqué... Le 9 juillet 2012 16:43, Pieren pier...@gmail.com a écrit : 2012/7/9 Philippe Verdy verd...@wanadoo.fr: C'est d'autant plus lassant de se faire insulter publiquement alors que je suis BEL ET BIEN resté dans le fil de discussion. La question de Rainer concernait: 1. les noms des cantons qui s'affichent un peu n'importe où 2. le double rendu des noms de communes (un pour le node, un pour la relation) Pour le 1., comme tu dis, Rainer, les données sont corrects. Après, leur affichage (ou pas) avec Mapnik est un problème de rendu. Mais je pense comme toi que c'est un problème gênant de rendu. Pour le 2., on modélise les communes avec un node place=* et une relation de type boundary. Le double affichage pourrait - là aussi - être supprimé mais c'est un travail à faire dans la chaîne de traitement des données pour Mapnik, dans osm2pqsql ou post-import par ex.. Il suffirait d'appliquer la règle suivante : si la relation porte un role admin_centre et que celui-ci pointer vers un noeud taggué place avec un name identique à la relation - ne pas afficher le nom de la relation. On teste si les noms sont identiques parce qu'on a vu quelques (rares) cas où le nom de la commune diffère du nom des agglomérations (par exemple, dans le cas des fusions). Voili, voila. Y-a-pu-ka Maintenant, ceux qui veulent discuter du rôle des cantons n'ont qu'à le faire sur le forum de www.millefeuilleadministratiffrancais.fr (et qui, depuis la création des métropoles, va se renommer www.milleetunefeuilleadministratiffrancais.fr) Pieren ___ 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] Comment tagger la petit patrimoine
Le 9 juillet 2012 16:51, Pieren pier...@gmail.com a écrit : Je pense qu'il y a consensus ici pour ne parler que des ruchers permanents. +1 -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Noms des cantons sur la carte mapnik
Le 9 juil. 2012 à 16:07, Philippe Verdy a écrit : Le 9 juillet 2012 14:34, Christian Rogel christian.ro...@club-internet.fr a écrit : Les cantons n'ont JAMAIS eu de rôle administratif. Pourquoi redire une chose fausse? Parce que ta réponse de principe ici est encore plus fausse ! Relis ce que j'ai écrit, j'ai pourtant bien précisé qu'actuellement les cantons n'avait pas/plus ce rôle. Et malgré tout ils gardent un rôle en tant qu'instrument de planification et gestion du territoire, justement par la/les administrations encore existantes et dans des lois bien actuelles (loi électorale mais pas seulement). Désolé, je parle trop l'administratif,, car j'ai été contaminé en fréquentant trop longtemps une administration départementale avec pleins de cantons. ;-) Avoir un rôle administratif, dans le jargon, ça veut dire être une unité opérationnelle de l'administration, donc en faire partie. Cela ne peut pas vouloir dire unité de référence ou de mesure prise par une administration pour son action. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger la petit patrimoine
Est-on obligé de mentionner la position exacte de chaque ruche (avec un noeud) ? On ne pourrait pas avoir plutôt une mention des zones où une ou plusieurs ruches sont exploitées quand elles ne sont pas dans des lieux protégés (par exemple dans une petite pièce qui communique avec l'extérieur avec juste un tube dans certains immeubles en ville, ou sur un toit privé). Le but n'étant pas de localiser les ruches elles-mêmes mais l'activité des abeilles pour les protéger des pesticides et aussi permettre de développer certaines cultures, ou permettre des comptages pour la polinisation et planifier des zones sous-exploitées, ou détecter aussi des zones de pollution, ou mises sous surveillance et à des campagnes d'information pour leur protection, suite à une mortalité excessive, voire à d'autres interditions de ventes de certains produits au public dans leurs jardins. Le 9 juillet 2012 16:29, Nicolas Moyroud nmoyr...@free.fr a écrit : Pour en revenir aux ruchers, je suis par contre plutôt d'avis de ne pas les mettre dans OSM, même si en ce qui me concerne ça pourrait m'être bien utile, étant très allergique aux piqûres de ces petites bêtes ! Je trouve que cette information est trop volatile car certains ruchers sont souvent déplacés. Si en plus il y a des vols possibles, alors effectivement ça pose un problème éthique supplémentaire. Mais en tout cas le voleur, ce ne sera pas moi ! :-) Et puis bon on ne sait jamais : les guêpes asiatiques consulteraient-elles OSM ? ;-) Le 9 juillet 2012 17:07, Florian LAINEZ winner...@free.fr a écrit : Le 9 juillet 2012 16:51, Pieren pier...@gmail.com a écrit : Je pense qu'il y a consensus ici pour ne parler que des ruchers permanents. +1 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger la petit patrimoine
Je te renvoie à la description du wiki, donnée quelques messages plus tôt. http://wiki.openstreetmap.org/wiki/Proposed_features/apiary Tu devrais y trouver des éléments de réponse Le 9 juillet 2012 17:23, Philippe Verdy verd...@wanadoo.fr a écrit : Est-on obligé de mentionner la position exacte de chaque ruche (avec un noeud) ? On ne pourrait pas avoir plutôt une mention des zones où une ou plusieurs ruches sont exploitées quand elles ne sont pas dans des lieux protégés (par exemple dans une petite pièce qui communique avec l'extérieur avec juste un tube dans certains immeubles en ville, ou sur un toit privé). Le but n'étant pas de localiser les ruches elles-mêmes mais l'activité des abeilles pour les protéger des pesticides et aussi permettre de développer certaines cultures, ou permettre des comptages pour la polinisation et planifier des zones sous-exploitées, ou détecter aussi des zones de pollution, ou mises sous surveillance et à des campagnes d'information pour leur protection, suite à une mortalité excessive, voire à d'autres interditions de ventes de certains produits au public dans leurs jardins. Le 9 juillet 2012 16:29, Nicolas Moyroud nmoyr...@free.fr a écrit : Pour en revenir aux ruchers, je suis par contre plutôt d'avis de ne pas les mettre dans OSM, même si en ce qui me concerne ça pourrait m'être bien utile, étant très allergique aux piqûres de ces petites bêtes ! Je trouve que cette information est trop volatile car certains ruchers sont souvent déplacés. Si en plus il y a des vols possibles, alors effectivement ça pose un problème éthique supplémentaire. Mais en tout cas le voleur, ce ne sera pas moi ! :-) Et puis bon on ne sait jamais : les guêpes asiatiques consulteraient-elles OSM ? ;-) Le 9 juillet 2012 17:07, Florian LAINEZ winner...@free.fr a écrit : Le 9 juillet 2012 16:51, Pieren pier...@gmail.com a écrit : Je pense qu'il y a consensus ici pour ne parler que des ruchers permanents. +1 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] rencontre OpenData en Région PACA c'est le 10 juillet 2012 !!!
Pour ceux qui ne se sont pas inscrit et qui ne pourront pas venir... http://www.amiando.com/RJVCJHU.html Voici en avant première nos interventions : La présentation du matin sur la dynamique en Région PACA avec notre Pdt ;-) https://docs.google.com/open?id=0B4BuAP_kINa7eTMwd3ZvSjY3dzg La présentation de l'après-midi : nous animerons un atelier avec notre président pas tout à fait normal :-D avec un petit clin d'oeil sur l'initiative de la ville d'Orange https://docs.google.com/open?id=0B4BuAP_kINa7alBmR3Z2RG9GcDg Bonne lecture - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/rencontre-OpenData-en-Region-PACA-c-est-le-10-juillet-2012-tp5715707.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] Comment tagger la petit patrimoine
Le 9 juillet 2012 17:31, Ab_fab gamma@gmail.com a écrit : Je te renvoie à la description du wiki, donnée quelques messages plus tôt. http://wiki.openstreetmap.org/wiki/Proposed_features/apiary Tu devrais y trouver des éléments de réponse Je ne me posais pas de questions moi-même ; c'était juste un avis. De toute façon cette page n'est qu'une proposition, pas encore une pratique reconnue. Ca reste une ébauche donnant l'avis d'une personne. Les cas pratiques trouvés hors de sa zone ne sont pas encore évoqués. Cela reste expérimental, très peu utilisé pour l'instant et il y a d'autres propositions concurrentes. Le modèle n'est pas encore bien établi la page de discussion renvoie à d'autres possibilités, comme beehive en valeur d'une clé dont le choix n'est pas établi non plus) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article sur la qualité d'OpenStreetMap dans XYZ
Bonsoir à tous Ça y est j'ai eu la réponse^^ Donc c'est bon je peux le partager avec vous ;D Par contre il vaut mieux éviter que l'article se diffuse trop car il ferra l'objet d'une réédition pour les conférences Esri en octobre. Voici le lien: http://opheliepetit.fr/pdf/XYZ_131.pdf A bientôt. Le 29 juin 2012 15:58, THEVENON Julien julien_theve...@yahoo.fr a écrit : * De :* rldhont rldh...@gmail.com ** * *Bonjour, * * Comme indiqué ici http://www.agrotic.org/blog/?p=2722 * * L'article est issue d'un travail de fin d'étude. Le dossier complet de 71 pages est disponible ici : * *http://opheliepetit.fr/pdf/Dossierqualiteopenstreetmap.pdf Merci pour le lien. C est vraiment tres interessant ! Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Ophélie PETIT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article sur la qualité d'OpenStreetMap dans XYZ
2012/7/9 Ophélie PETIT ophelie.petit.cheval...@gmail.com: Bonsoir à tous Ça y est j'ai eu la réponse^^ Donc c'est bon je peux le partager avec vous ;D Par contre il vaut mieux éviter que l'article se diffuse trop car il ferra l'objet d'une réédition pour les conférences Esri en octobre. Voici le lien: http://opheliepetit.fr/pdf/XYZ_131.pdf A bientôt. Merci pour le partage, bien dans l'esprit dOSM :-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapping Party au Sénégal (Université Gaston Berger de Saint-Louis)
Bonjour Ismaïla, Je suis étudiant à l'Université Gaston Berger de Saint-Louis (au Sénégal) , président du club Informatique. Nous comptons organisé dans la semaine un exposé sur OSM+mapping party de la carte de l'université. J'ai initié cette activité pour l'intéret que je porte a OSM et je voudrais bien la faire partager. Je vais dire que je suis newbie et que je voudrais des conseils pour organiser cette activité. Je ne suis pas un grand patricien et je pense que d'autres personnes sur la liste auront des conseils plus avisés. Je pense qu'il faudrait d'abord faire le point sur le matériel à disposition : quelle est la qualité de la couverture par Bing à Saint-Louis ? De combien de GPS disposes-tu ? Quelles sont les infos déjà saisies ? Ensuite, comme ton périmètre d'intervention n'est pas trop grand, tu peux répartir par type d'information : un tel va relevé les chemins de circulation, tel autre les bâtiments, etc. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapping Party au Sénégal (Université Gaston Berger de Saint-Louis)
La Carte Bing couvre tout le Sénégal... :-) Nous comptons travailler sur elle(bing). L'université n'est pas trop grand et la plupart connaisse les endroits.. Donc nous aurions besion que de la carte de bing... Le but est surtout d'initier les etudiants à à OSM (et à JOSM). Apres nous essayerons de faire des MApping party plus élaborés. Merci. Le 9 juillet 2012 21:30, Vincent Calame vincent.cal...@exemole.fr a écrit : Bonjour Ismaïla, Je suis étudiant à l'Université Gaston Berger de Saint-Louis (au Sénégal) , président du club Informatique. Nous comptons organisé dans la semaine un exposé sur OSM+mapping party de la carte de l'université. J'ai initié cette activité pour l'intéret que je porte a OSM et je voudrais bien la faire partager. Je vais dire que je suis newbie et que je voudrais des conseils pour organiser cette activité. Je ne suis pas un grand patricien et je pense que d'autres personnes sur la liste auront des conseils plus avisés. Je pense qu'il faudrait d'abord faire le point sur le matériel à disposition : quelle est la qualité de la couverture par Bing à Saint-Louis ? De combien de GPS disposes-tu ? Quelles sont les infos déjà saisies ? Ensuite, comme ton périmètre d'intervention n'est pas trop grand, tu peux répartir par type d'information : un tel va relevé les chemins de circulation, tel autre les bâtiments, etc. Vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
