[OSM-talk] google wms
hi, apologies if this has been brought up before, but some people I have brought into OSM have stumbled across this site: http://www.peterdamen.com/GoogleWMS/ and were all set to pollute the OSM database when I stopped them. Can we not convince this gentleman to cease and desist? -- regards Kenneth Gonsalves Associate NRC-FOSS http://nrcfosshelpline.in/web/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM-WIKI: reducing redundancy, less redundant and standardized data exchange
Hi denny
I had a second look at the documentation and I now understand how Semantic
MediaWiki can help us.
Assume map features were described by three attributes: a key, a value and a
description, like
{MapFeature key=foo value=bar description=desc}
Then we would create a Wiki page [[Tag:foo=bar]] (as we do today):
--- beginwiki of [[Tag:foo=bar]]
bla bla bla
!-- the properties of Semantic MediaWiki --
[[key::foo]]
[[value::bar]]
[[description::desc]]
--- endwiki
On the [[Map Features]] page we could ask for this data (the following example
automatically creates a table,
we have full control over rendering using wiki templates, if we want to)
--- #beginwiki of [[Map Features]]
{{#ask: [[Tag:foo=bar]]
| ?key = Key
| ?value = Value
| ?description = Description
}}
--- #endwiki
On yet another page we could include information about the map feature:
--- #beginwiki of [[Yet another page]]
The map feature [[Tag:foo=bar]] is described as follows:
* Key: {{#show: Tag:foo=bar | ?key}}
* Value: {{#show: Tag:foo=bar | ?value}}
* Description: {{#show: Tag:foo=bar | ?description}}
--- #endwiki
I'd like to use SemanticWiki for the OSM wiki. This will bring us a step
further to managing map feature data.
I'd like to have a kind of sandbox to work on this. Could somebody provide an
installation of MediaWiki including SemanticWiki and a copy of the current OSM
Wiki content on a test server?
-- Karl
-Ursprüngliche Nachricht-
Von: Denny Vrandecic [mailto:d...@aifb.uni-karlsruhe.de]
Gesendet: Mittwoch, 24. Dezember 2008 10:07
An: talk@openstreetmap.org; karl.guggisb...@guggis.ch
Betreff: [OSM-talk] OSM-WIKI: reducing redundancy, less redundant and
standardized data exchange
(Karl, since the list is probably closed for outside postings, can you please
forward this answer to the list?)
I stumbled on this thread via Google Alert, so excuse me for not being much
knowledgeable about the OpenStreetMaps wiki (I'm a big fan of OSM,
though!) -- but I know a little bit about Semantic MediaWiki.
So one of the major ideas is indeed to be able to declare a piece of
information on one page, and then reuse the data in other places, especially
summary sites.
Example: on the Statue of Liberty page you would say Tourist
attraction=major and located in=New York, NY and on then, in other places,
you could create queries to summarize such data from the wiki, i.e.
List of all major tourist attractions:
{{#ask:[[Torist attraction::Major]]}}
or
List of all tourist attractions in New York, NY:
{{#ask:[[Tourist attraction::+]] [[located in::New York, NY]]}} etc.
If you want, keep me in the loop for this thread, and I will answer question.
I'd be very happy to see the OSM wiki use SMW, if it makes sense.
Cheers,
denny
Original message:
Hi there,
In [2] we see that there are partially redundante declarations of map features
(descriptions of keys or key/value-pairs for tagging OSM
primitives) in the wiki. The major reason for redundant is, that they appear
both on individual pages (like [[Key:heighway]] or [[Tag:highway=primary]]) and
on summary pages (like [[Map Features]]). So far we didn't come up with an
approach to *declare* a map feature only once on the Wiki (i.e. by
instantiating a suitable template) and to *use* this declaration both in
indvidual pages and in summary pages.
I don't see yet how Semantic MediaWiki could help use here because the limited
templating approach seems to remain unchanged. An example on how Semantic
MediaWiki could help to declare, say, the data for the key/value-pari
highway=primary would be very appreciated. Perhaps on the talk page of [2]?
-- Karl
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wed, Dec 24, 2008 at 9:58 AM, Andrew Chadwick (email lists) andrewc-email-li...@piffle.org wrote: Kenneth Gonsalves wrote: apologies if this has been brought up before, but some people I have brought into OSM have stumbled across this site: http://www.peterdamen.com/GoogleWMS/ and were all set to pollute the OSM database when I stopped them. Can we not convince this gentleman to cease and desist? Persuading the author to put up a big reminder at the top of the page saying OSM users: please upload only to private osm-api servers or somesuch might be more useful. The tool is presumably useful outside OSM! Well even so, it would probably be against the terms of use etc from Google, and they can ask for it to be taken down, so whilst it may be useful, it cannot be used... That saying, whilst it would apply to Google, it wouldn't be for everything. The tool could be used for other tiled layers - something of much greater use. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Place Names in Mapnik: Wikipedia article length as a heuristic
I love the idea of using wikipedia article size as a proxy for 'importance'. My idea was to do a google fight between overlapping labels. (San Francisco 227M hits, San Jose 93M hits) Aled On Wed, Dec 24, 2008 at 9:47 AM, Edward Betts edwardbe...@gmail.com wrote: How about we use the length of the Wikipedia article about a city to decide which should get rendered on OpenStreetMap? We could add a tag to each city with the Wikipedia article URL. Here are some figures for the Bay Area: San Francisco: 119958 Oakland: 113560 San Jose: 84823 Mountain View: 26124 Redwood City: 23369 South San Francisco: 20539 Daly City: 17288 Just an idea. -- Edward. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
2008/12/24 Andrew Chadwick (email lists) andrewc-email-li...@piffle.org: Kenneth Gonsalves wrote: apologies if this has been brought up before, but some people I have brought into OSM have stumbled across this site: http://www.peterdamen.com/GoogleWMS/ and were all set to pollute the OSM database when I stopped them. Can we not convince this gentleman to cease and desist? Persuading the author to put up a big reminder at the top of the page saying OSM users: please upload only to private osm-api servers or somesuch might be more useful. The tool is presumably useful outside OSM! It's a while since I read their TOS but I think this is disallowed too, you can only print out a copy for private use but not store the data (or derived data). Basically similar to mp3s of known artists. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wednesday 24 Dec 2008 3:21:36 pm Nick Black wrote: Thanks for bringing this up. I will pass this onto the Foundation team and get in touch with the person running the site. Have you tried to contact the site owner in the past? I havent - but I think the foundation should communicate with him - possibly make him an offer he cannot refuse? -- regards Kenneth Gonsalves Associate NRC-FOSS http://nrcfosshelpline.in/web/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wed, Dec 24, 2008 at 1:09 PM, Thomas Wood grand.edgemas...@gmail.com wrote: Frederik does make a good point that it could be used for good. I'm probably stupid but what is the aim of having google maps layers in JOSM - one editor for OSM data - excepted for copy ? I still see why people create online mashups where we can compare gmaps and OSM. But here we are inside an editor... Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wed, Dec 24, 2008 at 10:07:06AM +, Tim Waters (chippy) wrote: Well even so, it would probably be against the terms of use etc from Google, and they can ask for it to be taken down, so whilst it may be useful, it cannot be used... It’s up to Google to do that, we can’t speak for them. We have already spoken from our side of things by interpreting Google’s terms of service and seeing how they fit with the OpenStreetMap licence and said Google’s data cannot be used to contribute to OSM. -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wed, Dec 24, 2008 at 12:09:40PM +, Thomas Wood wrote: I brought this up in IRC a few weeks back, and I know its been brought up before that. It's also appeared on the mls before, Richard's response pretty much sums it up.. http://lists.openstreetmap.org/pipermail/dev/2008-September/011891.html I’m with that, for Potlatch. The version of Potlatch thats online on the OSM site only uploads to OSM. We can’t use Google’s data to contribute to OSM, so it would be extremely silly to implement the ability to. I'll also note that it was originally announced on the JOSM mailing list here: http://lists.openstreetmap.org/pipermail/josm-dev/2007-October/000181.html Frederik does make a good point that it could be used for good. With JOSM, it’s different: JOSM isn’t tied to the OSM site, you can upload the data to anywhere else. However, I do feel that it should do something to prevent upload to OSM when layers with incompatible terms of use have been used. A possible consideration for a future API is to move the check there: JOSM uploads, and indicates what data sources were used in the editing session. Server checks, sees GoogleWMS, replies “I’m sorry Dave, I’m afraid I can’t do that.” Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wed, Dec 24, 2008 at 2:19 PM, Simon Ward si...@bleah.co.uk wrote: A possible consideration for a future API is to move the check there: JOSM uploads, and indicates what data sources were used in the editing session. Server checks, sees GoogleWMS, replies I'm sorry Dave, I'm afraid I can't do that. Simon Too easy to bypass : save data into file, reload the file then upload. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wed, Dec 24, 2008 at 02:34:13PM +0100, Pieren wrote: On Wed, Dec 24, 2008 at 2:19 PM, Simon Ward si...@bleah.co.uk wrote: A possible consideration for a future API is to move the check there: JOSM uploads, and indicates what data sources were used in the editing session. Server checks, sees GoogleWMS, replies I'm sorry Dave, I'm afraid I can't do that. Too easy to bypass : save data into file, reload the file then upload. Hard validation wasn’t the point. The point was to make the user think twice, just as with Richard’s comment on using GPSBabel to convert KML to GPX, then having to munge it to add timestamps. You can bypass such a check in the editor just as easily, but either method allows the editor to tell the user why there’s a problem. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wed, Dec 24, 2008 at 2:45 PM, Simon Ward si...@bleah.co.uk wrote: Hard validation wasn't the point. The point was to make the user think twice, just as with Richard's comment on using GPSBabel to convert KML to GPX, then having to munge it to add timestamps. You can bypass such a check in the editor just as easily, but either method allows the editor to tell the user why there's a problem. Let us not make this a KML-problem. It is a nice format to work with, well supported and with more features than GPX. All the work I have done with the international borders of Norway, have been based around KML, for a number of reasons (the two most important, being the ability to assign colors to markers and a good client to visualize the data in). In addition, I have had a hard time finding anything in Google Earth terms that limits tracing, as opposed to Google Maps where this is stated very clearly. - Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wed, Dec 24, 2008 at 03:14:14PM +0100, Gustav Foseid wrote: In addition, I have had a hard time finding anything in Google Earth terms that limits tracing, as opposed to Google Maps where this is stated very clearly. Just searching for “google earth terms of service” gives (among other hits), a combined “Google Maps/Earth Terms of Service” that clearly restricts the making of derivative works[1]. [1]: http://maps.google.com/help/terms_maps.html -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google Earth terms (was google wms)
On Wed, Dec 24, 2008 at 2:58 PM, Gustav Foseid gust...@gmail.com wrote: On Wed, Dec 24, 2008 at 3:32 PM, Simon Ward si...@bleah.co.uk wrote: On Wed, Dec 24, 2008 at 03:14:14PM +0100, Gustav Foseid wrote: In addition, I have had a hard time finding anything in Google Earth terms that limits tracing, as opposed to Google Maps where this is stated very clearly. Just searching for google earth terms of service gives (among other hits), a combined Google Maps/Earth Terms of Service that clearly restricts the making of derivative works[1]. [1]: http://maps.google.com/help/terms_maps.html Are those really terms for Google Earth and not for Google Maps? I get a Norwegian translation on that URL, that does not mention Google Earth at all. The title of the page is: Google Maps/Earth Terms of Service - http://maps.google.com/help/terms_maps.html The paragraph starts: By downloading, installing, or using the Google Earth software, accessing or using the Google Maps service So yes, they are really the Google Earth Terms of Service. These are the terms I have found for Google Earth: http://earth.google.com/intl/en-US/license.html These mention that you can only use the images in the Software, which I understand to allow tracing as long as it is done with the Google Earth trace tool. - Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Nick Black http://www.blacksworld.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] State of the Map domain... Have we lost it?
Have we lost the State of the Map Domain recently? Google still quotes OSM content for the URL, but the URL itself now points to a link farm! http://www.stateofthemap.org/ Regards, Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google Earth terms (was google wms)
On Wed, Dec 24, 2008 at 03:58:26PM +0100, Gustav Foseid wrote: Are those really terms for Google Earth and not for Google Maps? I get a Norwegian translation on that URL, that does not mention Google Earth at all. The English version is clearly titled as I have already indicated “Google Maps/Earth Terms of Service”. The main page heading says “Google Maps/Google Earth Terms and Conditions”. The first paragraph begins: “By downloading, installing, or using the Google Earth software, accessing or using the Google Maps service (together, the Products or Services), or accessing or using any of the content available within the Products, you agree to be bound by […]” See[1]. That’s clear enough to me, but maybe we should get Google to clarify these terms, and ensure other languages are also up‐to‐date? [1]: http://bleah.co.uk/~simon/stuff/osm/google_maps_earth_terms.png These are the terms I have found for Google Earth: http://earth.google.com/intl/en-US/license.html That mainly covers the Google Earth software and not much about the content. These mention that you can only use the images in the Software, which I understand to allow tracing as long as it is done with the Google Earth trace tool. Copyright doesn’t give anyone but the copyright holder permission (except maybe fair use/dealing) to copy/derive from works by default, so the lack of anything explicit with regards to tracing does not mean you can do so. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the Map domain... Have we lost it?
On Wed, Dec 24, 2008 at 03:38:16PM +, Peter Miller wrote: Have we lost the State of the Map Domain recently? Google still quotes OSM content for the URL, but the URL itself now points to a link farm! http://www.stateofthemap.org/ I guess we did, then someone realised. Extracts from whois stateofthemap.org: Domain Name:STATEOFTHEMAP.ORG Created On:20-Nov-2006 13:40:10 UTC Last Updated On:23-Dec-2008 17:13:33 UTC Expiration Date:20-Nov-2010 13:40:10 UTC Registrant ID:GODA-057234937 Registrant Name:Etienne Cherdlu Registrant Organization:OpenStreetMap Foundation Note the Last Updated date. -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Wed, Dec 24, 2008 at 1:01 PM, Pieren pier...@gmail.com wrote: On Wed, Dec 24, 2008 at 1:09 PM, Thomas Wood grand.edgemas...@gmail.com wrote: Frederik does make a good point that it could be used for good. I'm probably stupid but what is the aim of having google maps layers in JOSM - one editor for OSM data - excepted for copy ? I still see why people create online mashups where we can compare gmaps and OSM. But here we are inside an editor... That probably is the point. Not an issue in itself however, I've used JOSM in the past to derive data from various non-free sources for my own personal use; I didn't upload it to OSM however which is the point at which my editing patterns would have become a problem for the project, but no earlier. The tools built around this project get used for more than OSM itself. Actively working on restricting their use in conjunction with non-free data under any circumstance will most likely be futile in the long run compared to educating the userbase; especially as such use may be perfectly legitimate. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] google wms
On Thu, Dec 25, 2008 at 01:22:22AM +0100, Frederik Ramm wrote: A possible consideration for a future API is to move the check there: JOSM uploads, and indicates what data sources were used in the editing session. Server checks, sees GoogleWMS, replies “I’m sorry Dave, I’m afraid I can’t do that.” And slap some control freak crypto onto that so that nobody can circumvent it? And you missed the point of it in almost exactly the same way Pieren did. I never mentioned application signing or anything else like that. Trying to prevent people from circumventing such a measure is going to be extremely futile. I suggest you read my other reply before spouting off again. Merry Christmas, Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Android Naviation System
Android Naviation System met OpenStreetMap kaarten, echter waarom niet voor Nederland?? Zie: http://www.andnav.org/ Prettige feestdagen - http://www.and.com/christmascard/ !!! Arjan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Android Naviation System
On Wed, 2008-12-24 at 10:50 +0100, AND Automotive Navigation Data wrote: Android Naviation System met OpenStreetMap kaarten, echter waarom niet voor Nederland?? Zie: http://www.andnav.org/ Waarschijnlijk omdat http://www.openrouteservice.org/ wordt gebruikt. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] JOSM-Geschwindigkeit
On Wed, Dec 24, 2008 at 12:00:59AM +0100, Peter Vitt wrote: Rechercht habe ich nicht, da ich seit einigen Jahren in der Materie bin und daher denke, dass ich weiß, weovon ich rede. Und ja, es war anklagend, da es mich stört, dass auf solchen public mailinglists immer alles kaputt geredet werden muss. Wenn jemand einen Editor in C# schreiben möchte, dann sollte man ihn nicht fragen, warum er nicht C nimmt. Es werden wahrscheinli8ch Gründe vorhanden sein. Und der Es ging drum das JOSM langsam ist und dann der vorschlag kam einen editor in C# zu schreiben weil das ja schneller sei. Als gegenargument gab Frederik zum besten das Merkaartor (In C++ geschrieben) problemlos ganz Berlin laedt und in akzeptablen zeiten darstellt. Das ist der Benchmark an dem es sich zu orientieren gilt. Und ja - oftmals ist nicht die sprache die den ausschlag gibt sondern die algorithmen. Solange ich da mist baue kann das auch ein rewrite in C nichts bringen. Wenn meine Algorithment aber ausgereizt sind kann ich durch einen rewrite in C die letzten 5-10% rausholen. Ich glaube das sprachen wie Java und C# zur resourcenverschwendung einladen bzw es voellig wegabstrahieren. Ist ja auch laestig sich ueber memory layout gedanken zu machen - ist mir schon klar. Performance hat etwas mit effizientem umgang mit resourcen zu tun und in meinen Augen schliesst das sprachen wie Java und C# aus. Selbst c++ halte ich fuer extrem gefährlich in bezug auf speicher und deterministischen laufzeiten. Nicht das es nicht auch ginge aber meist bleibt dann von den C++ umfang meist nicht viel uebrig so das es auch C getan haette. Ich habe mit keinem Wort irgendjemandem verboten seine Lieblingssprache zu nehmen. Ich mache auch viel in Perl weil es schnell geht und man schnell ein proof of concept hat. Sobald ich jedoch einen grossen working set habe oder irgendetwas schneller sein muss das steige ich um auf C - Da kann ich beeinflussen das oft genutzte elemente meiner baeume in der selben cacheline sind etc ... Das Problem das highlevel sprachen overhead mitbringen ist systemimmanent und auch nicht wegzudiskutieren. Du optimierst mit deinem Gedanken die eine Resource Programmierer - der schnell an sein Ziel kommt ein Problem zu Loesen. Ich optimiere die resource CPU und Speicher. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Realnamen und Datenschutz
Solange dein GPS-Gerät nicht geeicht ist, wird bei Geschwindigkeitsüberschreitungen wohl nichts herauskommen. Was anderes ist es, wenn jemand die Gleise vom Bahndamm geklaut hat und dein Log verrät, dass du kurz vorher am selben Ort warst. Wahrscheinlich wirst du dann in eine Nervenheilanstalt verbracht, weil, so blöd kann man ja gar nicht sein. *scnr* ;) Wohl kaum! Wie soll Dir denn bewiesen werden, dass Du es warst? Du kannst immer noch behaupten, Du hättest das Gerät zu der Zeit verliehen gehabt oder was auch immer... Ein einzelner GPS-Geschwindigkeitswert mag verrauscht sein, aber die Durchschnittsgeschwindigkeit einer Strecke wird sehr präzise gemessen. Ein KfZ-Halter, der den Fahrer nicht identifizieren kann, muss das Bußgeld AFAIK trotzdem zahlen und bekommt zusätzlich die Auflage, ein Fahrtenbuch zu führen. Wahrscheinlich gibt es für GPS-Empfänger noch keine einschlägigen Urteile ;-) Ich sehe zur Zeit keine konkrete Gefahr, dass meine GPS-Daten von den Behörden ausgewertet werden. Anderenfalls würde ich meine Tracks nicht zur Verfügung stellen. Es werden bei OSM unnötigerweise viele personenbezogene Daten gesammelt und selbst an nicht angemeldete Nutzer weiterverteilt. Für das Erstellen der OSM-Daten sollte es egal sein, welcher Nutzer einen Track erstellt hat. Gruß Stephan (der noch nie für eine Geschwindigkeitsüberschreitung zahlen musste) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Nick ohne Realnamen
Am Wed, 24 Dec 2008 08:18:50 +0100 schrieb Bernd Distler o...@bd-programs.de: Wenn man dann seine Mails über die eigene Domain verschickt machen weder Nick noch Pseudonym Sinn, da hat man ja innerhalb von einer Minute raus, wie der Besitzer wirklich heißt ;-) Wenn es denn die eigene Domain ist. (: Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Nick ohne Realnamen
Am Wed, 24 Dec 2008 08:18:50 +0100 schrieb Bernd Distler o...@bd-programs.de: Wenn man dann seine Mails über die eigene Domain verschickt machen weder Nick noch Pseudonym Sinn, da hat man ja innerhalb von einer Minute raus, wie der Besitzer wirklich heißt ;-) Wenn es denn die eigene Domain ist. (: Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
On Wed, 24 Dec 2008, Florian Lohoff wrote: Es ging drum das JOSM langsam ist und dann der vorschlag kam einen editor in C# zu schreiben weil das ja schneller sei. Als gegenargument gab Frederik zum besten das Merkaartor (In C++ geschrieben) problemlos ganz Berlin laedt und in akzeptablen zeiten darstellt. Das ist der Benchmark an dem es sich zu orientieren gilt. Und ja - oftmals ist nicht die sprache die den ausschlag gibt sondern die algorithmen. Solange ich da mist baue kann das auch ein rewrite in C nichts bringen. Wenn meine Algorithment aber ausgereizt sind kann ich durch einen rewrite in C die letzten 5-10% rausholen. Ich glaube das sprachen wie Java und C# zur resourcenverschwendung einladen bzw es voellig wegabstrahieren. Ist ja auch laestig sich ueber memory layout gedanken zu machen - ist mir schon klar. JOSM ist bei großen Datenmengen deshalb langsam, weil die gesamte Datenliste bei jeder Aktion erneut durchsucht und neu dargestellt wird. Je größer die Datenmenge, desto langsamer wird JOSM. Und bei Flächen mit vielen Punkten wird es besonders langsam. Eine etwas vernünftigere Datenstruktur und in einigen Fällen die Vermeidung von Kopieroperationen würde hier Wunder wirken. Statt ständig neuen Editoren wären Verbesserungen an JOSM viel hilfreicher. Bis nämlich der gleiche Funktionsumfang nachprogrammiert ist, kann schon eine sehr lange Zeit vergehen. Meist wird das Projekt vorher einschlafen. P.S. Euer Sprachenstreit ist kindisch. Die Unterschiede in der Basisgeschwindigkeit der einzelnen Sprachen sind auf heutigen Plattformen nahezu uninteressant. Auch die Sprachen selbst übrigens. Wichtig sind die Algorithmen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Realnamen und Datenschutz
DarkAngel schrieb: Stephan Wolff schrieb: Aus den GPS-Tracks lassen sich bei aktiven Nutzern leicht Profile erstellen. User 007 wohnt bei A, arbeitet bei B, besucht abends oft C, am Wochenende gelegentlich auch D und kauft ein bei X, Y und Z. Als Verkehrsmittel hat er Auto und Fahrrad, selten Bus und Bahn und nur einmal eine Fähre benutzt. Er hat 2008 zwei Flugreisen gemacht, in -Hotels gewohnt und ist im Urlaub viel gewandert. Ein solches Profil wäre nicht nur für die Werbewirtschaft hoch interessant, sondern könnte auch Interesse bei Diensten mehr oder minder befreundeter Staaten wecken. Loggst Du 1. jedesmal mit, wenn Du zur Arbeit fährst/einkaufen gehst etc. und 2. lädst Du dieses Daten jedesmal auf den Server? Wenn ja, warum? Ich denke mal die Daten dienen hauptsächlich als Grundlage für das Eintragen von Straßen, Wegen usw. Wenn diese Wege erfasst sind, muss ich doch nicht weiter die GPS-Koordinaten auf den Server schaufeln. Klar wird die Position des Weges bei 200 verschiedenen GPS-Spuren um ein paar Zentimeter genauer als bei 5 Spuren. Aber ist das wirklich hilfreich? Darüber hinaus kann man die GPS-Daten vor dem Upload auch entsprechend bearbeiten. Meine Tracks enthalten nie meinen Wohnort, das Ziel eine Reise und ähnliche persönliche Daten. Man muss auch nicht immer den gesamten Track hochladen, sondern beschränkt sich auf Teile davon. Meinen direkten Weg zur Arbeit habe ich nur einmal aufgezeichnet (um ein Stück Radweg im Park zu verbessern), aber wenn ich nach der Arbeit noch eine Radtour mache, dann schalte ich das GPS ein, wenn ich mich aufs Rad setze. Viele innerstädtische Nebenstraßen in Kiel haben keinen, andere 1-3 und nur wenige mehr GPS-Tracks. Daher beginnen vielleicht ein halbes Dutzend Tracks werktags zwischen 17 und 18 Uhr nahe meinem Arbeitsplatz. Meist schalte ich das GPS erst aus, wenn ich an meiner Wohnung oder am Supermarkt angekommen bin. Oft lösche ich unnötige Teile aus dem Track, manchmal nicht. Warum muss sich jeder Nutzer die Mühe machen, seine Tracks von Hand zu bereinigen, wenn man die Nutzerzuordnung auch in der OSM-Datenbank unterdrücken könnte? Spätestens wenn ich Post vom Ordnungsamt bekomme, in der mir vorgeworfen wird acht mal einen Fußweg mit mehr als 15km/h benutzt zu haben, in den Lärmschutzbereich der Autobahn mit 127km/h eingefahren zu sein und ein Bahngleis, auf dem am nächsten Tag ein Güterzug kam unbefugt betreten und dabei den Bahnverkehr gefährdet zu haben, dann werde ich mich ärgern, meinen Realnamen angegeben zu haben. Nur mal angenommen, eine Behörde hätte Interesse, die technischen (und geistigen) Möglichkeiten und die restlichen Befugnisse einen GPS-Track von OSM Deiner Person aus der Mailingliste zuzuordnen: Was soll Dir diese Behörde deswegen vorwerfen können??? Der Track selbst enthält keine Informationen, wer ihn wie und unter welchen Voraussetzungen aufgezeichnet hat. Darüber hinaus lässt sich ein solcher Track ohne Probleme und ohne Spuren zu hinterlassen manipulieren. Damit ist er als Beweismittel ziemlich wertlos. Die Beispiele waren eher fiktiv. Ich hätte auch schreiben können, dass Chef nachsieht, wohin ich vor 17 Uhr gegangen bin oder die Freundin wissen will, wo ich vor drei Wochen war. Als vor einigen Monaten ein Holzklotz von einer Autobahnbrücke geworfen wurde und eine Frau erschlagen hat, hat die Polizei sämtliche Mobiltelefondaten aus der Umgebung abgefragt und die Verbindungs- und Standortdaten intensiv ausgewertet. Nach meiner Erinnerung sprachen die Tagesthemen von mehreren hundert betroffenen Handybesitzern (obwohl es natürlich nicht bewiesen war, dass diese selbst vor Ort waren). Ob diese Datennutzung angemessen war, mag ich nicht entscheiden. Wer sein Handy ausgeschaltet hatte oder nicht unter seinem Realnamen registriert hatte, blieb unverdächtig. Wenn Du aber solche Bedenken hast, lege Dir doch einen zweiten Account bei OSM zu, wechsel vor und nach dem Upload des Tracks die IP Deines Rechner damit sie nicht in Verbindung zu Deinen Postings gebracht wird Meine nach außen sichtbare IP ist nicht die des PC, sondern die des Routers, die der vom ISP bekommt. Selbst mit einem zweiten Account sieht man aber immer noch die Häufungspunkte der verschiedenen Tracks. Wenn ich aber für jeden Track einen neuen OSM-Account mit einer jeweils neuen Emailadresse verwende und die Daten nur aus einem Internetcafe übertrage ... Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Realnamen und Datenschutz
Stephan Wolff schrieb: Ein KfZ-Halter, der den Fahrer nicht identifizieren kann, muss das Bußgeld AFAIK trotzdem zahlen und bekommt zusätzlich die Auflage, ein Fahrtenbuch zu führen. Wahrscheinlich gibt es für GPS-Empfänger noch keine einschlägigen Urteile ;-) Wir haben in Deutschland die Halterhaftung nur für Verstöße im ruhenden Verkehr (=Parken). Wegen Geschwindigkeit kann der Halter nicht zur Verantwortung gezogen werden. Fahrtenbuchauflage ja, unter bestimmten Umständen. Ich muss auch niemanden benennen, wenn es sich um Angehörige handelt (Zeugnisverweigerung). In Österreich schaut die Sache anders aus, die haben die sog. Lenkerauskunft, da muss der Fahrzeughalter angeben, wer gefahren ist. Da ich zu der Firma gehöre, die solche Verstöße verfolgt, weiß ich, wovon ich rede. Ein frohes Fest und nicht zu schnell mappen ;-) . Gruss Franz Stockerl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lasst wieder Ruhe einkehren
Hallo Leute, was macht ihr denn da eigentlich? Ist es denn nicht völlig egal ob jemand seine Beiträge mit Real-Namen oder Pseudo unterschreibt? Wenn ihr die Leute real kennenlernen wollt fahrt doch mal zu den lokalen Stammtischen/Treffen dort wird sich mit Realname angesprochen. Jedenfalls bei uns in Mittelhessen ist das so. Es gibt gute Gründe für beide Lager. Na und? Warum muss denn hier eine Missionierung stattfinden? OPEN ist das Stichwort!!! Schon vergessen? Das Gleiche gilt für die Programmiersprachen. Lasst doch bitte jeden nach seinen Vorlieben arbeiten. Wie derjenige das angeht soll er doch selbst entscheiden. Hauptsache ist, es kommt etwas produktives für das Projekt heraus. Bitte unterschätzt auch nicht den Frust-Gedanken bei Leuten die sich bisher aus welchen Gründen auch immer sehr engagiert haben. Ich möchte einfach mal eine Lanze für Leute wie Frederik, Jochen, Carsten, Gerhard, Markus und viele viele andere brechen. Die einen tauchen durch Ihre Arbeit an Programmen, Tools oder sonstigem immer wieder mal im Vordergrund auf, andere bleiben durch ihre eher stille Arbeit in der WIKI, der Mailingliste, in den Foren oder sonst irgendwo mehr im verbrogenen. Dennoch ist jede Mitarbeit wichtig und gut für das Projekt. Wer wie wann und in welcher Art mitarbeitet sollte er selbst entscheiden können. O P E N ist die Devise LG und frohe Weihnachten Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Oberpfalz im OSM Inspector
Hallo Jochen, Ich nehme an, Du hast Javascript aus oder irgendeinen Proxy oder Adblocker oder irgendsowas, was das Javascript kaputt macht. Ja, das ist auch die Hypothese von Frederik. Nur wie finde ich das heraus? und wie behebe ich das? Ich habe Java 1.6.0_011-b03 Da JOSM funktioniert nehme ich an, dass auch mein Java funktioniert? Aber beim Inspector laden die Overlays endlos. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
On Tue, Dec 23, 2008 at 11:10:10PM +0100, Wolfgang Wienke wrote: Sascha Rogmann schrieb: Beispiel: Radwege am Ring in Münster. http://www.openstreetmap.org/?lat=51.972437lon=7.633982zoom=18layers=00B0FTF Endlich finde ich mal einen Detail-Radwegmapper. Ich kenne natürlich nicht die Kreuzung in Münster. Mapps Du so auch Radwege, die direkt auf dem Bürgersteig liegen und von diesem nur z.B. durch die Farbe getrennt sind? - Ich würde das für sinnvoll halten, sehe dafür aber oft nur ein DAZUGESETZTES cycleway=track oder highway=path mit bicycle=yes. An größeren Straßen, z.B. Durchgangsstraßen, mappe ich auch Radwege, die auf dem Bürgersteig liegen, von diesem aber farblich getrennt sind. Dort sind dann leichte Schlenker zu sehen wenn für ein kurzes Stück (z.B. 80m) der Radweg und der bisher nicht gemappte Fußweg durch eine Baumreihe getrennt sind. Beispiel: Lublinring in Münster mit vielen GPS-Traces im JOSM. Ein Baumreihenwechsel ist oben links (links vom WLAN-X). http://www.rogmann.org/osm/josm_lublinring.png (JOSM-Ansicht zur oben angegebenen Beispiel-URL). Gruß, Sascha Rogmann ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Oberpfalz im OSM Inspector
Markus schrieb: Hallo Jochen, Ich nehme an, Du hast Javascript aus oder irgendeinen Proxy oder Adblocker oder irgendsowas, was das Javascript kaputt macht. Ja, das ist auch die Hypothese von Frederik. Nur wie finde ich das heraus? und wie behebe ich das? Ich habe Java 1.6.0_011-b03 Da JOSM funktioniert nehme ich an, dass auch mein Java funktioniert? Aber beim Inspector laden die Overlays endlos. Gruss, Markus Hi, Java hat mit JavaScript überhaupt nichts zu tun. Probier mal ein neues Profil (Firefox mit -p starten). Oder nutze die Gelegenheit und mach nen Update auf FF3, vorher FF2 inkl. Profile komplett löschen. Grüße, Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Realnamen
Hallo Leute, zum Encoding-Problem sollte man vielleicht eins nicht außer Acht lassen: Mit wem kommuniziere ich wie normalerweise? Wenn ich zwar ein eifriger Mapper bin, aber normalerweise ausschließlich mit meinem deutschen Freundeskreis Mails austausche, werde ich kaum in die Verlegenheit geraten, auf us-ascii oder utf-8 zurückfallen zu müssen. Es geht also hier nicht um Engstirnigkeit, sondern um die individuelle Situation. Nicht jeder ist sofort darauf eingestellt und macht sich darüber Gedanken, wenn er zum ersten Mal in ein internationales Projekt einsteigt. Ich denke, eine Empfehlung in Form einer Anleitung zum sinnvollen Versenden von Mails an Mailinglists in der Wiki würde Einsteigern das Schreiben und dem Rest das Lesen der ML erleichtern, ohne dass immer direkt Blut zum Kochen gebracht wird. Ich mache mir die Tage darüber ein paar Gedanken und fange mal etwas an. Dazu werden sich dann hoffentlich konstruktive Hinzufügungen finden. So, ich wünsch Euch damit erstmal schöne Feiertage LG Ralf Oltmanns aka TigerDuck Florian Lohoff wrote: set send_charset=us-ascii:iso-8859-1:iso-8859-15:utf-8 [...] Hier eine kleine statistik der letzten meiner mails: grep charset= * | sed -e 's/.*charset=//' | sort | uniq -c | sort -rn 767 us-ascii 648 iso-8859-1 23 utf-8 D.h. 50% meiner mails kommen mit us-ascii aus. Nur etwas mehr als 1% brauchen etwas anderes als Western-Europe. [...] signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Realnamen
Hallo. Am Mittwoch, 24. Dezember 2008 schrieb Ralf Oltmanns: [...] werde ich kaum in die Verlegenheit geraten, auf us-ascii oder utf-8 zurückfallen zu müssen. [...] Ich mache mir die Tage darüber ein paar Gedanken und fange mal etwas an. Dazu werden sich dann hoffentlich konstruktive Hinzufügungen finden. Wenn du das obige wirklich nicht besser weißt, solltest du vielleicht keine Anleitung dazu schreiben... ;-) scnr, Bernd -- Telefonmann meine tochter neulich im zoo in der arktisabteilung: guck mal papi - da sind linuxe :D - german-bash.org signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] osm.pm perl module
hallo, für alle, die ein wenig in perl rummachen. ich habe eine erste version meines osm.pm moduls veröffentlicht. ihr findet es auf meiner wiki seite http://wiki.openstreetmap.org/User:Gary68 es enthält nützliche routinen zum umgang mit osm, gpx und html files. weiterhin routinen zum rechnen, zum tiles anzeigen und file info. nicht alles ist neu, aber mal schön auf einem haufen. details weiter unten in der liste der bisher implementierten subs. beispiele gibt es in der 2. generation der waycheck programme. ebenfalls auf meiner wiki seite. ciao gerhard gary68 # binSearch ($value, @ref) $index or -1 # closeOsmFile () # checkOverlap (w1xMin, w1yMin, w1xMax, w1yMax, w2xMin, w2yMin, w2xMax, w2yMax)0=no overlap, 1=overlap # crossing (g1x1,g1y1,g1x2,g1y2,g2x1,g2y1,g2x2,g2y2) ($sx, $sy) # distance (x1,y1,x2,y2) $distance in km # getNode () ($gId, $gLon, $gLat, $gU, \...@gtags) ; # in main @array = @ $ref # getRelation # getWay () ($gId, $gU, \...@gnodes, \...@gtags) ; # in main @array = @$ref # hashValue ($lon, $lat) $hashValue # historyLink ($type, $key) $htmlString # josmLink ($lon, $lat, $span, $wayId) $htmlString # openOsmFile ($file) osm file open and $line set to first node # osbLink ($lon, $lat) $htmlString # osmLink ($lon, $lat) $htmlString # picLinkMapnik ($lon, $lat, $zoom) $htmlString # picLinkOsmarender ($lon, $lat, $zoom) $htmlString # printGPXHeader ($file) # printGPXFoot ($file) # printGPXWaypoint ($file, $lon, $lat, $text) # printHTMLHeader ($file, $title) print header to file # printHTMLFoot ($file) print foot to file # printNodeList ($file, @list) # printProgress ($program, $osm, $startTime, $fullCount, $actualCount) # printWayList ($file, @list) # shortestDistance ($gx1, $gy1, $gx2, $gy2, $nx, $ny) roughly the distance in km # skipNodes () # stringFileInfo ($file) $string # stringTimeSpent ($timeSpent in seconds) $string # tileNumber ($lat,$lon,$zoom) ($xTile, $yTile) # ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
Full ACK... mfG, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
Dirk Stöcker schrieb: Eine etwas vernünftigere Datenstruktur und in einigen Fällen die Vermeidung von Kopieroperationen würde hier Wunder wirken. Wäre es dann nicht eine Idee, so etwas wie eine plattformunabhängig Dev-Group zu bilden, die sich um solche Probleme (Datenstrukturen, Algorithmen) Gedanken macht? Dann können Editor-Entwickler sich mehr auf das Frontend (und was sonst noch alles dazu gehört) konzentrieren und Leute, die viel von den benötigten Datenstrukturen und Algorithmen verstehen, können sich an der Basis einbringen und einen Dienst für jedwede Sprache leisten, ohne gleich einen alternativen Editor entwickeln zu müssen oder Java zu lernen. Statt ständig neuen Editoren wären Verbesserungen an JOSM viel hilfreicher. Bis nämlich der gleiche Funktionsumfang nachprogrammiert ist, kann schon eine sehr lange Zeit vergehen. Meist wird das Projekt vorher einschlafen. Ich persönlich fände einen Alternativeditor nicht schlecht, da ich mit JOSM ehrlich gesagt, einige Probleme habe. Die Einstiegshürde ist mir etwas zu hoch. Hier könnte sich wahrscheinlich ein zweites oder drittes Editor-Dev-Team komplett losgelöst von JOSM neue Gedanken machen, die dann natürlich auch bei Erfolg in JOSM einfließen können. Ich sehe das ähnlich wie beim Hausbau. Es gibt Holzhäser und Steinhäuser und Fachwerkhäuser und was weuß ich nicht noch alles. Und nach und nach werden die Vorteile aller Hausarten kombiniert, um bessere Häuser zu bauen. P.S. Euer Sprachenstreit ist kindisch. Die Unterschiede in der Basisgeschwindigkeit der einzelnen Sprachen sind auf heutigen Plattformen nahezu uninteressant. Auch die Sprachen selbst übrigens. Wichtig sind die Algorithmen. Gebe ich dir recht. Ich rege mich nur immer extrem darüber auf, wenn so etwas in einer Mailing List aufkommt, da es, wie Hobby Navigator in seiner Mal schrieb, eine gewisse Frustschwelle gibt, an der ich bereits bei einem Projekt gescheitert bin. Daher bin ich wahrscheinlich für solch kindische Diskussionen sehr anfällig. Aber ich denke, mit Flos letzter Mail sind die Standpunkte und Ansichten klar und geklärt. mfG und ein frohes Fest, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ~20.000 probleme... weitere touch checks gelaufen
Gary68 schrieb: wege, die auf verschiedenen layern liegen, werden nicht geprüft. schau mal, ob nach dem lauf an den daten was verändert wurde. history link. ich habe ja den einen oder anderen schon gemacht. wenn's der zufall will... Sorry, war ein Fehlalarm. Es war tatsächich ein Node-fehler vorhanden. Dein Tool funktioniert! Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
On Wed, 24 Dec 2008, Peter Vitt wrote: Eine etwas vernünftigere Datenstruktur und in einigen Fällen die Vermeidung von Kopieroperationen würde hier Wunder wirken. Wäre es dann nicht eine Idee, so etwas wie eine plattformunabhängig Dev-Group zu bilden, die sich um solche Probleme (Datenstrukturen, Algorithmen) Gedanken macht? Dann können Editor-Entwickler sich mehr auf das Frontend (und was sonst noch alles dazu gehört) konzentrieren und Leute, die viel von den benötigten Datenstrukturen und Algorithmen verstehen, können sich an der Basis einbringen und einen Dienst für jedwede Sprache leisten, ohne gleich einen alternativen Editor entwickeln zu müssen oder Java zu lernen. Eher nicht. Das Hauptproblem ist nicht das Design, sondern die Implementierung. Ideen für bessere Strukturierung des JOSM-Codes habe ich reichlich (immerhin programmiere ich schon ein paar Jahre), nur die Umsetzung ist alles andere als trivial. Deswegen fangen viele Anfänger auch lieber von vorn an. Das ist erstmal einfacher. Keiner will sehen, dass wenn ein wenig Zeit vergangen ist, das eigene tolle neue Projekt genau die gleichen Probleme hat, wie das alte. Nur hat sich das alte in der Zwischenzeit weiterentwickelt. In JOSM z.B. hat sich (auch durch meinen Mithilfe :-) dieses Jahr einiges getan. Permanent aufholen ist nicht so leicht wie mancher denkt. Statt ständig neuen Editoren wären Verbesserungen an JOSM viel hilfreicher. Bis nämlich der gleiche Funktionsumfang nachprogrammiert ist, kann schon eine sehr lange Zeit vergehen. Meist wird das Projekt vorher einschlafen. Ich persönlich fände einen Alternativeditor nicht schlecht, da ich mit JOSM ehrlich gesagt, einige Probleme habe. Die Einstiegshürde ist mir etwas zu hoch. Hier könnte sich wahrscheinlich ein zweites oder drittes Editor-Dev-Team komplett losgelöst von JOSM neue Gedanken machen, die dann natürlich auch bei Erfolg in JOSM einfließen können. Momentan haben wir 3+1 Editoren (Potlatch, JOSM, Merkaartor und JOSM-NG). Jetzt kommt noch einer dazu. Das sollte eine Weile reichen. Das Potential an Softwareentwicklern ist nicht unendlich und je mehr man sich hier zersplittert, desto schlechter sind die einzelnen Projekte. Andererseits belebt Konkurrenz das Geschäft. Der richtige Mittelweg ist nicht so leicht :-) Nur so als Hinweis - Obwohl ich JOSM mitentwickle finde ich 1) ein Java-Editor ist nicht der Weisheit letzter Schluß 2) die interne Struktur ist (teilweise stark) überarbeitungsbedürftig 3) eine Menge Designentscheidungen sind nicht optimal Nichtsdestotrotz bringe ich JOSM voran statt von vorn anzufangen. Wir haben alle mehr davon. Gebe ich dir recht. Ich rege mich nur immer extrem darüber auf, wenn so etwas in einer Mailing List aufkommt, da es, wie Hobby Navigator in seiner Mal schrieb, eine gewisse Frustschwelle gibt, an der ich bereits bei einem Projekt gescheitert bin. Daher bin ich Von Mails sollte man sich nicht abschrecken lassen. Unkonstruktives einfach ignorieren, den Rest zumindest überdenken oder beherzigen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
Dirk Stöcker schrieb: Momentan haben wir 3+1 Editoren (Potlatch, JOSM, Merkaartor und JOSM-NG). JOSM-NG ? Habe ich etwas verpasst? Viele Grüße, Chris-Hein Lunkhusen (formerly known as Chris66) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Oberpfalz im OSM Inspector
Markus schrieb: und habe FF3 runtergeladen. Jetzt funktioniert alles prächtig. Supi! Grüße, Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osm.pm perl module
Gary68 g...@... writes: hallo, für alle, die ein wenig in perl rummachen. ich habe eine erste version meines osm.pm moduls veröffentlicht. ihr findet es auf meiner wiki seite http://wiki.openstreetmap.org/User:Gary68 Hallo Gerhard, mit deinem Link stimmt etwas nicht. Du meintest sicher http://wiki.openstreetmap.org/index.php/User:Gary68 oder? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
Hallo, Chris-Hein Lunkhusen wrote: JOSM-NG ? Habe ich etwas verpasst? Offenbar ;-) JOSM-NG ist ein Prototyp einer JOSM-Neuimplementation mit verbessertem Design und stark optimierter Darstellungs-Engine, angefuehrt von Petr Nejedly, einem Sun-Mitarbeiter. Leider ist ausser der Darstellung noch nicht wirklich viel lauffähig, aber das, was da ist, ist eindrucksvoll und zeigt u.a. auch, dass man auch mit Java schnellen und speichereffizienten Code machen kann. Zu den genannten 3+1 Editoren gesellt sich übrigens noch ein fuenfter, naemlich der mobile osm2go, der auch stationaer einsetzbar ist und eingesetzt wird. Dieser Editor ist recht einfach, etwa eine Potlatch- Alternative, und fuer die Touchscreen-Bedienung optimiert, aber durchaus auch auf normalen Systemen brauchbar. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
Hallo, Peter Vitt wrote: Ich persönlich fände einen Alternativeditor nicht schlecht, da ich mit JOSM ehrlich gesagt, einige Probleme habe. Merkaartor ist eigentlich gar nicht schlecht und kann schon alles, was zum produktiven Einsatz gebraucht wird (runterladen, hochladen, GPX, Relationen, Dateien speichern, ...) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OT: Linuxe war: Plaedoyer fuer Realnamen
Telefonmann meine tochter neulich im zoo in der arktisabteilung: guck mal papi - da sind linuxe :D Seit wann kommen Pinguine in der Arktis vor? Zum Schutz vor den Eisbären hat man die doch in die Antarktis verbannt ;-) SCNR Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Realnamen und Datenschutz
In Österreich schaut die Sache anders aus, die haben die sog. Lenkerauskunft, da muss der Fahrzeughalter angeben, wer gefahren ist. Allerdings gibt es bei geringen Delikten davor die Anonymverfügung - wird die bezahlt, wird nie nachgefragt, wer's wirklich war. lg Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osm.pm perl module
yup sorry. Am Mittwoch, den 24.12.2008, 20:52 + schrieb Hobby Navigator: Gary68 g...@... writes: hallo, für alle, die ein wenig in perl rummachen. ich habe eine erste version meines osm.pm moduls veröffentlicht. ihr findet es auf meiner wiki seite http://wiki.openstreetmap.org/User:Gary68 Hallo Gerhard, mit deinem Link stimmt etwas nicht. Du meintest sicher http://wiki.openstreetmap.org/index.php/User:Gary68 oder? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Intersezione tra strade e confini
Ho un dubbio su come trattare le intersezioni tra strade (ed altre way) e confini dei comuni: mi sembra che i modi possibili siano: 1) creare un nodo sull'intersezione, condiviso da strada e confine, nel punto in cui adesso c'e` il confine 2) andare sul posto, prendere con precisione decente il punto in cui i cartelli segnalano il confine ed in quel punto aggiungere un nodo condiviso da strada e confine 3) lasciare strada e confine indipendenti dato che tendenzialmente le strade cambiano nome quando cambiano comune, io sarei propensa alla 2, a meno che non ci siano validi motivi di mantenibilita` per seguire la 3; la 1 non mi sembra ottimale perche' i confini sono decisamente meno precisi delle strade, e prima o poi andrebbero cambiati -- Elena of Valhalla homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
Il 24 dicembre 2008 10.24, Elena of Valhalla elena.valha...@gmail.com ha scritto: Ho un dubbio su come trattare le intersezioni tra strade (ed altre way) e confini dei comuni: mi sembra che i modi possibili siano: 1) creare un nodo sull'intersezione, condiviso da strada e confine, nel punto in cui adesso c'e` il confine 2) andare sul posto, prendere con precisione decente il punto in cui i cartelli segnalano il confine ed in quel punto aggiungere un nodo condiviso da strada e confine 3) lasciare strada e confine indipendenti dato che tendenzialmente le strade cambiano nome quando cambiano comune, io sarei propensa alla 2, a meno che non ci siano validi motivi di mantenibilita` per seguire la 3; la 1 non mi sembra ottimale perche' i confini sono decisamente meno precisi delle strade, e prima o poi andrebbero cambiati io uso la 3 sono due entità completamente diverse e secondo me devo stare separate -- Elena of Valhalla ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
Elena of Valhalla ha scritto: Ho un dubbio su come trattare le intersezioni tra strade (ed altre way) e confini dei comuni: mi sembra che i modi possibili siano: 1) creare un nodo sull'intersezione, condiviso da strada e confine, nel punto in cui adesso c'e` il confine 2) andare sul posto, prendere con precisione decente il punto in cui i cartelli segnalano il confine ed in quel punto aggiungere un nodo condiviso da strada e confine 3) lasciare strada e confine indipendenti dato che tendenzialmente le strade cambiano nome quando cambiano comune, io sarei propensa alla 2, a meno che non ci siano validi motivi di mantenibilita` per seguire la 3; la 1 non mi sembra ottimale perche' i confini sono decisamente meno precisi delle strade, e prima o poi andrebbero cambiati Direi che la soluzione 1) e' quella che si puo' (si deve) fare a tavolino, essendo improbabile che ci si possa recare fisicamente sul confine comunale/provinciale/regionale e fare una sosta abbastanza lunga da restituire una precisione decente. Successivamente, quando capitera' l'occasione, si fara' il rilievo di cui al 2) ed il nodo di cui al punto 1) dovra' essere spostato di conseguenza. La soluzione 3) e' IMHO senz'altro da scartare. Ciao e tanti auguri a tutta la lista /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
2008/12/24 niubii f.pelu...@libero.it: Direi che la soluzione 1) e' quella che si puo' (si deve) fare a tavolino, essendo improbabile che ci si possa recare fisicamente sul confine comunale/provinciale/regionale e fare una sosta abbastanza lunga da restituire una precisione decente. dipende dalle strade: sulle strade principali si puo` passare piu` volte in entrambe le direzioni (ed e` facile che capiti di percorrerle frequentemente), prendere ogni volta il waypoint e poi fare una media, sulle strade secondarie fermarsi non e` piu` difficile di quanto non sia farlo per prendere la posizione di un numero civico -- Elena of Valhalla homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
Il 24 dicembre 2008 10.36, niubii f.pelu...@libero.it ha scritto: Direi che la soluzione 1) e' quella che si puo' (si deve) fare a tavolino, essendo improbabile che ci si possa recare fisicamente sul confine comunale/provinciale/regionale e fare una sosta abbastanza lunga da restituire una precisione decente. Successivamente, quando capitera' l'occasione, si fara' il rilievo di cui al 2) ed il nodo di cui al punto 1) dovra' essere spostato di conseguenza. perchè volete unire due entità diverse? scusate quando fate un ponte mettete un punto sul fiume? secondo me è molto più corretto tenere le entità separate e mettere un punto per interrompere la strada il più vicino al confine... La soluzione 3) e' IMHO senz'altro da scartare. perchè scusa? Ciao e tanti auguri a tutta la lista /niubii/ ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
Il giorno 24 dicembre 2008 10.36, niubii f.pelu...@libero.it ha scritto: Direi che la soluzione 1) e' quella che si puo' (si deve) fare a tavolino, essendo improbabile che ci si possa recare fisicamente sul confine comunale/provinciale/regionale e fare una sosta abbastanza lunga da restituire una precisione decente. Successivamente, quando capitera' l'occasione, si fara' il rilievo di cui al 2) ed il nodo di cui al punto 1) dovra' essere spostato di conseguenza. La soluzione 3) e' IMHO senz'altro da scartare. Io ho sempre pensato che non ci dovesse essere collegamento tra i tracciati e gli admin level. Inoltre spezzettare una strada per vedere in quale provincia/comune ricade a cosa potreppe servire, visto che la competenza è del proprietario delle strada, che spesso esula dalla collocazione particolare? Vincenzo. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
Il giorno 24/dic/08, alle ore 10:55, Luca Delucchi ha scritto: Il 24 dicembre 2008 10.36, niubii f.pelu...@libero.it ha scritto: perchè volete unire due entità diverse? scusate quando fate un ponte mettete un punto sul fiume? secondo me è molto più corretto tenere le entità separate e mettere un punto per interrompere la strada il più vicino al confine... Concordo.. che senso ha unire una strada a un confine? sono due entità completamente diverse! Nel caso particolare in cui la strada cambiasse nome attraversando il confine la si potrebbe interrompere con un nodo messo lì vicino, no? Ma altrimenti tutto questo non ha senso.. senza contare il fatto che i confini, a differenza delle strade, non sono facili da tracciare (non sono disegnati sul terreno :-) , quindi non è semplice seguirli col gps), e quindi sarebbe meglio toccarli il meno possibile, per evitare l'accumularsi di errori non sempre individuabili.. Mario Piccinelli --- Dreamers come and go, but a dream's forever Freedom for all minds, let us go together Neverending ways, got to roam forever Always carry on! --- Mail/Gtalk: mario.piccine...@gmail.com (GNUPG Key id: EE74003E) MSN: iamtheheroyoutr...@email.it Blog: http://piccimario.wordpress.com Skype: piccimario Mobile: 393-8944497 --- Proud Happy Mac (and Linux) User --- Confidentiality Notice: This message, together with its annexes, contains strictly confidential information and is destined only to the addressee(s) identified above who only may use it under his/their responsibility. Anyone who receives this message by mistake or reads it without entitlement is forewarned that keeping, copying, disseminating or distributing this message to persons other than the addressee(s) is strictly forbidden. PGP.sig Description: Questa è un messaggio firmato elettronicamente ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
Ciao On Wed, Dec 24, 2008 at 11:05 AM, Mario Piccinelli mario.piccine...@gmail.com wrote: Concordo.. che senso ha unire una strada a un confine? sono due entità completamente diverse! Nel caso particolare in cui la strada cambiasse nome attraversando il confine la si potrebbe interrompere con un nodo messo lì vicino, no? Dalle mie parti il caso particolare e` la norma: le strade che attraversano i confini hanno quasi tutte un nome, se non altro locale, che cambia sul confine: anche le statali tendono ad essere Via Qualcosa mi sembrava poco elegante mettere la separazione in un punto vicino (e non appartenente) al confine, perche' vorrebbe dire che ci sarebbero dei tratti piccoli, ma non nulli, di strade appartenenti al comune sbagliato ad esempio, in Paese c'e` via Tizio, che diventa via Caio entrando in Cittadina; in Cittadina c'e` anche una via Tizio, che pero` e` da tutt'altra parte; il punto su cui cambia la strada e` quasi sul confine, ma leggermente spostato dal lato di Cittadina Un programma che cerchi via Tizio a Cittadina ne trova due, una corretta ed una lunga magari 50 cm che in realta` e` Via Caio; e` vero che e` un caso facilmente escludibile, ma i programmi lo devono sapere e controllare senza contare il fatto che i confini, a differenza delle strade, non sono facili da tracciare (non sono disegnati sul terreno :-) , quindi non è semplice seguirli col gps), e quindi sarebbe meglio toccarli il meno possibile, per evitare l'accumularsi di errori non sempre individuabili.. infatti quello era il motivo che sospettavo potesse valere a favore della soluzione 3 -- Elena of Valhalla homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
On Wednesday 24 December 2008, Luca Delucchi wrote: Il 24 dicembre 2008 10.36, niubii f.pelu...@libero.it ha scritto: Direi che la soluzione 1) e' quella che si puo' (si deve) fare a tavolino, essendo improbabile che ci si possa recare fisicamente sul confine comunale/provinciale/regionale e fare una sosta abbastanza lunga da restituire una precisione decente. Successivamente, quando capitera' l'occasione, si fara' il rilievo di cui al 2) ed il nodo di cui al punto 1) dovra' essere spostato di conseguenza. perchè volete unire due entità diverse? Che entità diverse? Un punto è un punto. Se per un punto passa una strada ed anche un confine, usare lo stesso punto dà l'informazione aggiuntiva che il confine attraversa la strada proprio in quel punto. scusate quando fate un ponte mettete un punto sul fiume? No, perché di solito del ponte mi interessa dove inizia e dove finisce. E si potrebbe anche aggiungere, è sempre un punto in più, ma un fiume, tipicamente si sposta da una piena all'altra. Oppure è abbastanza largo da richiedere un'area, e non una retta. Ma non sarei contrario. secondo me è molto più corretto tenere le entità separate e mettere un punto per interrompere la strada il più vicino al confine... La soluzione 3) e' IMHO senz'altro da scartare. perchè scusa? Ciao e tanti auguri a tutta la lista /niubii/ ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Luciano Montanaro // \X/ mikel...@cirulla.net ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
Il giorno 24/dic/08, alle ore 11:58, Luca Delucchi ha scritto: Il tuo ragionamento è corretto, ma visto che non facciamo la mappa per i rendering tanto meno dobbiamo farla per i programmi o navigatori. Comunque io, e penso anche mario, intendevamo mettere un punto vicino al confine non a 50 metri ma a 1 metro... ;-) Concordo pienamente.. il massimo sarebbe mettere il punto di intersezione delle due strade appoggiato sul confine, cioè in mezzo a due punti della traccia del confine.. ma non parte del confine stesso, ovvero il nodo deve fare parte solo della strada e non anche del confine.. così si realizza una separazione logica tra due elementi che a mio avviso è bene che restino separati, per le ragioni che ho elencato in precedenza.. Mario Piccinelli --- Dreamers come and go, but a dream's forever Freedom for all minds, let us go together Neverending ways, got to roam forever Always carry on! --- Mail/Gtalk: mario.piccine...@gmail.com (GNUPG Key id: EE74003E) MSN: iamtheheroyoutr...@email.it Blog: http://piccimario.wordpress.com Skype: piccimario Mobile: 393-8944497 --- Proud Happy Mac (and Linux) User --- Confidentiality Notice: This message, together with its annexes, contains strictly confidential information and is destined only to the addressee(s) identified above who only may use it under his/their responsibility. Anyone who receives this message by mistake or reads it without entitlement is forewarned that keeping, copying, disseminating or distributing this message to persons other than the addressee(s) is strictly forbidden. PGP.sig Description: Questa è un messaggio firmato elettronicamente ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
2008/12/24 Luciano Montanaro mikel...@cirulla.net: On Wednesday 24 December 2008, Luca Delucchi wrote: scusate quando fate un ponte mettete un punto sul fiume? No, perché di solito del ponte mi interessa dove inizia e dove finisce. E si potrebbe anche aggiungere, è sempre un punto in più, ma un fiume, tipicamente si sposta da una piena all'altra. Oppure è abbastanza largo da richiedere un'area, e non una retta. Ma non sarei contrario. quando una strada passa sopra un fiume il ponte e` una caratteristica della strada, non del fiume: se al posto del fiume ci fosse una valle asciutta non cambierebbe niente; pero` se al posto del ponte ci fosse un guado ci sarebbe un punto comune a strada e fiume, dato che e` una caratteristica di entrambi, specifica di quell'intersezione. La stessa cosa si fa con strade e ferrovie: un ponte o un sottopasso sono caratteristica solo di una delle due, un passaggio a livello e` un punto in comune. la situazione del confine e` intermedia: il fatto di attraversare il confine in quel punto e` una caratteristica della strada, specifica del passaggio dal confine, mentre sul confine e` poco importante il fatto che in quel punto ci sia una strada -- Elena of Valhalla homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
2008/12/24 Luca Delucchi lucadel...@gmail.com Il tuo ragionamento è corretto, ma visto che non facciamo la mappa per i rendering tanto meno dobbiamo farla per i programmi o navigatori. Vorrei capire meglio, quindi ne parliamo a parte. Vincenzo. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
2008/12/24 Elena of Valhalla elena.valha...@gmail.com: 1) creare un nodo sull'intersezione, condiviso da strada e confine, nel punto in cui adesso c'e` il confine 2) andare sul posto, prendere con precisione decente il punto in cui i cartelli segnalano il confine ed in quel punto aggiungere un nodo condiviso da strada e confine 3) lasciare strada e confine indipendenti Nella mia scarsa esperienza mi è capitato una volta sola (per una ciclabile) e ho adottato l'approccio 3. Il punto di separazione della strada è stato registrato da me sul terreno (con precisione decente) mentre i confini amministrativi sono stati caricati una tantum a partire da dati Istat e non mi sembrano precisissimi. Nell'ipotesi che i confini amministrativi vengano periodicamente aggiornati con le novità (i comuni nascono e muoiono) sono del parere di disaccoppiare il più possibile i dati fisici da quelli amministrativi: in questo modo questi ultimi possono essere cancellati in massa e ri-creati senza creare danni alla mappatura dal vivo. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
Luca Delucchi ha scritto: Il 24 dicembre 2008 10.36, niubii f.pelu...@libero.it ha scritto: perchè volete unire due entità diverse? scusate quando fate un ponte mettete un punto sul fiume? E' un esempio che non c'entra niente. secondo me è molto più corretto tenere le entità separate e mettere un punto per interrompere la strada il più vicino al confine... Non vedo qual e' la difficolta'. Qui non si tratta di unire due entita', si tratta di spezzare una strada in un punto perche' in quel punto (e soltanto in quello, non a 50 o 1 mm) passa il confine. Quando hai cancellato i confini amministrativi che si sovrapponevano alla coastline, attribuendo a quest'ultima anche il valore di limite amministrativo, hai sostanzialmente fatto lo stesso. IMHO se per un punto passa una strada e un confine, quel punto deve avere entrambi gli attributi. La soluzione 3) e' IMHO senz'altro da scartare. perchè scusa? Perche' non sarebbe aderente alla realta'. Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
On Wed, Dec 24, 2008 at 1:17 PM, Luciano Montanaro mikel...@cirulla.net wrote: Se è segnalato sulla strada, è giusto che il punto si muova con la strada: Mettiamo che dopo alcuni passaggi la posizione del punto strada-confine venga corretta: se i punti sono disaccoppiati, devono essere corretti assieme, ed è facile dimenticare di spostare il confine. Se il punto è uno, correggendo il percorso della strada si corregge anche la posizione del punto di confine. Però... e se il cartello nella realtà non è messo nel punto precisissimo di confine? (siamo in Italia, mica in Germania...) E se i confini che abbiamo su OSM non sono precisi? Insomma secondo me non vale la pena di fare una micro-correzione ai confini su OSM (cioè aggiungere un punto al confine e spostarlo in base alle nostre rilevazioni) se tanto andiamo a correggere dati imperfetti sulla base di informazioni imperfette... Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
Mario Piccinelli ha scritto: Concordo.. che senso ha unire una strada a un confine? sono due entità completamente diverse! Nel caso particolare in cui la strada cambiasse nome attraversando il confine la si potrebbe interrompere con un nodo messo lì vicino, no? In attesa che in OSM vengano definite regole elementari in uso in ogni GIS, quali adiacenza, inclusione, etc non c'e' IMHO altro modo per cambiare attributo ad una strada che non spezzarla in corrispondenza del confine. Sarebbe inutile e pericoloso utilizzare un nodo a parte (non appartenente al confine) per spezzare la strada. Qui non si tratta di unire niente a nessuno, rimangono due cose separate. Una e' una entita' lineare (che si spezza), l'altro e' un poligono (che aumenta di un nodo). Non vedo il problema. Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 24 December 2008, Luca Delucchi wrote: Il 24 dicembre 2008 11.56, Luciano Montanaro mikel...@cirulla.net ha scritto: On Wednesday 24 December 2008, Luca Delucchi wrote: Il 24 dicembre 2008 10.36, niubii f.pelu...@libero.it ha scritto: Direi che la soluzione 1) e' quella che si puo' (si deve) fare a tavolino, essendo improbabile che ci si possa recare fisicamente sul confine comunale/provinciale/regionale e fare una sosta abbastanza lunga da restituire una precisione decente. Successivamente, quando capitera' l'occasione, si fara' il rilievo di cui al 2) ed il nodo di cui al punto 1) dovra' essere spostato di conseguenza. perchè volete unire due entità diverse? Che entità diverse? Un punto è un punto. intendevo entità strada con entità confine, che tra l'altro il primo è un qualcosa di fisico mentre il confine è qualcosa di astratto Secondo me qui la confusione deriva da un modello che si usa. Per quello che capisco, il modello di OSM è fatto di una nuvola di punti, da linee spezzate e da poligoni. Linee spezzate e poligoni fanno riferimento tutti alla stessa nuvola di punti, e li qualifica. Anche i punti singoli possono avere delle qualifiche a sé stanti (ad es. possono indicare un semaforo o un bar). Quindi assegnare lo stesso punto a più linee spezzate o poligoni non è un'operazione proibita, anzi, in un certo senso è un'ottimizzazione. Se per un punto passa una strada ed anche un confine, usare lo stesso punto dà l'informazione aggiuntiva che il confine attraversa la strada proprio in quel punto. si ma attraverso le query spaziali non è fondamentale quell'informazione, però può causare problemi nell'editazione, in più i confini che ci sono ora non sono il massimo della precisione... Che problemi può dare? E sul fatto che i confini attuali non siano il massimo della precisione siamo d'accordo; ma se, durante un'uscita, sulla strada vedo l'indicazione di un confine, posso migliorare, almeno localmente la precisione del confine. Anche la stima peggiore effettuata con un'antenna GPS mi pare meglio di quella attuale, che credo sia fatta per mappe a scale 1:10^6 o giù di lì. Luciano. -- Luciano Montanaro // \X/ mikel...@cirulla.net ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it - -- Luciano Montanaro // \X/ mikel...@cirulla.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklSKu4ACgkQaeOY6B53J4UPkACeJ04QFQJRLj7kUNKGqOFW2nU5 MWEAni/OxsGA7BO5gJ70heKQTGoLwSAj =dyB3 -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
On Wed, Dec 24, 2008 at 1:21 PM, niubii f.pelu...@libero.it wrote: La soluzione 3) e' IMHO senz'altro da scartare. perchè scusa? Perche' non sarebbe aderente alla realta'. Domanda da 100 milioni di dollari: cos'è la realtà? Se io mi trovo nel punto X (misurato tramite GPS, con una tolleranza di tot metri) vedo che una strada cambia nome, questo è un fatto reale. Se tu mi dici che il fatto che la strada cambi nome nel punto X discende dal fatto che in quel punto passa il confine, questo fatto mi sembra meno reale: a. stiamo supponendo che la strada cambi nome perché cambia comune: è ragionevole ma non è detto (bisognerebbe controllare le delibere del comune) b. stiamo supponendo che la strada cambi nome perché il quel punto c'è il confine: è ragionevole ma non è detto (chi ha messo i cartelli potrebbe avere commesso un errore di qualche metro, magari per comodità - a volte i cartelli di fine e inizio comune non sono attaccati ma distano qualche metro: non vuol dire che il tratto a metà sia terra di nessuno!) c. non sono proprio d'accordo che i confini amministrativi siano reali - cosa succede nella realtà quando oltrepasso il confine? Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
2008/12/24 Luciano Montanaro mikel...@cirulla.net: Che problemi può dare? E sul fatto che i confini attuali non siano il massimo della precisione siamo d'accordo; ma se, durante un'uscita, sulla strada vedo l'indicazione di un confine, posso migliorare, almeno localmente la precisione del confine. Anche la stima peggiore effettuata con un'antenna GPS mi pare meglio di quella attuale, che credo sia fatta per mappe a scale 1:10^6 o giù di lì. Ora capisco meglio il tuo punto di vista... cioè in pratica sostieni l'approccio 2: rilevo dal vivo il cambio di confine e lo riporto su OSM. Mi sembra ragionevolissimo ma ho una sola obiezione: sei proprio sicuro che hai rilevato il *vero* cambio di confine? Il problema è che il confine non è tracciato per terra lungo tutta la sua lunghezza, ma appare solo quando interseca altre entità (es. strade). Siamo proprio sicuri che tutte le intersezioni stiano state calcolate correttamente da chi di dovere, cioè da chi ha posto i cartelli? Esempio pratico: quando esco dal comune di Milano ed entro in quello di Buccinasco (vicino a casa mia) il cartello di fine comune e quello di inizio comune non sono sovrapposti, ma sono ad una distanza di una decina di metri perché in mezzo c'è un incrocio. Come posso usare questa informazione per migliorare la mappa? Quale dei due punti uso? Non sono neanche sicuro che il confine sia compreso tra i due punti: magari passa lì vicino e chi ha messo i cartelli ha deciso che quella era la disposizione più ragionevole. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
On Wed, Dec 24, 2008 at 1:07 PM, Federico Cozzi f.co...@gmail.com wrote: Nell'ipotesi che i confini amministrativi vengano periodicamente aggiornati con le novità (i comuni nascono e muoiono) sono del parere di disaccoppiare il più possibile i dati fisici da quelli amministrativi: in questo modo questi ultimi possono essere cancellati in massa e ri-creati senza creare danni alla mappatura dal vivo. dato che la precisione attuale dei dati dei confini e` minore di quella dei normali gps, mi risulta che qualcuno abbia gia` cercato di fare delle migliorie a mano, almeno dove sul territorio sono disponibili segni precisi ed utilizzabili, per cui una cancellazione di massa rischierebbe in ogni caso di far perdere informazioni migliori di quelle che si inseriscono d'altra parte, mi sembra che le novita` piu` frequenti sui confini siano di accorpamento e separazione: operazioni che magari fanno cancellare qualche tratta (o le fanno cambiare livello) o ne fanno aggiungere, ma spostamenti veri e propri mi risultano piu` rari -- Elena of Valhalla homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
On Wed, Dec 24, 2008 at 1:17 PM, Luciano Montanaro mikel...@cirulla.net wrote: Be' ma io pensavo più che altro all'aggiunta di nuovi punti, quando si incontra il cartello di fine comune/provincia... esattamente quello a cui pensavo anche io: trovo il cartello, segno la posizione, aggiungo il punto e poi lo uso per cio` per cui l'informazione e` utile -- Elena of Valhalla homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
-Original Message- From: talk-it-boun...@openstreetmap.org [mailto:talk-it- boun...@openstreetmap.org] On Behalf Of Federico Cozzi Sent: mercoledì 24 dicembre 2008 13.18 To: openstreetmap list - italiano Subject: Re: [Talk-it] Intersezione tra strade e confini 2. come può un navigatore capire in quale comune si trovi in una via propongo quindi che 2. mi appoggio a query spaziali oppure, per i casi critici, al tag is_in Le query spaziali come ben osservi andrebbero bene se la precisione dei confini fosse assoluta, il che non è. Per l'uso di un tag al posto di una relazione non ho obiezioni (anche se preferisco la relazione, perché l'interrogazione è più rapida), però l'uso del tag andrebbe ben specificato, il tag is_in al momento è un minestrone, qualcosa di simile ad una libera annotazione. Meglio se il caso crearne uno ad hoc. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
On Wed, Dec 24, 2008 at 1:23 PM, Federico Cozzi f.co...@gmail.com wrote: On Wed, Dec 24, 2008 at 1:17 PM, Luciano Montanaro mikel...@cirulla.net wrote: Se è segnalato sulla strada, è giusto che il punto si muova con la strada: Mettiamo che dopo alcuni passaggi la posizione del punto strada-confine venga corretta: se i punti sono disaccoppiati, devono essere corretti assieme, ed è facile dimenticare di spostare il confine. Se il punto è uno, correggendo il percorso della strada si corregge anche la posizione del punto di confine. Però... e se il cartello nella realtà non è messo nel punto precisissimo di confine? (siamo in Italia, mica in Germania...) dipende dall'errore: se l'errore e` di un paio di metri e` trascurabile rispetto all'errore del gps con cui lo si rileva, se l'errore e` superiore a quello dei confini che abbiamo attualmente credo che ci sia da preoccuparsi :) E se i confini che abbiamo su OSM non sono precisi? infatti non lo sono, e per questo vale la pena migliorarli Insomma secondo me non vale la pena di fare una micro-correzione ai confini su OSM (cioè aggiungere un punto al confine e spostarlo in base alle nostre rilevazioni) se tanto andiamo a correggere dati imperfetti sulla base di informazioni imperfette... tutte le informazioni presenti su OSM sono imperfette: quelle rilevate con un buon gps in buone condizioni hanno un errore di un paio di metri, quelle rilevate con gps peggiori magari un errore attorno ai 10 metri, quelle dei confini non ricordo, ma decisamente maggiore: perche' non migliorarli dove possibile, soprattutto considerando che dove possibile coincide anche con dove piu` utile? -- Elena of Valhalla homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
On Wed, Dec 24, 2008 at 1:33 PM, Federico Cozzi f.co...@gmail.com wrote: On Wed, Dec 24, 2008 at 1:21 PM, niubii f.pelu...@libero.it wrote: La soluzione 3) e' IMHO senz'altro da scartare. perchè scusa? Perche' non sarebbe aderente alla realta'. Domanda da 100 milioni di dollari: cos'è la realtà? Se io mi trovo nel punto X (misurato tramite GPS, con una tolleranza di tot metri) vedo che una strada cambia nome, questo è un fatto reale. in realta` io avevo in mente il fatto che nel punto X ci fossero due cartelli marrone, uno con scritto il nome di un comune e l'altro con il nome di un altro comune ed una barra rossa sopra teoricamente e` anche possibile fare un ragionamento simile con un cippo (si chiamano cosi`, vero?) di confine che sia vicino alla strada, anche se non ne ho mai notati, o con il cancello che c'e` tra le dogane per i confini di stato Se tu mi dici che il fatto che la strada cambi nome nel punto X discende dal fatto che in quel punto passa il confine, questo fatto mi sembra meno reale: a. stiamo supponendo che la strada cambi nome perché cambia comune: è ragionevole ma non è detto (bisognerebbe controllare le delibere del comune) questo sarebbe il caso in cui l'unico indizio siano due cartelli con il nome delle strade, e ammetto che non sia particolarmente preciso b. stiamo supponendo che la strada cambi nome perché il quel punto c'è il confine: è ragionevole ma non è detto (chi ha messo i cartelli potrebbe avere commesso un errore di qualche metro, magari per comodità - a volte i cartelli di fine e inizio comune non sono attaccati ma distano qualche metro: non vuol dire che il tratto a metà sia terra di nessuno!) beh, se dai due estremi della strada ci sono nomi diversi, supporre che il cambio di nome sia esattamente sul confine mi sembra ragionevole; che i cartelli non siano precisamente sul confine e` una questione diversa c. non sono proprio d'accordo che i confini amministrativi siano reali - cosa succede nella realtà quando oltrepasso il confine? cosa succede quando da Via Pinco incrociamo Via Pallino e proseguiamo dritti in via Tal dei Tali? -- Elena of Valhalla homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tag is_in (era: Intersezione tra strade e confini)
On Wed, Dec 24, 2008 at 1:53 PM, Alberto Nogaro bartosom...@yahoo.it wrote: 2. come può un navigatore capire in quale comune si trovi in una via propongo quindi che 2. mi appoggio a query spaziali oppure, per i casi critici, al tag is_in Le query spaziali come ben osservi andrebbero bene se la precisione dei confini fosse assoluta, il che non è. Per l'uso di un tag al posto di una relazione non ho obiezioni (anche se preferisco la relazione, perché l'interrogazione è più rapida), però l'uso del tag andrebbe ben specificato, il tag is_in al momento è un minestrone, qualcosa di simile ad una libera annotazione. Meglio se il caso crearne uno ad hoc. Leggendo nella documentazione del formato mappe Garmin vedo che ciascuna strada indica a quale comune, regione e stato appartiene; per ciascun attributo (comune, regione e stato) è possibile indicare più di un valore. Nel nostro caso potremmo fare: is_in:city=Milano;Buccinasco is_in:region=Lombardia is_in:country=Italia per una strada che passa sia per Milano che Buccinasco. Però, per non impazzire con i tag, ritengo che dovrebbe esistere un meccanismo di default, ad esempio tramite inclusione spaziale nei confini amministrativi: in questo modo si potrebbe usare il tag is_in solo per i casi critici. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tag is_in (era: Intersezione tra strade e confini)
On Wed, Dec 24, 2008 at 2:59 PM, Federico Cozzi f.co...@gmail.com wrote: On Wed, Dec 24, 2008 at 1:53 PM, Alberto Nogaro bartosom...@yahoo.it wrote: 2. come può un navigatore capire in quale comune si trovi in una via propongo quindi che 2. mi appoggio a query spaziali oppure, per i casi critici, al tag is_in Ho trovato la soluzione ufficiale: http://wiki.openstreetmap.org/wiki/FAQ#What_makes_a_road_belong_to_a_city.3F Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tag is_in (era: Intersezione tra strade e confini)
-Original Message- From: talk-it-boun...@openstreetmap.org [mailto:talk-it- boun...@openstreetmap.org] On Behalf Of Federico Cozzi Sent: mercoledì 24 dicembre 2008 15.00 To: openstreetmap list - italiano Subject: Re: [Talk-it] tag is_in (era: Intersezione tra strade e confini) Leggendo nella documentazione del formato mappe Garmin vedo che ciascuna strada indica a quale comune, regione e stato appartiene; per ciascun attributo (comune, regione e stato) è possibile indicare più di un valore. Non so se le cose siano cambiate, il mio vecchio Garmin aveva un meccanismo di ricerca degli indirizzi abbastanza assurdo. Anziché chiedere prima il comune e poi la via, chiedeva prima la via e poi offriva un elenco di comuni in cui esiste tale via. C'era da impazzire! I nomi dei comuni di solito sono precisi, anche perché sono pochi e saranno ben controllati. Ma con le vie, toccava provare tutte le varianti (via, viale, Garibaldi, G. Garibaldi, Giuseppe Garibaldi, ecc.) fino a vedere magicamente apparire il comune cercato nell'elenco. Senza contare i casi in cui il nome della via era stato inserito con errori tipografici. Nel nostro caso potremmo fare: is_in:city=Milano;Buccinasco is_in:region=Lombardia is_in:country=Italia per una strada che passa sia per Milano che Buccinasco. Si, specificato così potrebbe funzionare. Però, per non impazzire con i tag, ritengo che dovrebbe esistere un meccanismo di default, ad esempio tramite inclusione spaziale nei confini amministrativi: in questo modo si potrebbe usare il tag is_in solo per i casi critici. Si, hai ragione, se non si vuole duplicare informazioni in OSM, le informazioni spaziali su vie e confini dovrebbero bastare. Sono convinto che per un programma di navigazione, per rapidità sarebbe meglio avere memorizzati i risultati delle query spaziali precalcolate, ma è un problema del navigatore, non di OSM. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Intersezione tra strade e confini
niubii ha scritto: Federico Cozzi ha scritto: La soluzione 3) e' IMHO senz'altro da scartare. perchè scusa? Perche' non sarebbe aderente alla realta'. Domanda da 100 milioni di dollari: cos'è la realtà? Mi sembra che ci si stia allontandando un po' dal problema... :-) Una domanda del genere e' troppo impegnativa, passo. http://it.wikipedia.org/wiki/Realt%C3%A0 Se ti soddisfa, poi ti passo le coordinate del mio conto, così mi fai il bonifico. Se non ti soddisfa, puoi migliorare la voce :-) Se trovo un cartello che indica il limite territoriale, per me il limite e' quello. Amen. Se lo sposto, arbitrariamente, perche' secondo me e' sbagliato, innanzitutto commetto un errore di presunzione. Poi confondo chi passera' in quel punto dopo di me, che si rendera' conto della diversa posizione del confine reale da quello indicato nella mappa e vorra' correggere. Caso dei due segnali: Se ci sono due segnali distanti di qualche metro lungo una strada che non scavalca nessun ostacolo naturale (mai capitato) allora il confine e' IMHO nel mezzo. Se i due segnali si trovano sulle spalle di un ponte che scavalca un fiume IMHO il confine e' materializzato dal centro del letto del fiume. Se i due segnali si trovano agli angoli opposti di un incrocio IMHO il confine e' materializzato dal centro della carreggiata trasversale. Quotone! In sintesi, appoggio assolutamente l'idea del nodo comune tra confine e strada: mi chiedo anzi come si possa pensare che non debba essere così. Auguri! -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Frazioni
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciao a tutti. Ho mappato alcune zone come locality, ma ho sbagliato poiché popolate e con case. Queste zone sono frazioni del mio comune e dalla pagina del wiki non ho capito se segnalarle come hamlet, suburb o village. Stò parlando di zone identificabili rispetto al comune a cui sono legate quando ci si passa attraverso, non piccole come Borgo tre case :) e con varie decine di case. Jacopo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklSaxAACgkQgLJTK54vkCwgQwCfY5VxjVoxqMjk3wjHdO959Gkc 5o8AoIjkeZtemxCaKXC2MiC/G2bgC4Ou =K3nF -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Frazioni
jacopogg83 ha scritto: Queste zone sono frazioni del mio comune e dalla pagina del wiki non ho capito se segnalarle come hamlet, suburb o village. Cos'è che non capisci, esattamente? Mi interessa, perché il problema riappare ciclicamente, ma sinceramente adesso il wiki[1] mi sembra molto chiaro; se non fosse così, bisogna correggerlo. In estrema sintesi (ma, ripeto, è quello che è scritto sul wiki...): 1) la frazione è urbanisticamente autonoma rispetto al resto del comune? (ci sono campi/boschi tutt'attorno?) No --- suburb --- fine Sì --- 2) 2) La frazione è composta da poche case (cascina, piccolo nucleo rurale, ecc.)? No --- village --- fine Sì --- hamlet --- fine Dalla tua descrizione mi sembra di capire che si tratti di un village, ma solo tu puoi dirlo. Facci sapere se ora è più chiaro, al limite integra in modo che tu sia l'ultimo a porre questa domanda :-) Se invece ti riferisci a questa[2] pagina, effettivamente merita un restyling: ci pensi tu? Inizio con l'inserire il contenuto di questa e-mail. Buon Natale! Carlo [1] http://wiki.openstreetmap.org/wiki/IT:Map_Features#Places_.28territori.29 [2] http://wiki.openstreetmap.org/wiki/IT:Key:place -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-es] felices fiestas
a todos. cuidadín con el gps y las copitas. que salen unas trazas de mierda. sergio ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] Nussdorf vs. Nußdorf
On 12/24/2008 02:40 PM, Wolfgang W. Wasserburger wrote: Soweit ich weiß sucht OSB die nächsten Ortsnamen und setzt sie vor die Bugs. Daher nehm ich an gibt es irgendwo den Ortsteil Nussdorf. Da einige hier in letzter Zeit sehr fleißig waren in der Gegend, wollt ich mal anfragen ob jemand von euch weiß, wo der Node stecken könnte bzw. ob es ohnehin korrekterweise schon Nussdorf heißt (was mich doch wundern würde). Ich weiß zwar noch nicht, wie man von OSB automatisch Mitteilungen bekommt, aber die Sache mit dem scharfen S ist halt mit der neuen deutschen Rechtschreibung erst recht im A... Die Mitteilung stammt aus dem RSS Feed[0] für Wien und Umgebung. Der Eintrag ist vom 22.12. 1.) Straße zB ist gleich geblieben, daher ist mal die größte Panik vorbei. 2.) Eigennamen bleiben grundsätzlich unverändert, d.h. Her Nußbaum heißt jetzt nicht Nussbaum, daher auch Nußdorf und nicht Nussdorf; möglicherweise liefert OSB allerdings schreibvereinfachte Ausdrücke. Das wäre eine Möglichkeit, allerdings denk ich, ist es für OSB bei weitem einfacher nur den nächsten Ortsnamen durchzureichen, anstatt irgendwas zu vereinfachen. PS: wenn es Dir wirklich wichtig ist, suche ich das morgen auch in der gesamten Datenbank :-) Nein, wichtig ist es gar nicht, mich hat eigentlich das Doppel-S nur optisch im RSS Feed gestört. ;-) lg, Norbert [0] http://openstreetbugs.appspot.com/getRSSfeed?b=48.07883710371094t=48.34103122837863l=16.04270489458862r=16.79320843459772 ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Nussdorf vs. Nußdorf
PS: wenn es Dir wirklich wichtig ist, suche ich das morgen auch in der gesamten Datenbank :-) In der Datenbank gibt es nach schnellem Durchsuchen nur einen Node mit Nussdorf und zwar: 316450642;2008-12-03 16:06:49;railsnail;46.8364680;12.8021952; mit folgenden Tags: 2511478;316450642;amenity;place_of_worship 2511477;316450642;religion;christian 2511476;316450642;created_by;Potlatch 0.10f 2511475;316450642;name;Nussdorf außerdem gibt es einen way: 25629781;2008-12-23 11:02:04;Loth it folgenden Tags: 2511478;316450642;amenity;place_of_worship 2511477;316450642;religion;christian 2511476;316450642;created_by;Potlatch 0.10f 2511475;316450642;name;Nussdorf Thats it CU Wolfgang and merry xmas :-))) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk-fr] osm2pgsql
Bonjour tout le monde, j'ai eu envie d'importer les données osm dans postgresql, et pour les visualiser rapidement d'utiliser QGIS. Malheureusement QGIS refuse de bosser car il ne trouve pas de primary key sur les tables, et effectivement il n'y en a pas. Est-ce un problème sur ma version osm2pgsql (0.55-20081223 £Rev: 10464) ? Comment corriger cela ? Cordialement Pascal -- ALICE N°1 de la RELATION CLIENT 2008* Découvrez vite l'offre exclusive ALICE BOX! En cliquant ici http://abonnement.aliceadsl.fr Offre soumise à conditions.*Source : TNS SOFRES / BEARING POINT. Secteur Fournisseur d.Accès Internet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] osm2pgsql
ne cherchez pas ou plus ! je crois que la réponse est là : http://oegeo.wordpress.com/2008/03/07/turning-openstreetmap-into-a-wfs/ Cordiamlement Pascal -- Initial Header --- From : talk-fr-boun...@openstreetmap.org To : Discussions sur OSM en françaistalk-fr@openstreetmap.org Cc : Date : Tue, 23 Dec 2008 21:55:04 +0100 Subject : Re: [OSM-talk-fr] Impardonnable ! -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xav a écrit : Ils sont rigolos dans le coin. Au sud de Voeu il y a Saint-Valentin. Au nord ouest on trouve aussi Vatan, et sur l'une des pancartes de sortie de village, on peut lire et ne te retournes pas - -- Thomas Clavierhttp://www.tcweb.org +33 (0)6 20 81 81 30 JabberID : t...@jabber.tcweb.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklRUCgACgkQStsfiGuIVEO3cwCfZHHsTGHGaIyetWKpZv/ODeUk r3oAnivfkjV9LK62jQE6EnF5tt0ABB+Q =JVSZ -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ALICE N°1 de la RELATION CLIENT 2008* Découvrez vite l'offre exclusive ALICE BOX! En cliquant ici http://abonnement.aliceadsl.fr Offre soumise à conditions.*Source : TNS SOFRES / BEARING POINT. Secteur Fournisseur d.Accès Internet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osm2pgsql
tu peux en rajouter une toi meme: ALTER TABLE planet_osm_point ADD COLUMN gid serial; ALTER TABLE planet_osm_point ADD CONSTRAINT gid_pkey PRIMARY KEY (gid); etc pour les autres tables, a+ thomas 2008/12/24 pascal.ferr...@aliceadsl.fr pascal.ferr...@aliceadsl.fr: Bonjour tout le monde, j'ai eu envie d'importer les données osm dans postgresql, et pour les visualiser rapidement d'utiliser QGIS. Malheureusement QGIS refuse de bosser car il ne trouve pas de primary key sur les tables, et effectivement il n'y en a pas. Est-ce un problème sur ma version osm2pgsql (0.55-20081223 £Rev: 10464) ? Comment corriger cela ? Cordialement Pascal -- ALICE N°1 de la RELATION CLIENT 2008* Découvrez vite l'offre exclusive ALICE BOX! En cliquant ici http://abonnement.aliceadsl.fr Offre soumise à conditions.*Source : TNS SOFRES / BEARING POINT. Secteur Fournisseur d.Accès Internet ___ 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] Projet de production de cartes scolaires, fond de cartes, etc...
Je crains que nous, sur notre liste de diffusion en langue française soient trop isolés, trop en marge, pour que quelqu'un au niveau international nous écoute, Quoique certains, et je les en remercie, se font porte-parole, mais cela ne fait pas délégation, ni notre porte-parole, Et je pense qu'en parallèle de cette liste ici il faille qu'on aille s'investir individuellement sur la mailing list internationale, afin d'être entendus, même si ça frise, même si on ne maîtrise pas l'anglais 'comme il faut' (il y en a d'autres, dans des situations semblables) et même si ça fait faire des efforts en sus... Parce que, si on n'y va pas, des questions et demandes comme celle d'Axel (ci-dessous) tournent en bourrique localement, restent confinés en vase clos dans notre petit univers francophone, sans que jamais ces questions arrivent chez les gens qui peuvent y faire quelque chose... --- S'il se trouve que les Islandais, les Chinois, les Ouzbeques, les Ukraïniens, ou les New-Yorkais tirent déjà leurs cartes pour l'enseignement depuis OSM et ont fait les outils nécessaires pour agencer ça ? --- Il y a bien certains parmi nous ici, qui s'engagent à la mailing list internationale, mais ça ne suffit pas. Ce n'est pas représentatif, malgré leurs efforts (merci à eux, déjà). 'Faut être conscients que nous, francophones, nous ne sommes pas le nombril du monde, et que notre liste de diffusion ici n'est qu'un morceau infime de l'ensemble d'OSM, et que nous sommes loin d'être le centre. : Je pense que près de 96 % des OSMeurs du monde ignorent qu'on existe, ici, nous... Donc à nous, d'aller vers eux. A ceux, qui ont le temps dispo pour ce faire... Amicalement Gerhard --- Moi-même hélas n'ai que peu de temps dispo, me bats avec la survie 'tout court', donc dois laisser ça à des gens plus libres que moi. -- Le 23 déc. 08 à 15:31, Axel R. a écrit : C'est un peu lié à ma demande. Je pense que si certaines choses apparaissait sur les rendus, ça motiverait ceux qui mappent à utiliser ces relations/fonction. Mais je comprends que l'on ne peut pas tout mettre sur le même rendu et qu'il faut avoir un rendu par usage que l'on veut. Un pour la voiture Un pour le vélo (avec les dénivelé, magasin de location, borne vélib...) Un pour la rando à pied (les GR, les petits chemins) Un pour les scolaires (avec les lacs, forêt, délimitation administrative) Un pour les déplacements en transport en commun. Certains rendus peuvent répondre à des besoins différents, mais en surchargeant le moins possible une carte, on la rend d'autant plus lisible. Axel D'ailleurs je me suis essayé à la relation ligne de bus l'autre jour, mais je n'ai nulle part trouvé où tester un rendu de cette relation. Quelqu'un a-t'il ca sous le coude ? Il m'avait semblé avoir lu un truc la dessus sur un blog OSM (par l'auteur de la cyclemap si je me souviens bien). a+, ___ 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-GB] Birmingham Traces
Hi, Since Birmingham is now finished, I'd like to mark this occasion. It is customary to do a video render of all the GPS traces collected over a mapping party, so a complete video render of the City over the last few years seems apt. Here's the video so far: http://uk.youtube.com/watch?v=3VC7UpoYBeA I've so far collected 400+ traces that I think are in the Birmingham area, but there still seems to be gaps on the render. Could anyone who knows they have collected traces in the Birmingham area tag their GPS traces accordingly. I can then do a batch download based on that tag from the OSM server. If you are unsure that you covered Birmingham with a particular trace then may I suggest tagging them with Midlands. I'm only rendering those that appear in a box around the city so being a little bit out shouldn't matter. If you uploaded them anonymously then please send me the GPS traces directly. I plan to do the render before New Years, so if the GPX traces could be taggged/sent before then it would be help. Thanks Ciarán ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Announcement: Hull completed
I would like to announce that the fine city of Kingston Upon Hull (Hull to its friends and 'Ull to its locals) has all its public roads and many of its amenities completed. Almost all of the city was mapped by Jean and me by driving or walking around it. We have taken about 10,000 photos (my camera rolled its number over about a month ago) and visited every single public road in the city. We've added schools, cemeteries, pubs, allotments, parks and some shops all by visiting them with a GPS and camera - the Y! images are only lo-res and have been useful only for large scale stuff like some railways, waterways and the docks. We have seen the city in a new light - some of it is run down, but much of it is doing very nicely. I have enjoyed the experience greatly (though some housing estates have been a bore) and now I look forward to helping complete the East Riding of Yorkshire next year. The latest map is: http://www.openstreetmap.org/?lat=53.7673lon=-0.3378zoom=13layers=0B00FTF http://www.openstreetmap.org/?lat=53.7673lon=-0.3378zoom=13layers=0B00FTF Our blog of the experience is: http://chris-osm.blogspot.com/ which also is on the planet-osm digest. http://blogs.openstreetmap.org/ Cheers, Chris ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Announcement: Hull completed
I would like to announce that the fine city of Kingston Upon Hull (Hull to its friends and 'Ull to its locals) has all its public roads and many of its amenities completed. Congratulations! and now I look forward to helping complete the East Riding of Yorkshire next year. I was about to say that there's a challenge ahead there but (looking for the first time for a few weeks) it looks like that's coming along too. Certainly more complete than some of the neighbouring counties including (ahem) some of the ones near me. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Announcement: Hull completed
Awesome work Chris, join the small club of now ex mappers ;-) Cheers Andy -Original Message- From: talk-gb-boun...@openstreetmap.org [mailto:talk-gb- boun...@openstreetmap.org] On Behalf Of Chris Hill Sent: 24 December 2008 10:58 AM To: Talk GB Subject: [Talk-GB] Announcement: Hull completed I would like to announce that the fine city of Kingston Upon Hull (Hull to its friends and 'Ull to its locals) has all its public roads and many of its amenities completed. Almost all of the city was mapped by Jean and me by driving or walking around it. We have taken about 10,000 photos (my camera rolled its number over about a month ago) and visited every single public road in the city. We've added schools, cemeteries, pubs, allotments, parks and some shops all by visiting them with a GPS and camera - the Y! images are only lo-res and have been useful only for large scale stuff like some railways, waterways and the docks. We have seen the city in a new light - some of it is run down, but much of it is doing very nicely. I have enjoyed the experience greatly (though some housing estates have been a bore) and now I look forward to helping complete the East Riding of Yorkshire next year. The latest map is: http://www.openstreetmap.org/?lat=53.7673lon=- 0.3378zoom=13layers=0B00FTF http://www.openstreetmap.org/?lat=53.7673lon=- 0.3378zoom=13layers=0B00FTF Our blog of the experience is: http://chris-osm.blogspot.com/ which also is on the planet-osm digest. http://blogs.openstreetmap.org/ Cheers, Chris ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.0/1862 - Release Date: 23/12/2008 12:08 PM ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Announcement: Hull completed
On 24 Dec 2008, at 17:43, Andy Robinson (blackadder-lists) wrote: Awesome work Chris, join the small club of now ex mappers ;-) I thought that club was called I moved house to map more. [I'm sure someone will come up with a better name.] Shaun smime.p7s Description: S/MIME cryptographic signature ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Announcement: Hull completed
I thought that club was called I moved house to map more. [I'm sure someone will come up with a better name.] I discovered Harlow had high res Yahoo imagery and have started tracing houses? (Hint) Ed ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] US Route Tagging With Relations
Chris, Thanks for putting up that table. Looks great. I have two suggestions: I think the network identifiers should be simpler. What about this scheme? Interstate = Interstate signed highway system US = US signed highway system [state abbr.] = State signed highway system TX = Texas CA = California OR = Oregon etc... County or other networks should just be the county name or TN Secondary, etc... To avoid duplicate network values (CA stands for California and Canada) we can use the is_in key the same way it is used for place names. So a California route relation would have these tags: network: CA is_in: United States Or a county road system in california: network: Marin Co is_in: California, United States This way we don't clutter up the network name, but we keep the differentiating information. My other suggestion is that I don't thing the symbol key is necessary. I think the renderers should be able to assign a symbol based on the network and is_in tags once they get to that stage. This way they symbols will stay more consistent and we won't get US highway shields that look slightly different throughout the country. Thoughts? Zeke ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Route Tagging With Relations
A couple thoughts: 1) Commercial data providers have use a route type parameter that designates something as an Interstate, Federal Highway, State Highway, County Road, or Farm-to-Market road. This code does not distinguish between states; all state highways have the same route type. General practice is to use the same highway shield for all states; you don't get the Beehive sign for Utah. :) This is an opportunity for OSM to distinguish itself; if local users contribute Highway signs from their region - down to very specialized signs for something like Kettle Moraine Scenic Route in Southeast Wisconsin - they'll have something the commercial vendors don't provide. However, there should be something clearly identify a route as a state, county/parish, farm-to-market road/ whatever, so a default shield could be picked. 2) I don't like the is_in approach - the US:CA approach seems to offer all the appropriate information in the same place. However, if there was a way to explicitly state that this is a state route, that would help in the situation mentioned above. 3) There should be a place for people to contribute highway shields - as metadata. Respecifying highway shields for every route would be prone to omissions. In the case of Kettle Moraine Scenic Route - it's so specialized, it may make sense to apply the sign to the route itself. But having a place to submit a library of highway shields as metadata - that would be good. From: Zeke Farwell ezeki...@gmail.com To: Talk-us talk-us@openstreetmap.org Sent: Wednesday, December 24, 2008 7:50:20 AM Subject: Re: [Talk-us] US Route Tagging With Relations Chris, Thanks for putting up that table. Looks great. I have two suggestions: I think the network identifiers should be simpler. What about this scheme? Interstate = Interstate signed highway system US = US signed highway system [state abbr.] = State signed highway system TX = Texas CA = California OR = Oregon etc... County or other networks should just be the county name or TN Secondary, etc... To avoid duplicate network values (CA stands for California and Canada) we can use the is_in key the same way it is used for place names. So a California route relation would have these tags: network: CA is_in: United States Or a county road system in california: network: Marin Co is_in: California, United States This way we don't clutter up the network name, but we keep the differentiating information. My other suggestion is that I don't thing the symbol key is necessary. I think the renderers should be able to assign a symbol based on the network and is_in tags once they get to that stage. This way they symbols will stay more consistent and we won't get US highway shields that look slightly different throughout the country. Thoughts? Zeke ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Route Tagging With Relations
On Wed, Dec 24, 2008 at 12:38 PM, Russ Nelson nel...@crynwr.com wrote: Alan Brown writes: 3) There should be a place for people to contribute highway shields - as metadata. To make life even more interesting, New York State renders placenames in the Adirondack Park using beige on brown, rather than the usual and standard white on green. Looks more woodsy. First, we need to get one of the renderers to support custom-drawn shields... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Route Tagging With Relations
Yeah we're getting a little ahead of ourselves with the shields. The first step is tagging the highways in a standard scheme which would give a renderer sufficient data to draw shields. Then someone has to actually build a renderer that draws the shields. Thats a whole other can of worms. I don't think that the Slippy Map on openstreetmap.org will ever draw custom shields beyond blue interstate shields, white US highway shields, and white ovals for state routes. I think it would be great to have a map with custom shields for every state. What we need for that to happen is someone to set up a US based Open Street Map renderer. In addition to custom shields, the highway colors could be drawn in more US centric way: varying shades of red, orange, and yellow with green reserved for toll roads. I think this would really help people in the US get involved with OSM because the map would look more familiar to them. The main slippy map is never going to do this though, because it is international. 2) I don't like the is_in approach - the US:CA approach seems to offer all the appropriate information in the same place. However, if there was a way to explicitly state that this is a state route, that would help in the situation mentioned above. The UC:CA approach does offer all the appropriate information in the same place. I don't think that is necessarily desirable though. For example, Vermont Route 30 is never called US Vermont Route 30. The network is just Vermont, not United States: Vermont. This is even more true for county roads. If Windham county in Vermont had it's own numbered routes one would not call a route United States, Vermont, Windham County Route 10. In short, I like the is_in approach because keeps the network name simple. I'd rather not have to bother with the is_in tag at all. For someone mapping there is no confusion as to whether a highway is Canadian Route 10 or California Route 10 (unless they are really bad at geography), but I suppose this could get confusing for the renderers. Ideally, I would say a renderer should be smart enough to know where the US Canada boundary is and to render routes tagged with network: CA as a California route when in the US, and as a Canada route when in Canada. I don't know the details of how the renderers work though. Zeke ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Route Tagging With Relations
On Wed, Dec 24, 2008 at 1:44 PM, Zeke Farwell ezeki...@gmail.com wrote: Yeah we're getting a little ahead of ourselves with the shields. The first step is tagging the highways in a standard scheme which would give a renderer sufficient data to draw shields. Then someone has to actually build a renderer that draws the shields. Thats a whole other can of worms. I don't think that the Slippy Map on openstreetmap.org will ever draw custom shields beyond blue interstate shields, white US highway shields, and white ovals for state routes. I think it would be great to have a map with custom shields for every state. What we need for that to happen is someone to set up a US based Open Street Map renderer. In addition to custom shields, the highway colors could be drawn in more US centric way: varying shades of red, orange, and yellow with green reserved for toll roads. I think this would really help people in the US get involved with OSM because the map would look more familiar to them. The main slippy map is never going to do this though, because it is international. 2) I don't like the is_in approach - the US:CA approach seems to offer all the appropriate information in the same place. However, if there was a way to explicitly state that this is a state route, that would help in the situation mentioned above. The UC:CA approach does offer all the appropriate information in the same place. I don't think that is necessarily desirable though. For example, Vermont Route 30 is never called US Vermont Route 30. The network is just Vermont, not United States: Vermont. This is even more true for county roads. If Windham county in Vermont had it's own numbered routes one would not call a route United States, Vermont, Windham County Route 10. In short, I like the is_in approach because keeps the network name simple. I'd rather not have to bother with the is_in tag at all. For someone mapping there is no confusion as to whether a highway is Canadian Route 10 or California Route 10 (unless they are really bad at geography), but I suppose this could get confusing for the renderers. Ideally, I would say a renderer should be smart enough to know where the US Canada boundary is and to render routes tagged with network: CA as a California route when in the US, and as a Canada route when in Canada. I don't know the details of how the renderers work though. Zeke I've never liked the is_in tag. It seems like a poorly-thought-out kludge, because the contents are not strictly defined, so it's useless for automated parsing. Instead of having the state name in the network tag, why not have network=us_county, state=CA, county=Marin, operator=Marin County, CA or something like that. The operator tag seems appropriate here, but I'm not sure about the contents. Alternate values for network could be us_interstate, us_highway or us_state. The interstate modifier (alternate, business, etc.) could go into a interstate_modifier tag. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Fwd: US Route Tagging With Relations
Sorry meant to send to all... -- Forwarded message -- From: lordsu...@gmail.com Date: Wed, 24 Dec 2008 16:56:48 -0600 Subject: Re: [Talk-us] US Route Tagging With Relations To: Zeke Farwell ezeki...@gmail.com Personally I think it's best to let the renderer be as stupid as possible - some applications might be embedded, for example. Making the networks location or context-dependent is a recipe for disaster IMHO. The beauty of the proposed scheme is that it's easy for the renderer to pick a generic symbol that is appropriate. I - interstate shield US - us shield MX - Mexico shield XX:anything - state/province generic (circle/oval) XX:yy:anything - local generic (rectangle) For route guidance like text-to-speech or written directions the last part (split on colon for anything with a colon) can always be used and will at least make some sense. I agree it would be nice to have a North American rendering style but that's not a data issue. And there's a lot of variety even there; compare MapArt to Michelin to Rand McNally to AAA/Universal to DeLorme to USGS. On 12/24/08, Zeke Farwell ezeki...@gmail.com wrote: Yeah we're getting a little ahead of ourselves with the shields. The first step is tagging the highways in a standard scheme which would give a renderer sufficient data to draw shields. Then someone has to actually build a renderer that draws the shields. Thats a whole other can of worms. I don't think that the Slippy Map on openstreetmap.org will ever draw custom shields beyond blue interstate shields, white US highway shields, and white ovals for state routes. I think it would be great to have a map with custom shields for every state. What we need for that to happen is someone to set up a US based Open Street Map renderer. In addition to custom shields, the highway colors could be drawn in more US centric way: varying shades of red, orange, and yellow with green reserved for toll roads. I think this would really help people in the US get involved with OSM because the map would look more familiar to them. The main slippy map is never going to do this though, because it is international. 2) I don't like the is_in approach - the US:CA approach seems to offer all the appropriate information in the same place. However, if there was a way to explicitly state that this is a state route, that would help in the situation mentioned above. The UC:CA approach does offer all the appropriate information in the same place. I don't think that is necessarily desirable though. For example, Vermont Route 30 is never called US Vermont Route 30. The network is just Vermont, not United States: Vermont. This is even more true for county roads. If Windham county in Vermont had it's own numbered routes one would not call a route United States, Vermont, Windham County Route 10. In short, I like the is_in approach because keeps the network name simple. I'd rather not have to bother with the is_in tag at all. For someone mapping there is no confusion as to whether a highway is Canadian Route 10 or California Route 10 (unless they are really bad at geography), but I suppose this could get confusing for the renderers. Ideally, I would say a renderer should be smart enough to know where the US Canada boundary is and to render routes tagged with network: CA as a California route when in the US, and as a Canada route when in Canada. I don't know the details of how the renderers work though. Zeke -- Christopher N. Lawrence, Ph.D. c.n.lawre...@gmail.com Assistant Professor of Political Science Texas AM International University 313 LBVSC, 5201 University Blvd Laredo, Texas 78041-1920 Website: http://www.cnlawrence.com/ -- Christopher N. Lawrence, Ph.D. c.n.lawre...@gmail.com Assistant Professor of Political Science Texas AM International University 313 LBVSC, 5201 University Blvd Laredo, Texas 78041-1920 Website: http://www.cnlawrence.com/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
