Re: [Talk-transit] Connect two lines (ciprian niculescu)
Ciprian, I don't believe any relations are required for OpenTripPlanner to recognize a footway that would join two transit stops in the current version of OTP, routing is based primarily on the topology of OSM footways and GTFS data (stop locations and routes/trips). I would suggest posting additional details for your question on the OpenTripPlanner Developers Group (http://groups.google.com/group/opentripplanner-dev), since more detailed routing/transfer questions will likely get more responses there from some of the folks involved in actively improving the OTP multimodal routing engine. I believe there was recent added support for a GTFS extension pathways.txt file (http://groups.google.com/group/gtfs-changes/browse_thread/thread/241013e6216a0256) in OpenTripPlanner, which would give you more control over mapping the transit station within the GTFS file itself (instead of relying on topology of OSM ways for this). OTP Developers Group should be able to give you a more definite answer. Sean Sean J. Barbeau, M.S. Comp.Sci. Research Associate Center for Urban Transportation Research University of South Florida 4202 E. Fowler Avenue, CUT100 Tampa, FL 33620-5375 813.974.7208 2D barcode 813.974.5168 (fax) barb...@cutr.usf.edu -Original Message- From: talk-transit-requ...@openstreetmap.org [mailto:talk-transit-requ...@openstreetmap.org] Sent: Sunday, September 11, 2011 7:01 AM To: talk-transit@openstreetmap.org Subject: Talk-transit Digest, Vol 32, Issue 4 Send Talk-transit mailing list submissions to talk-transit@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-transit or, via email, send a message with subject or body 'help' to talk-transit-requ...@openstreetmap.org You can reach the person managing the list at talk-transit-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-transit digest... Today's Topics: 1. Connect two lines (ciprian niculescu) -- Message: 1 Date: Sun, 11 Sep 2011 00:40:29 +0200 From: ciprian niculescu cnicu...@gmail.com To: talk-transit@openstreetmap.org Subject: [Talk-transit] Connect two lines Message-ID: CAEMue=pcjjonj+w7rcoq1iaxz3qjaax5k2hkgkse_60h-wi...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hi, i want to develop the metro lines in my town, and install OpenTripPlanner to do the routing. In the early tests the algorithm don't recognise the footway/tunnel between the lines on a metro station. Must i create the relation between the Node-station and the Way-footway? If yes, how to do it? The way in question is http://www.openstreetmap.org/browse/node/125382255 Thanks Ciprian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20110911/a9f3a0e9/attachment-0001.html -- ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit End of Talk-transit Digest, Vol 32, Issue 4 *** ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [talk-ph] OSM-PH @ Software Freedom Day 2011
OK, I'm in to assist. On Sun, Sep 11, 2011 at 12:34 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi guys, Software Freedom Day 2011 will already be held this coming Saturday, September 17 at the University of Santo Tomas. OpenStreetMap Philippines will be conducting a workshop on OSM at 1 of the 5 breakout sessions in the afternoon from 1 to 4 pm at the AMV Hall http://osm.org/go/4zhQl5P24--?m. We are sharing the timeslot with Ushahidi who will talk about crowdsourcing humanitarian crisis information. For the workshop, we plan to introduce OSM to the attendees (most of them are college students), have a mini-mapping party in and around UST (there are lots of unmapped POIs), and show them how to edit and contribute data to OSM. As of September 3, there are already 1,600 registered participants to SFD as a whole. So I'm expecting that there would be around 200-300 people (!!!) attending the OSM workshop. Feel free to join the fun! We could definitely use a lot of hands. :-) Eugene On Thu, Aug 25, 2011 at 8:22 PM, maning sambale emmanuel.samb...@gmail.com wrote: Dear everyone, We have a slot/session in the upcoming Software Freedom Day 2011 in UST Sept. 17, 2011. We urged Pinoy OSMers to join and help us run the session. Details and confirmation of attendance here: https://www.facebook.com/event.php?eid=210784685637970 -- cheers, maning -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] Unmapped Place For Belgium in Septembre
Can you manually edit that list? I ask it because Lo-Reninge is marked as unmapped, but this is just a node in the middle of Lo and Reninge which are both mapped. Lo-Reninge doesn't have a real center. If there is a better way of placing that node, please do so. Greets, Sander 2011/9/11 eMerzh merz...@gmail.com Hi everyone, as every month or so, i update my stats about unmapped places (See previous message in this list) So as reminder the url or the map is : http://bmaron.net/osm_stats/unmapped/ The textual version is http://bmaron.net/osm_stats/unmapped/result.html You can check the diff between the previous month with the last computing at http://bmaron.net/osm_stats/unmapped/archive/2011.08.05/result.2011.08.05.html So in brief : + 9 Places + 370.000 Nodes - 3 Unmapped city (34-31) -18 sparsely mapped city (244-226) And since 04 July + 25 Places + 743 000 Nodes - 13 unmapped City (44-31) - 36 sparsely mapped (262-226) Reminder 2 : it's only a count of nodes in a defined distance (CF : definition in the result.html file) not about quality or number of tags or whatever From the count of the 2 last month, we still need 5 Month to finish the unmapped places!!! and 13 Month to finish the sparsely mapped... (i've previoulsy targeted it for July 2011 and October 2011...) Please don't give up! Thanks to all of you -- eMerzh ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-legal-talk] How to modify data provider license (WMATA)
I've been asked by the GIS manager at WMATA (the transit authority for the Metro DC, USA) how we would like their license changed so their data can be used in OSM. I suggested they adopt something like the ODbL or CC0, but they said that's highly unlikely and far better to modify the existing license. Here is the current version: http://www.wmata.com/rider_tools/license_agreement.cfm AFAICT, the only problem is with paragraph 4: LICENSEE must state in legible bold print on the same page where WMATA Transit Information appears and in close proximity thereto, “WMATA Transit information provided on this site is subject to change without notice. For the most current information, please click here.” Perhaps the fewest changes that would make it work would be the following: LICENSEE should state in legible bold print on the same page where WMATA Transit Information appears and in close proximity thereto, “WMATA Transit information provided on this site is subject to change without notice. For the most current information, please click here.”, whenever technically feasible. Or perhaps we could even just change one word, must-should, as I believe should is understood to mean recommended, though of course IANAL. Any other suggestions I should pass on to him? Thanks, -Josh ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Quick History Service is down (wtfe.gryph.de)
Hi, On 09/11/11 02:44, Frederik Ramm wrote: my quick history server at wtfe.gryph.de is offline due to a hardware issue at the hosting provider. This affects the license change layers/plugins in JOSM and Potlatch. The provider has emailed to say they're working on it but I'll have to wait and see. It is unclear if the database will have to be rebuilt after the system is back up (which would mean about a week of additional downtime). It seems the machine is up and running again and has current data. I have had isolated reports about malfunctions in the past (the when I tried again it worked kind). But with the service getting more widely used I am interested in bug reports of any kind to make sure it holds up to expectations. Also if other people would like to run the software on a machine of their own - requires a Linux box with ~ 100 GB disk space, a MySQL database and Osmosis - I'll gladly help them set things up. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] user rankings
On 10 Sep 2011, at 18:18, Tobias Knerr wrote: Are there building blocks available to create custom statistics? None that I know of. I have created a choropleth map that shows the completion percentage of Communes in Luxembourg based on official street lists, and the missing street density on a colour gradient: http://stereo.lu/MissingDensity.png It's very useful to find low hanging fruits that Luxembourg mappers can map together If there's any interest, I will try to simplify the procedure and write a blog post. Guillaume ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] user rankings
On Mon, Sep 12, 2011 at 6:05 AM, Guillaume Rischard openstreet...@stereo.lu wrote: On 10 Sep 2011, at 18:18, Tobias Knerr wrote: Are there building blocks available to create custom statistics? None that I know of. I have created a choropleth map that shows the completion percentage of Communes in Luxembourg based on official street lists, and the missing street density on a colour gradient: http://stereo.lu/MissingDensity.png It's very useful to find low hanging fruits that Luxembourg mappers can map together If there's any interest, I will try to simplify the procedure and write a blog post. Please? Sounds very interesting. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] user rankings
Hi all, I've being doing the same in my country, and the detailed steps are described in the wiki, as I always do. For example, for the road network, the process is described in: http://wiki.openstreetmap.org/wiki/C%C3%A1lculo_da_Cobertura_da_Rede_Vi%C3%A1ria The final output, as a choropleth map is something like: http://dl.dropbox.com/u/5489125/s.valentim.osm.jpg (sorry for the pink, but that one was created in the S. Valentim's day, to show how much love some municipalities need from OSM mappers). I've also did the same for pharmacies and for more other features: http://wiki.openstreetmap.org/wiki/C%C3%A1lculo_da_Cobertura_de_Farm%C3%A1cias I do some of these before each mapping party, to show to users. It is not possible to do this for every country and keep it updated in a easy way. This kind of analysis depends of the administrative limits. There is no geographical entity in OSM that represents administrative units. There are nodes, ways and relations that can be tagged as administrative boundaries, but there are no semantics constrains that make them usable administrative boundaries, topologically well formed. I really don't know if such kind of data, administrative limits - data that cannot be captured by OSM mappers - should be considered at the same level as the other physical data, that can be captured by mappers. Since less skilled users were always changing the administrative limits in my country (many of them were part of relations, with nodes shared with rivers, roads, etc) we decided in the list with no votes against to remove them from OSM. There were more problems with administrative boundaries on OSM, then without them. We suggest our users to use the official administrative limits (they available as WMS and WFS) as another layer in web mapping applications, for example. It would be nice if we we could create planet files for specific administrative levels, if administrative boundaries could be used in the API instead of non-sense rectangular bounding boxes, etc. But I'll not fight for that and I understand other mappers have different opinions. It's easier to replicate the planet and to the processing locally. It will take a few hours, although (to create the statistics and whenever we need to update them). We can create one more service outside openstreetmap to do these statistics as a service for the community. GeoFabrick is already creating nice planet files based on country boundaries, as a service outside openstreetmap.org. I'm available to help. Regards from Denver, Jorge On 12-09-2011 16:25, Richard Weait wrote: On Mon, Sep 12, 2011 at 6:05 AM, Guillaume Rischard openstreet...@stereo.lu wrote: On 10 Sep 2011, at 18:18, Tobias Knerr wrote: Are there building blocks available to create custom statistics? None that I know of. I have created a choropleth map that shows the completion percentage of Communes in Luxembourg based on official street lists, and the missing street density on a colour gradient: http://stereo.lu/MissingDensity.png It's very useful to find low hanging fruits that Luxembourg mappers can map together If there's any interest, I will try to simplify the procedure and write a blog post. Please? Sounds very interesting. ___ 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: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Am 11.09.2011 23:31, schrieb ant: Moin, Am 09/11/2011 06:25 PM, schrieb Peter Wendorff: Das stimmt, aber ob dieses Tool benutzungsfreundlich für nicht-techniker bleiben kann, die sich auch nicht mit dem tagging-schema in allen Varianten auseinandersetzen wollen oder können, bezweifle ich. Osmosis wird durch osmembrane schon ziemlich benutzerfreundlich, finde ich. Trotzdem muss der Nutzer immer noch ein natürlich sprachlich formuliertes Problem irgendwie in die Filter umsetzen. wenn ich in Potlatch ein Restaurant eintragen will, klicke ich auf das Symbol mit Messer und Gabel und fertig. Das kommt der sprachlich formulierten Aufgabe schon sehr nahe. Wer dennoch spezielle Tags eintragen möchte, klickt auf Advanced und tippt Schlüssel und Wert ein. Dieses Konzept lässt sich auf beliebige Anwendungen übertragen. Für die Eingabe von Daten stimme ich dir da voll zu - und das funktioniert ja auch weitgehend recht gut. Bei einer guten Export-GUI müsste ein Datennutzer nicht unbedingt wissen, welche Tools im Hintergrund die Arbeit machen, welche Entity Streams wie gefiltert werden usw. Das Problem dabei ist aber, dass der Ersteller der Tools die Vorgabe gibt, welche Tags betrachtet werden und welche nicht. Da ist dann schnell die Ausgabe für die Tonne, weil gerade im von mir betrachteten Gebiet eine sonst seltener vorkommende Variante für das Taggen von Feature X benutzt wird, die im Export-Tool nicht vorkommt. Diese Fehler wird man aber nichtmal merken, weil man nichtmal mehr darüber stolpern kann, wenn man nur noch die GUI benutzt. Die Pflege entsprechenden Mappings wird also richtig schwer, wenn das Tool nicht an Wert verlieren soll. Im Übrigen geht es mir nicht primär um die Tags - ich gehe davon aus, dass ein potenzieller Nutzer der Daten weiß, an welchen Tags er interessiert ist. Anders sieht es jedoch bei der Kenntnis der Kommandozeilentools - die nötig ist, um OSM-Daten nutzbar zu machen - aus. Die Kommandozeilentools braucht man dank OSMembrane nichtmal. Die Filterung zu formulieren selbst ist aber häufig schon zu schwierig (Welche Tags muss ich in welcher Reihenfolge rausfiltern, um mein Ziel zu erreichen)? Wie man das aber noch mehr vereinfachen kann, da hab ich echt noch keine Idee. Klar, man könnte eine Datenbank von pipelines anbieten, die häufige Aufgaben einfach abrufbar macht ((warum) gibt's das eigentlich noch nicht?). Aber es wird immer wieder Anfragen geben, die in dem Katalog nicht da sind, oder Facetten, die eben anders interpretiert werden könnten. Gehören Verkehrsflächen jetzt zu den Wohngebieten dazu oder nicht? Gehören Treppen zu den Wegen oder nicht? Wenn man sich mit den Tags selbst auseinandersetzen will/kann, dann gibt es die entsprechenden Tools. Wenn nur eine Frage in natürlicher Sprache vorliegt, wird kein Tool im Allgemeinen die Antwort liefern können. Um beim Potlatch-Bild zu bleiben: Simple hieße bei unserem Tool nunmehr Tag-Kombinationen eingeben, Bbox ziehen und Enter drücken; BBox ziehen einverstanden, Tag-Kombinationen eingeben: Da weiß ich schon nicht mehr, wie das so geht, dass es so richtig einfach wird. advanced hieße, bei Bedarf die Prozess-Pipeline an den gewünschten Stellen manipulieren zu können. Richtig. Alles in Allem schreit das für mich nach 'ner Aufgabe für osmembrane: Die Karte zur bbox-Auswahl sollte nicht so kompliziert sein, ein Polygon zu zeichnen auch nicht, bleibt die Vereinfachung der Tag-Auswahl. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Hallo, On 09/11/11 23:31, ant wrote: Bei einer guten Export-GUI müsste ein Datennutzer nicht unbedingt wissen, welche Tools im Hintergrund die Arbeit machen, welche Entity Streams wie gefiltert werden usw. Bleibt abzuwarten, wie sich das entwickelt. Ohne Kenntnis des Hintergrunds bleiben einem viele Probleme halt verborgen. Zum Beispiel werden Leute mit der gleichen Selbstverstaendlichkeit, mit der hier nach Landuse-Flaechen gefragt wurde, nach Buslinien fragen und erwarten, dass sie das in der Export-GUI einfach irgendwo anklicken koennen. Dann werden sie nach Bushaltestellen fragen, und dann kommt hier das Posting: Jetzt hab ich das in eine Karte eingezeichnet, und die Haltestellen liegen alle neben der Linie. Das kann es doch nicht sein... Oder jemand will einfach nur die Fluesse als Shapefile, und wenn man ihm dann die waterway=river-Linien exportiert, kommt: Der Rhein sieht hier aber ganz anders aus als bei OSM ;) Ich glaube, es ist sehr leicht fuer einen Export-Tool-Schreiber, den Bedarf falsch einzuschaetzen, oder anders: Fuer jedes Export-Tool X gibt es einen Nutzer Y, dessen scheinbar triviale Anforderung damit nicht erfuellt wird ;) Was natuerlich nicht heisst, dass man es nicht versuchen soll. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Moin, Christian Müller schrieb: Am 11.09.2011 12:14, schrieb Martin Koppenhoefer: Das kann ich nicht tun, weil auch die Zwischenräume zur settlement-Fläche gehören, z.B. Verkehrsflächen. Nochmal, Du kannst deine eigene Definition von Siedlungsfläche gerne ausdenken und dann verwenden. Für OSM sollten aber bereits gebräuchliche verwendet werden - siehe Flächenverbrauch in der Wikipedia. Wenn Du die Verkehrsfläche dazu nimmst, sprichst Du von Siedlungs- und Verkehrsfläche (kurz SuV) Du kannst gerne SuV als settlement im engl. verstehen, musst dann aber settlement area beim Übersetzen ins dt. als SuV übersetzen und nicht rein als Siedlungsfläche - weil die gebräuchliche Definition im dt. hmm, ihr hängt Euch Beide in der Diskussion ziemlich an den Begriffen administrative Grenze und Fläche als Definitionen auf - was durch Sinn macht, um generell eindeutige tags zu bekommen. Vielleicht sollte man aber für das - nicht nur von Martin - gewünschte place-Polygon (einer Siedlung) vorerst einfach mal den Begriff Umriß einer Siedlung einwerfen. Es erweitert den unscharfen node um eine ungefähre Ausdehnung - bleibt aber trotzdem so unscharf, keine absolute Lage oder gar Definition vorgeben zu wollen. Auch deshalb sollte es m . M. n. nicht in landuse oder boundary eingeordnet werden - dort mögen weitere tags in der Gesamtheit dann evtl. diese Informationen ebenfalls liefern können - irgendwann. Ich sehe es vorerst als ein Hilfselement, z. B. zum Rendern in gewissen Maßstabsbereichen, wo die genauen Einzelflächen (sofern denn überhaupt vorhanden) schon nicht mehr aufgelöst werden können bzw. es nicht mehr sinnvoll ist (*), andererseits aber mehr Informationen als ein node gewünscht werden bzw. sinnvoll sind. Wären alle dafür notwendigen Flächennutzungen bereits definiert, eingetragen und auch noch an den passenden Stellen parzelliert, wäre es möglich, diese Informationen daraus abzuleiten - so existiert aber in meinen Augen derzeit durchaus ein Bedarf für solch eine Zwischen- bzw. Näherungslösung. Andere mögen andere Gründe haben oder Anwendungen finden. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Reitweg - aber nur für Kutsche
hi ! habe gestern auf dem Darß eine Wegebeschilderung mit V/238 (http://wiki.openstreetmap.org/wiki/File:120px-Zeichen_238.svg.png) gesehen und darunter stand das dieser für Kutschen frei sei - Reiten aber verboten. Wie würdet Ihr das taggen ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 11. September 2011 22:32 schrieb Christian Müller cmu...@gmx.de: Das ist ein bisschen so, wie Gemüse- und Backwaren strikt zu trennen, aber nur wenn das Gemüse eine Mindestgröße erreicht hat. +1, schönes Bild. Das ist genau die Situation, die wir zum Teil haben, und die das Mappen unnötig kompliziert macht. Wieso nicht? Du schreibst ins Wiki etwa landuse=* erfasst keine administrativ-rechtliche Grenzen. -1, ich würde nicht reinschreiben, was _nicht_ erfasst wird, sondern das, was erfasst wird. Admin-rechtliche Gebiets- und Flächengrenzen sind in X besser aufgehoben. +1, das steht da auch schon klar drin: sie werden mit boundary=administrative und admin_level getaggt. Gebietsnamen werden üblicherweise über place nodes getaggt. -1. Sie können als place Node oder area getaggt werden. Ein _Gebiet_ nur als Node zu taggen beinhaltet immanent einen gewissen Grad von Unvollständigkeit. Die Tatsache, dass mehr und mehr places neben dem Node auch als area getaggt werden spricht dafür, dass man irgendwann an einen Punkt kommen wird, wo der Satz heissen wird: Gebietsnamen werden üblicherweise mittels eines place polygons und zugeordnetem Node getaggt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 11. September 2011 23:15 schrieb Christian Müller cmu...@gmx.de: Am 11.09.2011 12:14, schrieb Martin Koppenhoefer: Am 10. September 2011 19:57 schrieb Christian Müllercmu...@gmx.de: Am 10.09.2011 14:46, schrieb Martin Koppenhoefer: Nochmal, Du kannst deine eigene Definition von Siedlungsfläche gerne ausdenken und dann verwenden. Für OSM sollten aber bereits gebräuchliche verwendet werden - siehe Flächenverbrauch in der Wikipedia. -1, diese schmale Flächenverbrauchsseite in der Wikipedia, ohne vernünftige Quellenangaben, ist für mich nicht die Bibel. Je nachdem, unter welchem Gesichtspunkt man vorgeht, gibt es auch andere Definitionen. Wenn Du die Verkehrsfläche dazu nimmst, sprichst Du von Siedlungs- und Verkehrsfläche (kurz SuV) Du kannst gerne SuV als settlement im engl. verstehen, musst dann aber settlement area beim Übersetzen ins dt. als SuV übersetzen und nicht rein als Siedlungsfläche - weil die gebräuchliche Definition im dt. Verkehrsfläche in der Siedlungsfläche _nicht_ einschließt. sagt die Wikipedia-Seite zum Flächenverbrauch und auch das BauGB deutet hinsichtlich Flächennutzung (welche Teile sind gesondert darzustellen) darauf hin --- Wenn Du Dir andere Paragraphen im BauGB ansiehst, dann gibt es aber auch andere Kriterien dort (im Zusammenhang bebaute Ortsteile). Je nach Sinn und Zweck bzw. Kontext sind die Kriterien teilweise unterschiedlich. Wir erfassen bisher keine Verkehrsflächen explizit, daher sollte unsere Siedlungsgrenze auch nicht darauf aufbauen. Place ist unser Tag für Orte. Die können gesetzlich normativ definiert sein, müssen das aber nicht. Es reicht, dass es sie gibt. Und seit wann kann ich eine Relation nicht erstellen, nur weil es Zwischenräume gibt? Innerhalb eine Gemeindegrenze, kann es durchaus mehrere unabhängige Flächen geben, in denen sich SuV findet. von Gemeindegrenzen spreche ich sowieso nie, wenn es um Siedlungen geht. Die gehören zu den Verwaltungsgrenzen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Christian, da Du gerne die Wikipedia zitierst hier 2 Links, die Dich interessieren dürften: http://de.wikipedia.org/wiki/Stadtviertel Ein Stadtviertel ist ein überschaubares, häufig nur aus einigen Straßenzügen bestehendes, soziales Bezugssystem, das sich sowohl räumlich/geografisch als auch von der sozialen oder ethnischen Struktur seiner Bewohner her von anderen Stadtvierteln abgrenzt. Eine offizielle Grenzziehung existiert dabei meist nicht. Das Gebiet wird durch seine Bewohner definiert und ist unabhängig vom Gebiet eines Stadtteils oder Stadtbezirks. analog würde ich auch Wohngebiete auf dem Land sehen. Zweiter Link: http://de.wikipedia.org/wiki/Ortsteil Ortsteil, je nach Art der Gebietskörperschaft (Verwaltungseinheit) auch Stadtteil, Gemeindeteil, Ortschaftsbestandteil oder Fraktion, ist in Siedlungsgeografie, Demographie und Raumplanung ein unspezifischer Sammelbegriff für abgegrenzte und mit eigenem Namen versehene Teile einer Siedlung (einem Ort, einer Ortschaft im allgemeinem Sinne). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Hallo alle miteinander, zu allererst finde ich es schön, dass hier offensichtlich die Bereitschaft zur offenen Diskussion vorhanden ist. ;) [...] dann ist das halt ein Problem, aber kein Grund, sich darüber zu beschweren (kein Vorwurf, die Beschwerde war zumindest nicht deutlich, aber man könnte sie in deine Mail reininterpretieren). Es sollte auch keine Beschwerde im ursprünglichen Sinne sein, sondern vielmehr eine Art, zu zeigen, wieviel Frust sich in einem anstauen kann, wenn es nicht gelingt, trotz Wille und Zeit Ergebnisse produzieren und am Ende jegliche Mühe als gescheitert ansehen muss. Dabei bin ich ein sehr genügsamer Mensch. :) Nun sehe ich aber vollkommen ein, wenn Peter einwirft, dass die Vereinbarkeit von OSM-Rohdaten und den spezifischen Nutzungswünschen nicht ohne weiteres zusammenzubringen ist. Da ich selbst ab und an kartiere, habe ich das unendliche Diskussionspotenzial um die Auslegung von Tags auch schon miterlebt. Daher wird es so oder so keine Perfektion geben - so wie eben das ganze OSM-Gebilde niemals perfekt sein kann und wird. Was man aber tun kann, ist einen größtmöglichen Spielraum zu schaffen, der - ständig weiterentwickelt - einen immer größer werdenden Nutzerpool (mit entsprechenden Bedürfnissen) erreicht. Aber zurück zur konkreten Ebene: Ich finde den Ansatz von ant sehr richtig, der da sagt: Mir schwebt in etwa Folgendes vor: Ein Web-Interface oder Programm mit GUI, in dem ich ein Rechteck oder Polygon über eine Karte ziehe und sage, welche Daten (Tags) ich möchte. Das Programm holt für mich die Daten und filtert sie, wandelt sie ggf. um, und dann kann ich damit tun, was ich möchte (z.B. in QGIS laden oder in eine DB importieren). Nichts anderes haben doch auch schon informationfreeway.org (wenn es denn mal gänge) und das Stuttgarter Pendant versucht und in Teilen erreicht. Sowohl beim einen als auch beim anderen definiere ich eine BBox und die Information, die ich haben will (mit der Voraussetzung, dass man sich mit den Tags etwas auskennt). Danach lasse ich mir das als gpx-, kml-, shp oder sonstige Datei ausgeben (je nachdem, wie die technische Umsetzbarkeit ist). Somit sind meiner Ansicht nach die Techniken doch schon vorhanden. Was lediglich fehlt, ist einfache Handhabung. Und hier kranken die meisten Ansätze meiner Meinung nach. Dabei geht es, wie ant auch schon angerissen hat, auch einfacher: wenn ich in Potlatch ein Restaurant eintragen will, klicke ich auf das Symbol mit Messer und Gabel und fertig. Das kommt der sprachlich formulierten Aufgabe schon sehr nahe. Wer dennoch spezielle Tags eintragen möchte, klickt auf Advanced und tippt Schlüssel und Wert ein. Dieses Konzept lässt sich auf beliebige Anwendungen übertragen. Übersetzt in die Export-Perspektive bedeutet dies, man müsste ein kleines und erweiterbares Sammelsurium an Vorlagen (oder besser: Tag-Pakete) bereitstellen. Diese könnten dann z.B. lauten: Ich möchte alle Gewässer! - darin enthalten sind dann sowohl Flüsse, Bäche, Seen, Polter, etc. Ich möchte alle Flüsse! - und er bekommt nur die Flüsse, nicht aber die Bäche und Seen, etc. Letztlich ist also doch nur eine Kombinatorik von Tag-Elementen erforderlich (außer vllt. bei Relations, oder?). Und alles, was die Vorlagen nicht erfassen (oder falsch erfassen), kann man mit einem Advanced-Button direkt selektieren oder eben de-selektieren. Also? Peter dazu: Alles in Allem schreit das für mich nach 'ner Aufgabe für osmembrane: Die Karte zur bbox-Auswahl sollte nicht so kompliziert sein, ein Polygon zu zeichnen auch nicht, bleibt die Vereinfachung der Tag-Auswahl. Dito. OSMembrane macht bereits vieles richtig, scheitert aber aus meiner Nicht-Informatiker-Sicht (noch) völlig an der Usability. Der Mehrwert dieser Applikation ist somit gegenüber der manuellen Texteingabe eher gering. Aber das Potenzial ist riesig, da die Basis ja schon steht. Soweit mein Senf. ;) Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Am 12. September 2011 13:44 schrieb rhinh...@googlemail.com: Ich möchte alle Flüsse! - und er bekommt nur die Flüsse, nicht aber die Bäche und Seen, etc. Letztlich ist also doch nur eine Kombinatorik von Tag-Elementen erforderlich (außer vllt. bei Relations, oder?). in OSM ist das theoretisch einfach: alles mit waterway=river. Wenn Du aber genau hinsiehst, dann wird es komplizierter. Wann ist ein Fluss denn ein Fluss? Das ist überhaupt nicht allgemein definiert (z.B. über die Wassermenge), sondern z.T. auch historisch bedingt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] falsche nodes in europe-cut? / osmosis und 15GB zuviel?
Hallo! Ich versuche weiterhin meinen Balkan Auszug auf mein Garmin Gerät zu bekommen. Dazu habe ich: 1. das Europe.tar.gz File von Geofabrik geholt (9 GB) 2. dieses mit Osmosis dann zurecht geschnitten: ./Osmosis/osmosis-0.39/bin/osmosis -v --rx europe.osm.bz2 --bounding-box top=48.000 left=13.000 bottom=43.000 right=18.000 completeRelations=yes --wx ausschnitt.osm Und diese Datei dann gesplittet: java -Xmx8192m -ea -jar ../splitter/splitter-r179/splitter.jar --max-nodes=60 --overlap=4000 --max-areas=255 --cache=cache --description=germany --mapid=1234 --max-nodes=60 --no-trim --overlap=4000 --status-freq=600 --output=xml ausschnitt.osm Und mit mkgmap nach openmbtmap zu ner Karte verbasteln: java -ea -Xmx8192m -jar /opt/OSM/mkmap/mkgmap-r2023/mkgmap.jar --style-file=openmtbmap_style --max-jobs --generate-sea=polygons,extend-sea-sectors,close-gaps=6000 --reduce-point-density=5.4 --x-reduce-point-density-polygon=5.4 --index --transparent --adjust-turn-headings --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs=4 --description=openmbtmap_de --location-autofill=1 --route --country-abbr=de --country-name=germany --mapname=1234 --family-id=1234 --product-id=1 --series-name=openmbtmap_de_%date% --family-name=mbtmap_de_%date% -tdbfile --overview-mapname=mapset --area-name=Germany_%date%_openmbtmap.org -c template.args Dabei bekomme ich jedoch folgende Fehler/Warnungen: SEVERE (Polyline): 1234.osm.gz: Problem writing line (class uk.me.parabola.imgfmt.app.trergn.Polyline) of type 0x10606 containing 18 points and starting at http://www.openstreetmap.org/?mlat=43.50333mlon=16.44125zoom=17 SEVERE (Polyline): 1234.osm.gz: Subdivision shift is 0 and its centre is at http://www.openstreetmap.org/?mlat=43.39095mlon=15.38371zoom=17 SEVERE (Polyline): 1234.osm.gz: deltaLong = 49285 SEVERE (MapSplitter): 12340012.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=45.09006mlon=14.62583zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): 12340012.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=45.09006mlon=14.62583zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): 12340040.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=47.10392mlon=17.13927zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): 12340040.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=47.10392mlon=17.13927zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): 12340040.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=47.10392mlon=17.13927zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): 12340031.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=54.45301mlon=13.44016zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): 12340031.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=54.45301mlon=13.44016zoom=17 (reduce the density of points, length of lines, etc.) Warning: using default sort Nicht weiter tragisch, ABER was macht der 54.45301/13.44016 in meinen Daten, ich hab da doch gar nicht geschnitten? (ist Rügen, was nun gar ned zum Balkan gehört). Ist das vielleicht eine Boundary, die wegen Relationen zum Satz dazu gehört? Und ich hab ja dazu die SRTM Daten geholt für meinen Ausschnitt und ins 0.6 API gewandelt mit Osmosis: osmosis-0.35/bin/osmosis --read-xml-0.5 srtm.osm enableDateParsing=no --migrate --wx srtm6.osm Da kam eine 15GB Datei bei heraus, mein europe-Extrakt war rund 3.5 GB. Die wollte ich mit Osmosis joinen: /opt/OSM/Osmosis/osmosis-0.39/bin/osmosis --rx ausschnitt.osm --sort --rx srtm6.osm --sort --m --wx final.osm Was aber ned ging, ständig irgendwelche Fehler, etwas googlen meinte: zu große Daten. Stimmt das denn? Sind 15GB wirklich zu viel? ;-) MfG, Lars Schimmer -- - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Ich möchte alle Flüsse! - und er bekommt nur die Flüsse, nicht aber die Bäche und Seen, etc. Letztlich ist also doch nur eine Kombinatorik von Tag-Elementen erforderlich (außer vllt. bei Relations, oder?). in OSM ist das theoretisch einfach: alles mit waterway=river. Wenn Du aber genau hinsiehst, dann wird es komplizierter. Wann ist ein Fluss denn ein Fluss? Das ist überhaupt nicht allgemein definiert (z.B. über die Wassermenge), sondern z.T. auch historisch bedingt. Sehe ich ein. In der Tat ist das eine knifflige Angelegenheit. [In der Hydrogeographie behilft man sich mit Ordnungskennzahlen, die sich aus der Größe des Gewässersystems (bzw. der Summe der Gewässermitglieder) ergibt. Dennoch fehlt natürlich eine klare Definition.] Daher bleibt es uns OSM-lern überlassen, eine Klassifizierungslösung zu finden. Getan haben wir das ja auch schon bei den highway=track und den grade-Werten. Natürlich ist das nicht optimal, aber gerade zwischen Flüssen und Bächen könnte man da aufgrund ihrer geringen Anzahl (geg. Bächen und Kanälen) schon was auf die Beine stellen. Davon mal abgesehen, sollte dennoch bei meinem Beispiel Ich möchte alle Flüsse! der Tag waterway=river (und ggf. noch ein anderer) eingetragen werden. Über die Ausgabe-Qualität eines Tags bestimmt nun mal immer das OSM-Material - das Dilemma werden wir fast überall bekommen. Nichtsdestotrotz sollte der Export erst einmal möglich sein. Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] falsche nodes in europe-cut? / osmosis und 15GB zuviel?
Am 12.09.2011 13:57, schrieb Lars Schimmer: 1. das Europe.tar.gz File von Geofabrik geholt (9 GB) 2. dieses mit Osmosis dann zurecht geschnitten: Nur am Rande: wenn du bei Schritt 1 die pbf-Datei herunterlädts, sparst du 2,5 GB Downloadvolumen. Osmosi kann auch pbf. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] falsche nodes in europe-cut? / osmosis und 15GB zuviel?
Am 12.09.2011 14:47, schrieb Rainer Kluge: Am 12.09.2011 13:57, schrieb Lars Schimmer: 1. das Europe.tar.gz File von Geofabrik geholt (9 GB) 2. dieses mit Osmosis dann zurecht geschnitten: Nur am Rande: wenn du bei Schritt 1 die pbf-Datei herunterlädts, sparst du 2,5 GB Downloadvolumen. Osmosi kann auch pbf. Um das noch zu ergänzen: splitter kann pbf auch lesen und schreiben und mkgmap liest auch pbf. Neben dem Downloadvolumen spart man sich das entpacken und auch die restliche Prozessdauer ist kürzer. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] falsche nodes in europe-cut? / osmosis und 15GB zuviel?
Lars Schimmer wrote: SEVERE (MapSplitter): 12340040.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=47.10392mlon=17.13927zoom=17 (reduce the density of points, length of lines, etc.) Nicht weiter tragisch Naja, wie mans nimmt. Die Meldung bedeutet, daß mkgamp dort auf ein großes Polygon gestoßen ist, das es nicht verarbeiten kann, und daß es ALLE Daten in der Gegend einfach weglassen wird. Wieso die Nordsee an den Balkan verlegt wird, kann ich Dir allerdings auch nicht sagen. Vielleicht ein Super-Multipolygon, das eine Landesgrenze bis dorthin durchzieht? bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/falsche-nodes-in-europe-cut-osmosis-und-15GB-zuviel-tp6783180p6783512.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Am 12. September 2011 14:36 schrieb rhinh...@googlemail.com: Sehe ich ein. In der Tat ist das eine knifflige Angelegenheit. [In der Hydrogeographie behilft man sich mit Ordnungskennzahlen, die sich aus der Größe des Gewässersystems (bzw. der Summe der Gewässermitglieder) ergibt. Dennoch fehlt natürlich eine klare Definition.] Daher bleibt es uns OSM-lern überlassen, eine Klassifizierungslösung zu finden. Getan haben wir das ja auch schon bei den highway=track und den grade-Werten. Natürlich ist das nicht optimal, aber gerade zwischen Flüssen und Bächen könnte man da aufgrund ihrer geringen Anzahl (geg. Bächen und Kanälen) schon was auf die Beine stellen. M.E. gibt es 2 Hauptarten von Fließgewässern in OSM: natürliche und künstliche. Bei den natürlichen haben wir 2 Arten: river und stream, wobei letztere prinzipiell kleiner sind als erstere, width als Breitenangabe ist auch nicht verkehrt, sofern man das kann. Im deutschen Sprachgebrauch gibt es hauptsächlich diese 2 Arten (Fluss und Bach, es gäbe noch Strom als Sonderfall von Fluss, aber nach unten ist das eigentlich alles), während das Italienische mehrere unterschiedliche natürliche, kleinere Wasserläufe kennt, daher gibt es hier öfters mal Nachfragen und Unzufriedenheit diesbezüglich ;-) Bei den künstlichen haben wir 3 Arten: canal, drain und ditch (blöderweise scheint die Trennung, wenn man das Wiki streng liest, zwischen drain und ditch auch eine funktionale zu sein, wobei andererseits, wenn man immer noch streng liest, sich da eigentlich eine Lücke ergeben würde für künstliche Wasserwege, die nicht in einem Graben laufen und solche, die nicht für industrielle Abwässer oder Regenwasser geschaffen sind, (sondern z.B. zur Trockenlegung dienen, was ja drain prinzipiell als Wort abdeckt). Diese blöde Angewohnheit, Beispiele direkt in die Definition zu schreiben, sorgt, solange man das exklusiv interpretiert, für unnötigen Ballast. Praktisch sieht das aber m.E. kaum jemand so eng, sonst würde man ja eine Vielzahl von Fließgewässern gar nicht taggen können. Meine eigene Interpretation ist, dass auch die künstlichen Fließgewässer sich von groß nach klein differenzieren, also wie genannt canal, drain, ditch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] landuse - gewerbliche Flächen
Hi Frederik, parallel zum Thema der Wohnflächenerfassung, könnte man die landuse Erfassung vereinfachen, indem man sich für das tagging teilweise nach ISIC richtet - das ist eine internationale Klassifikation für Gewerbetypen, die auch von der EU übernommen wurde. Zusätzlich macht auch die BauNVO auf Ebene der Bauflächen keinen Unterschied zwischen Industrie- und gewerblicher Fläche, beides ist dort als (G) gekennzeichnet.. Du hast bereits beobachtet, dass Mapper vor Ort teilweise nicht auseinanderhalten (können!), was commercial und was industrial ist. Evtl. sollte man industrial und commercial also zusammenlegen und stattdessen den Gewerbetyp, sofern ein Mapper ihn tatsächlich kennt, mit einem Zusatztag ausdifferenzieren: - da wo Industrie ist, ist oft auch auch nicht-industrielles Gewerbe - die nähere Unterteilung gewerblicher Fläche nach ISIC [1] könnte in OSM so umgesetzt werden landuse=industrial industrial=agriculture,hunting,forestry,fishing mining,quarrying manufacturing energy (oder electricity, gas, water) construction retail offices (oder finance, real_estate, public_sector ~reine Büroflächen) Evtl. gibt es statt industrial ein besseres Wort für gewerbl. Fläche. Das verringert Eintrittsbarrieren, indem die Anzahl der values in landuse schrumpft. Die Klassifikation von Flächen ist dadurch - einfach gestaltbar (Beschränkung auf gewerbl. Fläche, sprich _egal_ ob Büro, Geschäft, Produktion, etc.) - oder differenziert möglich (für Mapper die ins Detail gehen möchten) Wenn man das so macht, gibt's die ISIC-Klassifizierung für die Hauptgruppen A-G gratis dazu. Für die Hauptgruppen H-Q wird meines Wissen in OSM die zugehörige Fläche anders erfasst (z.B. H,M-N education, health - amenity). Das wäre ein Thema mit dem man auf tagging anklopfen kann, weil die ISIC international ist. Ich frage aber dennoch hier nach einer qualifizierten Meinung. Gruß, Christian [1] http://de.wikipedia.org/wiki/International_Standard_Industrial_Classification ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 09:26, schrieb Georg Feddern: Wären alle dafür notwendigen Flächennutzungen bereits definiert, eingetragen und auch noch an den passenden Stellen parzelliert, wäre es möglich, diese Informationen daraus abzuleiten - so existiert aber in meinen Augen derzeit durchaus ein Bedarf für solch eine Zwischen- bzw. Näherungslösung. +10 das ist genau das, was ich Martin darauf schrieb.. Eine Erfassung des place-polygons kann nur als /Zwischenlösung/ Sinn machen, wenn es an landuse=* /mangelt/. Weil es schnell gehen soll, behebt man nicht den Mangel, sonder begnügt sich mit dieser Näherung. Das ist ok, aber in einem größeren zeitlichen Kontext ist es verschwendete Zeit, weil OSM ja die Erfassung des landuse=* prinzipiell schon will. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse - gewerbliche Flächen
Am 12. September 2011 17:51 schrieb Christian Müller cmu...@gmx.de: parallel zum Thema der Wohnflächenerfassung, könnte man die landuse Erfassung vereinfachen, indem man sich für das tagging teilweise nach ISIC richtet - das ist eine internationale Klassifikation für Gewerbetypen, die auch von der EU übernommen wurde. könnte man machen, klingt aber so pauschal ein bisschen kompliziert. Wenn man daraus tags für OSM ableiten kann, die spezifischer sind als das, was wir haben, (ich habe mir die Norm jetzt nicht angesehen, aber z.B. so was wie producing=automotive oder producing=textile oder so könnte ich mir schon vorstellen). Zusätzlich macht auch die BauNVO auf Ebene der Bauflächen keinen Unterschied zwischen Industrie- und gewerblicher Fläche, beides ist dort als (G) gekennzeichnet.. Das stimmt nicht. §8 beschreibt Gewerbegebiete: (1) Gewerbegebiete dienen vorwiegend der Unterbringung von nicht erheblich belästigenden Gewerbebetrieben. (2) Zulässig sind 1. Gewerbebetriebe aller Art, Lagerhäuser, Lagerplätze und öffentliche Betriebe, 2. Geschäfts-, Büro- und Verwaltungsgebäude, 3. Tankstellen, 4. Anlagen für sportliche Zwecke. (dann kommen noch Ausnahmen) und §9 beschreibt Industriegebiete: (1) Industriegebiete dienen ausschließlich der Unterbringung von Gewerbebetrieben, und zwar vorwiegend solcher Betriebe, die in anderen Baugebieten unzulässig sind. (2) Zulässig sind 1. Gewerbebetriebe aller Art, Lagerhäuser, Lagerplätze und öffentliche Betriebe, 2. Tankstellen. (nochmal Ausnahmen). Du hast bereits beobachtet, dass Mapper vor Ort teilweise nicht auseinanderhalten (können!), was commercial und was industrial ist. Evtl. sollte man industrial und commercial also zusammenlegen und stattdessen den Gewerbetyp, sofern ein Mapper ihn tatsächlich kennt, mit einem Zusatztag ausdifferenzieren: -1 commercial kommt aus dem Zoning-Planungsrecht, wie es z.B. in den USA gilt, und beschreibt vorwiegend geschäftliche Nutzung, wird aber auch benutzt für Innenstadtbereiche (m.E. unglücklich, dass unsere Innenstädte damit zu Kommerz werden, zumindest tagging-technisch, siehe Tradition der europäischen Stadt als Schlagwort). Nur weil man das in Deutschland evtl. nicht genau anwenden kann, sollte man es noch lange nicht mit Industrie zusammenwerfen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] falsche nodes in europe-cut? / osmosis und 15GB zuviel?
Am 12. September 2011 15:39 schrieb NopMap ekkeh...@gmx.de: Wieso die Nordsee an den Balkan verlegt wird, kann ich Dir allerdings auch nicht sagen. Vielleicht ein Super-Multipolygon, das eine Landesgrenze bis dorthin durchzieht? Vielleicht eine der Relationen vom Typ Weltmeer oder Landmasse, z.B. Landmasse Europa? Das Zeugs liegt leider bei allen die Datenbanken, die sich die Daten importieren und Relationen rekursiv importieren (vermute ich)... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 13:15, schrieb Martin Koppenhoefer: -1, ich würde nicht reinschreiben, was _nicht_ erfasst wird, sondern das, was erfasst wird. Ja, da bin ich eigentlich bei Dir. Evtl. macht aber eine Definition von beiden Seiten (was wird eingeschlossen, was wird ausgeschlossen) Sinn, gerade dann, wenn man mit der einschließenden Definition des Begriffs fuzzy bleibt. Zudem weiß ich schneller was gemeint ist, wenn sowohl Beispiele für einschließend, als auch ausschließend gegeben werden. Denn ich muss mir gewisse Ausschlüsse nicht aus der einschließenden Definition ableiten. _Vorrangig_ zum Wohnen verwendet Grenze dort, wo vor Ort beobachtbar die Flächennutzung wechselt sind einschließend, aber das damit die admin.-rechtl. Grenze ausgeschlossen ist, muss ich mir erst überlegen. Admin-rechtliche Gebiets- und Flächengrenzen sind in X besser aufgehoben. +1, das steht da auch schon klar drin: sie werden mit boundary=administrative und admin_level getaggt. Gebietsnamen werden üblicherweise über place nodes getaggt. -1. Sie können als place Node oder area getaggt werden. Ein _Gebiet_ nur als Node zu taggen beinhaltet immanent einen gewissen Grad von Unvollständigkeit. Ich bezog mich auf amtliche Gebietsnamen.. In der gesamten mail. Sorry, dass ich es gerade in diesem Satz nicht nochmal explizit erwähnt hatte - mein Fehler. Und amtliche Gebiete zu erfassen ist unsinnig, wenn Du schon ein +1 oben setzt. Nur darum geht es. Wie die Siedlungsfläche, als nicht-amtliches Gebiet besser über die landuses-Relation erfasst wird, hatte ich auch schon geschrieben - aus Mangel an landuse-Daten kann ein place-polygon hier /temporär/ Sinn machen. Andere nicht-amtliche Gebiete, die auch keinen bekannten Bezug zu anderen Daten haben, können gerne als place-polygon erfasst werden. Dem hatte ich mich bei place=locality schon teilweise angeschlossen. Diese place Grenzen stellen dann ja auch keine Dopplung zu anderen Daten dar. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Flüssen und Bächen; gesplittet von Exportmöglichkeiten
Sehe ich ein. In der Tat ist das eine knifflige Angelegenheit. [In der Hydrogeographie behilft man sich mit Ordnungskennzahlen, die sich aus der Größe des Gewässersystems (bzw. der Summe der Gewässermitglieder) ergibt. Dennoch fehlt natürlich eine klare Definition.] Daher bleibt es uns OSM-lern überlassen, eine Klassifizierungslösung zu finden. Getan haben wir das ja auch schon bei den highway=track und den grade-Werten. Natürlich ist das nicht optimal, aber gerade zwischen Flüssen und Bächen könnte man da aufgrund ihrer geringen Anzahl (geg. Bächen und Kanälen) schon was auf die Beine stellen. M.E. gibt es 2 Hauptarten von Fließgewässern in OSM: natürliche und künstliche. Bei den natürlichen haben wir 2 Arten: river und stream, wobei letztere prinzipiell kleiner sind als erstere, width als Breitenangabe ist auch nicht verkehrt, sofern man das kann. Im deutschen Sprachgebrauch gibt es hauptsächlich diese 2 Arten (Fluss und Bach, es gäbe noch Strom als Sonderfall von Fluss, aber nach unten ist das eigentlich alles), während das Italienische mehrere unterschiedliche natürliche, kleinere Wasserläufe kennt, daher gibt es hier öfters mal Nachfragen und Unzufriedenheit diesbezüglich ;-) Naja, wenn man meinen Professor fragen würde, hätte sicherlich auch der mehr als zwei Arten von Fließgewässern auf Lager. Aber ja, im Sprachgebrauch sind es hauptsächlich zwei. Bei den künstlichen haben wir 3 Arten: canal, drain und ditch (blöderweise scheint die Trennung, wenn man das Wiki streng liest, zwischen drain und ditch auch eine funktionale zu sein, wobei andererseits, wenn man immer noch streng liest, sich da eigentlich eine Lücke ergeben würde für künstliche Wasserwege, die nicht in einem Graben laufen und solche, die nicht für industrielle Abwässer oder Regenwasser geschaffen sind, (sondern z.B. zur Trockenlegung dienen, was ja drain prinzipiell als Wort abdeckt). Diese blöde Angewohnheit, Beispiele direkt in die Definition zu schreiben, sorgt, solange man das exklusiv interpretiert, für unnötigen Ballast. Praktisch sieht das aber m.E. kaum jemand so eng, sonst würde man ja eine Vielzahl von Fließgewässern gar nicht taggen können. Meine eigene Interpretation ist, dass auch die künstlichen Fließgewässer sich von groß nach klein differenzieren, also wie genannt canal, drain, ditch. Meiner Meinung nach genügt das unterscheiden zwischen Fluss und Bach auch völlig. Mehr noch, man sollte hier eigentlich aufhören können und alles weitere (z.B. Kanalisiert? Industrieabfluss? Zu- oder Ableitung? Schiffbar?) den Sekundärtags überlassen. Der Primärtag (also waterway) sollte nur für die grundsätzliche Größenbeschreibung da sein. Das Erscheinungsbild eines Fließgewässers ist doch hauptsächlich, die Art der Nutzung oder gar historische Umstände erst einmal nebensächlich. Wir definieren einen Feldweg ja auch erst einmal mit highway=track und danach erst dessen Zustand oder dessen Nutzung. Somit ließe sich das Problem der fehlenden Definition *eigentlich* leicht lösen. Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 13:35, schrieb Martin Koppenhoefer: Christian, da Du gerne die Wikipedia zitierst hier 2 Links, die Dich interessieren dürften: http://de.wikipedia.org/wiki/Stadtviertel Ein Stadtviertel ist ein überschaubares, häufig nur aus einigen Straßenzügen bestehendes, soziales Bezugssystem, das sich sowohl räumlich/geografisch als auch von der sozialen oder ethnischen Struktur seiner Bewohner her von anderen Stadtvierteln abgrenzt. Eine offizielle Grenzziehung existiert dabei meist nicht. Das Gebiet wird durch seine Bewohner definiert und ist unabhängig vom Gebiet eines Stadtteils oder Stadtbezirks. analog würde ich auch Wohngebiete auf dem Land sehen. würde ich -- das ist deine Sichtweise.. wir wollen aber das, was allg. verständlich und anerkannt ist. Die Wikipediadef. zu 'Stadtviertel' deckt sich mit OSMs Sichtweise. Dort heißt es in der Regel nur statistische oderhistorische Unterteilung / mostly statistical, historic Ein Problem ist, dass der Wikipedia-Teil durch seine Bewohner sicherlich für die Begriffsdefinition des Stadtviertels taugt, aber eigentlich nicht für die Erfassung geografischer Daten. Streng genommen, kannst Du die Stadtviertelgrenze dann erst eintragen, wenn Du weißt, das die Bewohner einen Konsens über ihren Verlauf haben. Sonst trägst Du /deine/ Realität ein, die in OSM aber behauptet /allgemeingültig/ zu sein. An der Stelle ist die Erfassung der Realität für einen Mapper immens schwer, denn er muss nicht nur eine Person, sondern mehrere des Stadtviertels befragen, um zu sehen, ob sich Aussagen decken. Die Erfassung nicht-gegenständlicher und zugleich nicht-amtlicher geografischer Information bedeutet also, will man es ordentlich machen, viel Arbeit. Es steht glasklar da: Eine offizielle Grenzziehung existiert dabei meist nicht. Da OSM weder Malen nach Zahlen noch meines Erachtens oder wir würfeln eine Grenze aus ist, hat eine Grenze, die nicht offiziell existiert, auch nichts in OSM verlorenund schon gar nicht im namespace border=_administrative_ Da wäre dann wohl border=residential_guess angebrachter. In aller Regel wird aber eine offizielle Grenze für die meisten Stadtviertel tatsächlich existieren, gerade wenn ein Amt zu Statistik für ein Stadtviertel erstellt. Zweiter Link: http://de.wikipedia.org/wiki/Ortsteil Ortsteil, je nach Art der Gebietskörperschaft (Verwaltungseinheit) auch Stadtteil, Gemeindeteil, Ortschaftsbestandteil oder Fraktion, ist in Siedlungsgeografie, Demographie und Raumplanung ein unspezifischer Sammelbegriff für abgegrenzte und mit eigenem Namen versehene Teile einer Siedlung (einem Ort, einer Ortschaft im allgemeinem Sinne). Ja, ist so allgemein gehalten, dass es unser beider Auffassungen nirgendwo im Weg steht. /Wodurch/ abgegrenzt wird, und /wer/ Namen vergibt ist im einzelnen zu betrachten. Und wenn von einer Verwaltungseinheit gesprochen wird, so fängt der Satz an, dann doch bitte durch die Verwaltung.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 13:24, schrieb Martin Koppenhoefer: -1, diese schmale Flächenverbrauchsseite in der Wikipedia, ohne vernünftige Quellenangaben, ist für mich nicht die Bibel. Da Du Wikipedia's Defintion von Flächenverbrauch nicht traust, schaust Du vielleicht mal auf die Seite des statistischen Bundesamtes dazu: http://www.destatis.de/jetspeed/portal/cms/Sites/destatis/Internet/DE/Content/Statistiken/Umwelt/UmweltoekonomischeGesamtrechnungen/Flaechennutzung/Content75/FlaechennutzungInfo.psml Auch keine Bibel, aber sehr viele Leute, die sich auf eine Begriffsdefinition geeinigt haben, wo Du dein eigenes Bier braust. (im Zusammenhang bebaute Ortsteile). steht der sezifischeren Def. nicht entgegen. Je nach Sinn und Zweck bzw. Kontext sind die Kriterien teilweise unterschiedlich. Wir erfassen bisher keine Verkehrsflächen explizit, daher sollte unsere Siedlungsgrenze auch nicht darauf aufbauen. Place ist unser Tag für Orte. Die können gesetzlich normativ definiert sein, müssen das aber nicht. Es reicht, dass es sie gibt. Nochmal, willst Du die Realität abbilden oder eine erfinden? In ersterem Fall hat man sich nunmal an ein paar Konventionen zu halten. Sonst schreib halt Fantasy-Computerspiele.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12. September 2011 17:08 schrieb Christian Müller cmu...@gmx.de: Am 11.09.2011 12:37, schrieb Martin Koppenhoefer: Macht es Sinn, das place polygon doppelt zu pflegen, ohne Sinnbezug, wenn es einfacher und pflegeleichter, durch eine Relation geht? Ich denke nicht. place-polygon heisst nicht, dass dieses Polygon unbedingt durch einen doppelten Way gemappt werden muss, Multipolygone rechne ich da natürlich auch dazu. Je nach Mapping-art wird man aber mit einem alles umschliessenden Polygon oft besser zurechtkommen (das kann natürlich auch ein Multipolygon sein, also aus way-Stücken bestehen). Das ist auch eine Frage, wie man die Daten besser organisiert. Z.B. könnte man das deutsche Staatsgebiet auch als Summe aller Landkreise und kreisfreien Städte mappen. Oder verschachtelt (d.h. z.B. aus den Bundesländern, die wiederum aus den Gemeinden bestünden, etc.). Macht aber keinen Sinn m.E., ist viel zu fehleranfällig, und wer dann eine Deutschlandgrenze braucht müsste sich erst mal mit den Gemeinden rumschlagen (Aufwand steht nicht mehr im Verhältnis zum Nutzen). Wenn place-polygons verwendet werden, um Siedlungsfläche (im Sinne der Siedlungsgeografie) zu erfassen, machen Mapper sich doppelte Arbeit. Denn die Siedlungsfläche ist, per Definition, eine Sammlung bestimmter Einzelflächen. Nicht /irgendwelcher/ Einzelflächen, sondern solcher die schon getaggt werden. jein. Zum einen werden Verkehrsflächen nicht getaggt (zumindest allgemein bisher) und dann ist eine Siedlung siedlungsgeografisch eben nicht allein durch Nutzung bestimmt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12. September 2011 18:30 schrieb Christian Müller cmu...@gmx.de: Wie die Siedlungsfläche, als nicht-amtliches Gebiet besser über die landuses-Relation erfasst wird, hatte ich auch schon geschrieben - aus Mangel an landuse-Daten kann ein place-polygon hier /temporär/ Sinn machen. landuse ist die Bodennutzung. Wenn ich je eine Relation aus den landuses machen würde (ich würde das eher nicht tun, weil die Innengrenzen da nicht interessieren), dann würde diese Relationen natürlich für den siedlungsgeographischen Teil einen tag place=* bekommen, sie wäre also keine landuse-Relation. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12. September 2011 19:25 schrieb Christian Müller cmu...@gmx.de: Am 12.09.2011 13:35, schrieb Martin Koppenhoefer: Christian, da Du gerne die Wikipedia zitierst hier 2 Links, die Dich interessieren dürften: http://de.wikipedia.org/wiki/Stadtviertel Ein Stadtviertel ist ein überschaubares, häufig nur aus einigen Straßenzügen bestehendes, soziales Bezugssystem, das sich sowohl räumlich/geografisch als auch von der sozialen oder ethnischen Struktur seiner Bewohner her von anderen Stadtvierteln abgrenzt. Eine offizielle Grenzziehung existiert dabei meist nicht. Das Gebiet wird durch seine Bewohner definiert und ist unabhängig vom Gebiet eines Stadtteils oder Stadtbezirks. analog würde ich auch Wohngebiete auf dem Land sehen. würde ich -- das ist deine Sichtweise.. wir wollen aber das, was allg. verständlich und anerkannt ist. da das wohl nicht klar genug war: ich sehe Wohngebiete auf dem Land analog. Ein Problem ist, dass der Wikipedia-Teil durch seine Bewohner sicherlich für die Begriffsdefinition des Stadtviertels taugt, aber eigentlich nicht für die Erfassung geografischer Daten. Streng genommen, kannst Du die Stadtviertelgrenze dann erst eintragen, wenn Du weißt, das die Bewohner einen Konsens über ihren Verlauf haben. Sonst trägst Du /deine/ Realität ein, die in OSM aber behauptet /allgemeingültig/ zu sein. dann ändert der nächste das halt. Du wirst sehen, dass da kein Editwar entstehen wird. An der Stelle ist die Erfassung der Realität für einen Mapper immens schwer, denn er muss nicht nur eine Person, sondern mehrere des Stadtviertels befragen, um zu sehen, ob sich Aussagen decken. nein, er muss sich nur auskennen im Gebiet. Es steht glasklar da: Eine offizielle Grenzziehung existiert dabei meist nicht. genau. Das, was ich Dir seit zig Mails schon schreibe. Da OSM weder Malen nach Zahlen noch meines Erachtens oder wir würfeln eine Grenze aus ist, hat eine Grenze, die nicht offiziell existiert, auch nichts in OSM verloren und schon gar nicht im namespace border=_administrative_ Da wäre dann wohl border=residential_guess angebrachter. bitte, nicht border sondern boundary, hier lesen manche auch mit, um was übers Tagging zu erfahren. Der tag, den ich verwenden würde, ist place, nicht boundary. In aller Regel wird aber eine offizielle Grenze für die meisten Stadtviertel tatsächlich existieren, gerade wenn ein Amt zu Statistik für ein Stadtviertel erstellt. wenn man will und darf, kann man diese Einteilungen von den Statistikämtern verwenden, solange sie sich mit dem decken, wie man es vor Ort sieht. Im Prinzip ist mir aber egal, wie die Ämter die Stadt einteilen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12. September 2011 19:33 schrieb Christian Müller cmu...@gmx.de: Am 12.09.2011 13:24, schrieb Martin Koppenhoefer: -1, diese schmale Flächenverbrauchsseite in der Wikipedia, ohne vernünftige Quellenangaben, ist für mich nicht die Bibel. Da Du Wikipedia's Defintion von Flächenverbrauch nicht traust, schaust Du vielleicht mal auf die Seite des statistischen Bundesamtes dazu: http://www.destatis.de/jetspeed/portal/cms/Sites/destatis/Internet/DE/Content/Statistiken/Umwelt/UmweltoekonomischeGesamtrechnungen/Flaechennutzung/Content75/FlaechennutzungInfo.psml Die selbe chose in grün, da es auch da um umweltökonomische Gesamtrechnungen geht. Die einzelnen dort unterschiedenen Flächenarten erfassen wir bisher so in OSM nicht, daher ist das für OSM nicht relevant. Ich traue der Definition zum Flächenverbrauch durchaus, nur bringt sie uns m.E. hier nicht weiter. Je nach Sinn und Zweck bzw. Kontext sind die Kriterien teilweise unterschiedlich. Wir erfassen bisher keine Verkehrsflächen explizit, daher sollte unsere Siedlungsgrenze auch nicht darauf aufbauen. Place ist unser Tag für Orte. Die können gesetzlich normativ definiert sein, müssen das aber nicht. Es reicht, dass es sie gibt. Nochmal, willst Du die Realität abbilden oder eine erfinden? da es nicht die Realität in einem Tag gibt, sondern verschiedene Betrachtungsweisen davon, ist es nur logisch, dass wir auch in OSM, wo wir es für sinnvoll erachten, verschiedene Aspekte taggen. Das hat mit Realität erfinden nichts zu tun. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 19:25, schrieb Christian Müller: Da OSM weder Malen nach Zahlen noch meines Erachtens oder wir würfeln eine Grenze aus ist, hat eine Grenze, die nicht offiziell existiert, auch nichts in OSM verlorenund schon gar nicht im namespace border=_administrative_ Da wäre dann wohl border=residential_guess angebrachter. Also mal ehrlich, ich bin nicht sicher ob du verstanden hast, wie Openstreetmap funktioniert. Selbstverständlich ist OSM jede Menge meines Erachtens, das ist ja gerade der Witz dabei. Wenn man das nicht wollte, hätte von vorne herein nicht freie Tags sonder eine verwaltete Liste von zulässigen Tags implementiert. (Just my two cents als einem von dieser ausufernden dogmatischen Diskussion langsam leicht angenervtem gemeinen Mapper) Friedhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 13:24, schrieb Martin Koppenhoefer: ..Fantasy-Computerspiele.. Das war etwas arg pauschal, sorry. Meistens mag ich es nicht, wenn meine Argumente mit solchen pauschalen Aussagen weggewischt werden, hier also nochmal kurz die Beweggründe hinter dieser Aussage: - Siedlungsgeografie erfassen: ja - admin.-rechtliche Grenzen erfassen: ja - die unscharfe Grenze eines Stadtviertelbewohners aufnehmen: wenn's sein muss Aber eben bitte so, dass das unterscheidbar bleibt, als Datennutzer will ich doch wissen, wo welche Daten herkommen, bzw. in welchem Zweck bzw. Kontext sie stehen. Ich kann doch nicht alles unter einem Tag zusammenmanschen, schließlich sollen die Datennutzer kreativ werden, bei dem was sie mit den Daten anstellen, nicht die Datenerfasser. D.h. - für die Siedlungsgeografie den wiss. Definition folgen und nicht neue erfinden, dieser Begriff entstammt doch schon einem Spezialgebiet! - welche zwei Laien unterhalten sich über 'Siedlungsgeografie' ohne wenigstens den Anspruch daran zu haben, dieses wiss. Gebiet einigermaßen greifen zu können? - für admin.-rechtliche Grenzen border=administrative verwenden - dokumentieren, welche place values amtl. Anspruch haben, welche nicht - da place amtl. und nicht-amtl. mischt - unscharfe Grenzen geeignet taggen, damit erkennbar bleibt, dass das die Auffassung des Mappenden ist, ohne Anspruch auf eine sonstige Korrektheit Wenn wir bei OSM Dinge mischen wöllten, die so lala zusammengehören, anstatt sauber auszudifferenzieren, dann wäre die Ausdifferenzierung eines highways auch nie begonnen worden, da reicht ja dann: hier verläuft ein Weg welche Art Weg interessiert nicht, es kommt nur darauf an da ist ein Weg Was interessiert, sollte, so als Zielvorstellung, der Nutzer bestimmen (können). Es ist also nicht verkehrt, Struktur zu suchen und zu dokumentieren, wo sie existiert, anstatt die Hände in den Schoß zu legen und zu meinen das grobe wird dem Nutzer schon reichen. Wer das grobe erfassen will, weil er nicht mehr Infos hat, der nutzt, um bei highway zu bleiben, highway=road Damit ist anderen Mappern klar, wie genau diese Information ist - nämlich sehr grob, ein Platzhalter für jemanden der dort weitermappen will. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Ebenen ebenfalls weg
Moin Jan, Jan Tappenbeck schrieb: kann mir noch einer sagen wie die Variable für die Ebenen heißt ? wie war das noch gleich mit Fisch geben und Fischen lehren? Wenn Du in den Erweiterten Einstellungen in das Suchfeld .bounds eingibst, zeigt er Dir alle Einträge mit .bounds an. Dann erkennst Du den Ebenen-Dialog bestimmt (*) - und weißt auch gleich, wie Du bei Bedarf die anderen findest. Gruß Georg (*) Du darfst nur keinen Tunnel-Blick haben, wo ich Dir hier eine Brücke baue ... ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse - gewerbliche Flächen
Martin Koppenhoefer dieterdre...@gmail.com [Mon, Sep 12, 2011 at 06:10:29PM CEST]: [...] Du hast bereits beobachtet, dass Mapper vor Ort teilweise nicht auseinanderhalten (können!), was commercial und was industrial ist. Evtl. sollte man industrial und commercial also zusammenlegen und stattdessen den Gewerbetyp, sofern ein Mapper ihn tatsächlich kennt, mit einem Zusatztag ausdifferenzieren: -1 commercial kommt aus dem Zoning-Planungsrecht, wie es z.B. in den USA gilt, und beschreibt vorwiegend geschäftliche Nutzung, wird aber auch benutzt für Innenstadtbereiche (m.E. unglücklich, dass unsere Innenstädte damit zu Kommerz werden, zumindest tagging-technisch, siehe Tradition der europäischen Stadt als Schlagwort). Nur weil man das in Deutschland evtl. nicht genau anwenden kann, sollte man es noch lange nicht mit Industrie zusammenwerfen. meinst Du commercial oder retail? -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Fl
Hallo, Am Montag 12 September 2011 19:58:36 schrieb Martin Koppenhoefer: bitte, nicht border sondern boundary, hier lesen manche auch mit, um was übers Tagging zu erfahren. Der tag, den ich verwenden würde, ist place, nicht boundary. Keine Sorge, die lesen diesen Thread bestimmt schon lange nicht mehr... Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse - gewerbliche Flächen
Am 12. September 2011 22:18 schrieb Johannes Huesing johan...@huesing.name: Martin Koppenhoefer dieterdre...@gmail.com [Mon, Sep 12, 2011 at 06:10:29PM CEST]: [...] Du hast bereits beobachtet, dass Mapper vor Ort teilweise nicht auseinanderhalten (können!), was commercial und was industrial ist. Evtl. sollte man industrial und commercial also zusammenlegen und stattdessen den Gewerbetyp, sofern ein Mapper ihn tatsächlich kennt, mit einem Zusatztag ausdifferenzieren: -1 commercial kommt aus dem Zoning-Planungsrecht, wie es z.B. in den USA gilt, und beschreibt vorwiegend geschäftliche Nutzung, wird aber auch benutzt für Innenstadtbereiche (m.E. unglücklich, dass unsere Innenstädte damit zu Kommerz werden, zumindest tagging-technisch, siehe Tradition der europäischen Stadt als Schlagwort). Nur weil man das in Deutschland evtl. nicht genau anwenden kann, sollte man es noch lange nicht mit Industrie zusammenwerfen. meinst Du commercial oder retail? ich meine commercial. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Hi, Am 11.09.2011 16:11, schrieb Martin Koppenhoefer: Ist die Folge von was anderem: die Einteilung die wir haben spiegelt die amerikanische Realität wieder, daher haben wir in Deutschland Probleme. Wir hätten bei einem deutschen Schema neben industrial was für Gewerbegebiet erfunden. Könnte man nachträglich z.B. mit einem Zusatztag zur Intensität (light/heavy) oder so lösen. +1 siehe ISIC, könnte evtl. alle glücklich machen.. Frage ist, wie values auf landuse=grob grob=detail verteilt werden. Mir ging es noch nie um Bau in dieser Diskussion, sondern immer um Bestand. Planungen mit der Realität im selben Tag zu mischen halte ich für einen großen Fehler, weil es eben diesen Unterschied verwischt. +1 ich meinte mit Baufläche auch nicht construction sondern bebaute Fläche ..Meint 'Baufläche' im amtsdeutsch denn nur geplante Fläche? Mein Eindruck war, dass Baufläche keinen zeitlichen Bezug hat, also sowohl bebaute Fläche, als auch zu bebauende Fläche. Demnach wären dann Bauflächen in Planung für landuse auszuschließen, oder so etwas wie: landuse=meadow proposed=residential wenn der Mappende mehr weiß. Die Antwort auf die Frage, ob Flaechen an Ways geklebt werden sollen, ist eine Geschmaeckssache. es gibt klar Vor- und Nachteile bei beiden Vorgehensweisen. Die wurden inzwischen weitgehend in diesen Threads der letzten Wochen erörtert (vor allem zu Beginn) und jeder kann sich selbst überlegen, was er für wichtig hält. Ich denke, das nach einer besseren Ausdifferenzierung der Tags dazu mehr Klarheit 'entsteht'. Flächennutzungsgrenzen an andere Flächennutzungsgrenzen zu kleben ist gängige Praxis, daraus lässt sich für das Wiki ableiten, dass Flächennutzungsgrenzen dort sind, wo Nutzungsarten wechseln. Bis landuse=traffic erfasst wird, wäre das Kleben an highway=* übergangsweise 'ok'. Um landuses nicht übermäßig zu fragmentieren, kann landuse=traffic über anderen landuse=* liegen (IMHO, dazu hat sich bis jetzt niemand geäußert). Damit bleibt die Frage beantwortbar, ob die Telefonzelle im Park oder an der Straße steht, obwohl der Park links und rechts der Straße als ein landuse-polygon erfasst wird. Der anfangs zitierte Straßengraben kann als line oder area innerhalb landuse=traffic liegen, sollte aber ein anderes Tag bekommen, denn das Entwässerungssystem gehört zur Verkehrsfläche, ändert also den landuse=* nicht. Da gab es 'ditch' irgendwo.. Wer das Kleben mit seinem Editor als mühsam oder schwer umsetzbar empfindet, schreibe bitte einen Bugreport für josm/portlatch/merkaartor. Wir taggen nicht für Editoren, wenn ich das mal von wir taggen nicht für Renderer adaptieren darf. +1. Da steht, dass man eine Fläche, die überwiegend durch Wohnen genutzt wird, als landuse=residential taggen soll. Das dass aber ein Wohngebiet im siedlungsgeographischen Sinne sei steht da nirgends, zumindest nicht auf der englischen Seite des wiki In der Tat ist die englische Seite dazu besser, als die deutsche - da wird von Mischgebieten, Wohngebieten usw. gesprochen - diese Begriffe sollten dorft maximal stehen, um von Ihnen abzugrenzen. An area of land mit Gegend zu übersetzen, anstatt Gebiet schließt Missdeutungen hin zu amtl. Gebiet eher aus. Fluren und Gemarkungen fallen in den Themenkreis Toponyme und sind zusätzliche Informationen in einer anderen Ebene als administrative Grenzen oder Bodennutzung. Es geht nicht darum, das Mappen einfacher oder komplexer zu machen, sondern diesen Aspekt der Realität abzubilden. +1 Mir war insbesondere wichtig, dass nicht mit der Bodennutzung zu vermischen. Dennoch sollten Fluren und Gemarkungsgrenzen als administrative Grenzen erfasst werden, sofern sie noch aktuell im Kataster liegen. Die Toponomastik ist die Ortsnamenkunde _beliebiger_ geografischer Objekte (lt. Wikipedia). Ortsnamenkunde bringt uns insbes. in einem geschichtlichen Kontext weiter; z.B. wenn es um Grenzstreitigkeiten geht, es hilft uns aber wenig bei der Ermittlung von Grenzen der Realität, wie sie jetzt real vorhanden sind. Ich lehne mich mal etwas aus dem Fenster und behaupte, dass Du zu jedem amtl. Ortsnamen des Katasters Ortsnamenkunde betreiben kannst. Das ist siedlungsgeografisch und historisch eine interessante Angelegenheit, aber für OSM momentan einfach zu weit weg vom Tellerrand. Für nicht-amtl. Ortsnamen hingegen ist evtl. nur über die Ortsnamenkunde ein Grenzverlauf ermittelbar - ein Mapper muss halt abwägen, welche Ressourcen er da hat. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Ebenen ebenfalls weg
Am 12.09.2011 21:51, schrieb Georg Feddern: Moin Jan, Jan Tappenbeck schrieb: kann mir noch einer sagen wie die Variable für die Ebenen heißt ? wie war das noch gleich mit Fisch geben und Fischen lehren? Wenn Du in den Erweiterten Einstellungen in das Suchfeld .bounds eingibst, zeigt er Dir alle Einträge mit .bounds an. Dann erkennst Du den Ebenen-Dialog bestimmt (*) - und weißt auch gleich, wie Du bei Bedarf die anderen findest. Gruß Georg (*) Du darfst nur keinen Tunnel-Blick haben, wo ich Dir hier eine Brücke baue ... ;-) hi ! jetzt habe ich die Brücke überquert ! Danke mein Baumeister ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Fl
Hallo, Am 13.09.2011 00:07, schrieb Wolfgang: Am Montag 12 September 2011 19:58:36 schrieb Martin Koppenhoefer: bitte, nicht border sondern boundary, hier lesen manche auch mit, um was übers Tagging zu erfahren. Der tag, den ich verwenden würde, ist place, nicht boundary. Keine Sorge, die lesen diesen Thread bestimmt schon lange nicht mehr... und die paar Durchschnittsmapper, die bis hierher durchgehalten haben, werden wohl zukünftig die Finger von Places, Landuses und Boundaries lassen. Ich jedenfalls. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Aggiornamento elenco user-highways
Il giorno 11 settembre 2011 23:51, Daniele Forsi dfo...@gmail.com ha scritto: che senso ha inserire delle residential senza dargli un nome? Per definizione le residential servono per andare a casa di qualcuno e come fai se non sai il nome della via? Intendiamoci ne ho anche io qualcuna da completare... Ci sono strade su cui non si affaccia nessun numero civico. Da quello che mi è sembrato di capire per via empirica, queste strade non serve che abbiano il nome. Qui [1] puoi vederne un esempio: in questa zona ho mappato i civici girando a piedi per tutta la zona, e ti posso assicurare che questa il nome non ce l'aveva (non sul posto, per lo meno). Si tratta di un quartiere residenziale molto recente, in cui hanno appena costruito o stanno finendo di costruire palazzi e villette a schiera; altre strade della zona, che un anno fa non avevano nome, l'hanno ricevuto quando le case sono state ultimate e il civico è stato assegnato. -- Daniele Forsi Ciao, Simone [1] http://www.openstreetmap.org/browse/way/59140864 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Problema Edge 800 e wp
Ciao a tutti ripropongo questo quesito. Ho letto tutti i vari forum e articoli riguardanti il problema ma non riesco a risolvere una cosa. Sono riuscito solo una volta a convertire il file location.fit. Ho cancellato il file e sono uscito a rilevare, i wp sullo schermo dell'edge ci sono, ma appena cerco di aprire il file locatio.fit non riesco mi da errore. Non so cosa fare, non voglio resettare il gps perche' i wp rilevati mi servono. Grazie Mich74 Le mail ti raggiungono ovunque con BlackBerry® from Vodafone! ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Il 12 settembre 2011 09:53, Simone Saviolo ha scritto: Si tratta di un quartiere residenziale molto recente, in cui hanno appena costruito o stanno finendo di costruire palazzi e villette a schiera; altre strade della zona, che un anno fa non avevano nome, l'hanno ricevuto quando le case sono state ultimate e il civico è stato assegnato. d'accordo, ma dubito che in Italia il 45% delle highway=residential sia in quella situazione ho visto che qualcuno ha usato name=Strada da denominare è una buona idea? Un problema dei vari tag proposti noname, unnamed, ecc. è l'ambiguità: il nome non esiste, non è scritto su un cartello, ecc. per evitare l'ambiguità si può descrivere la situazione delle note in italiano. Si possono vedere le strade senza nome in OSM Inspector da zoom 8 in poi: http://tools.geofabrik.de/osmi/?view=highwayslon=12.06006lat=41.94642zoom=6overlays=name_missing_major,name_missing_minor -- Daniele Forsi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Il giorno 12 settembre 2011 11:32, Daniele Forsi dfo...@gmail.com ha scritto: Il 12 settembre 2011 09:53, Simone Saviolo ha scritto: Si tratta di un quartiere residenziale molto recente, in cui hanno appena costruito o stanno finendo di costruire palazzi e villette a schiera; altre strade della zona, che un anno fa non avevano nome, l'hanno ricevuto quando le case sono state ultimate e il civico è stato assegnato. d'accordo, ma dubito che in Italia il 45% delle highway=residential sia in quella situazione Assolutamente. Segnalavo solo il fatto che *a volte* (poche!) non è un errore. ho visto che qualcuno ha usato name=Strada da denominare è una buona idea? Un problema dei vari tag proposti noname, unnamed, ecc. è l'ambiguità: il nome non esiste, non è scritto su un cartello, ecc. per evitare l'ambiguità si può descrivere la situazione delle note in italiano. Eh lo so, manca un modo accettato per indicare l'assenza di nome. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
2011/9/12 Daniele Forsi dfo...@gmail.com: ho visto che qualcuno ha usato name=Strada da denominare è una buona idea? No, non è una buona idea secondome. Anche name=fixme, name=missing name, ecc. sono contraproduttivi. Se una strada (o un altro feature) non ha un nome, non mettiamo il tag name. Se il nome è sconosciuto: dito. Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Anche per me non ha senso il name=qualcosa, anche se non si mappa per il rendering (cit.), l'etichetta comparirebbe sui rendering e bisognerebbe che i programmatori andassero a controllare se il name contiene fixme o similia. Piuttosto proporrei un tag fixme=noname, ma sarebbe un lavoraccio applicarlo al 46% delle vie italiane. Ciao, Stefano PS Piuttosto cerchiamo qualche servizio che ci possa concedere l'uso dei nomi delle vie per copiarle, Tuttocittà o simili. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
2011/9/12 sabas88 saba...@gmail.com: Piuttosto proporrei un tag fixme=noname, ma sarebbe un lavoraccio applicarlo al 46% delle vie italiane. e cosa dovrebbe significare? a) il feature ha un nome e in OSM non è inserito b) il feature non ha un nome c) il feature potrebbe avere un nome o anche no, e in OSM non c'è. Se l'informazione è quella di c) direi che il fatto che name non è assegnato è sufficiente. Per b) direi che un altro tag (noname=yes) potrebbe essere più adatto, ma cmq. b) potrebbe essere anche il feature ha un nome ma non si vede al luogo ed il mappatore quindi ha pensato che invece non ha un nome, e quindi un altro mappatore cmq. non si potrebbe fidare di un' informazione del genere. PS Piuttosto cerchiamo qualche servizio che ci possa concedere l'uso dei nomi delle vie per copiarle, Tuttocittà o simili. -1, vorrei avere i dati buoni in OSM, quelli giusti. Se copiamo gli errori da altri non vedo il senso. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Agenzia del Territorio? :) Il giorno 12 settembre 2011 12:56, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2011/9/12 sabas88 saba...@gmail.com: Piuttosto proporrei un tag fixme=noname, ma sarebbe un lavoraccio applicarlo al 46% delle vie italiane. e cosa dovrebbe significare? a) il feature ha un nome e in OSM non è inserito b) il feature non ha un nome c) il feature potrebbe avere un nome o anche no, e in OSM non c'è. Se l'informazione è quella di c) direi che il fatto che name non è assegnato è sufficiente. Per b) direi che un altro tag (noname=yes) potrebbe essere più adatto, ma cmq. b) potrebbe essere anche il feature ha un nome ma non si vede al luogo ed il mappatore quindi ha pensato che invece non ha un nome, e quindi un altro mappatore cmq. non si potrebbe fidare di un' informazione del genere. PS Piuttosto cerchiamo qualche servizio che ci possa concedere l'uso dei nomi delle vie per copiarle, Tuttocittà o simili. -1, vorrei avere i dati buoni in OSM, quelli giusti. Se copiamo gli errori da altri non vedo il senso. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Il 12 settembre 2011 11:32, Daniele Forsi dfo...@gmail.com ha scritto: Il 12 settembre 2011 09:53, Simone Saviolo ha scritto: d'accordo, ma dubito che in Italia il 45% delle highway=residential sia in quella situazione Mappando da PCN io spesso tracciavo la strada, la taggavo residential perche' o la conoscevo o perche' palesemente portava ad un gruppo di case (es: villette a schiera o simili). Pero' non ho mai messo il nome della via perche' non lo conosco. Quindi nel 45% ci sono anche i casi come il mio. Saluti. Fabrizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Il 12/09/2011 12:56, Martin Koppenhoefer ha scritto: PS Piuttosto cerchiamo qualche servizio che ci possa concedere l'uso dei nomi delle vie per copiarle, Tuttocitt o simili. -1, vorrei avere i dati buoni in OSM, quelli giusti. Se copiamo gli errori da altri non vedo il senso. Non mi ricordo se se ne era gi parlato, ma i piani regolatori dei vari comuni non possono essere intesi come documenti ufficiali e quindi di pubblico dominio? In questo caso sarebbero molto pi affidabili di tante altre fonti... ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it Ciao Giuliano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Il giorno 12 settembre 2011 14:46, G Zamboni gd.zamb...@tiscali.it ha scritto: Il 12/09/2011 12:56, Martin Koppenhoefer ha scritto: PS Piuttosto cerchiamo qualche servizio che ci possa concedere l'uso dei nomi delle vie per copiarle, Tuttocittà o simili. -1, vorrei avere i dati buoni in OSM, quelli giusti. Se copiamo gli errori da altri non vedo il senso. Non mi ricordo se se ne era già parlato, ma i piani regolatori dei vari comuni non possono essere intesi come documenti ufficiali e quindi di pubblico dominio? In questo caso sarebbero molto più affidabili di tante altre fonti... Credo di poter dissentire. Conosco almeno tre casi solo a Vercelli in cui il piano regolatore è stato disatteso (progettato in un modo, si è fatto in un altro), senza contare le strade che hanno cambiato nome. Non metterei affatto la mano sul fuoco sul fatto che *oggi* il piano regolatore rifletta la reale situazione. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Si sta parlando (per quanto ho detto io perlomeno) di trovare qualcosa che faccia da base (ma non occorre che sia un import) per poi essere integrato con i sopralluoghi. Anche le coastline del PGS facevano schifo ma stanno venendo migliorate con i contributi successivi. Stefano Il giorno 12 settembre 2011 14:57, Simone Saviolo simone.savi...@gmail.comha scritto: Il giorno 12 settembre 2011 14:46, G Zamboni gd.zamb...@tiscali.it ha scritto: Il 12/09/2011 12:56, Martin Koppenhoefer ha scritto: PS Piuttosto cerchiamo qualche servizio che ci possa concedere l'uso dei nomi delle vie per copiarle, Tuttocittà o simili. -1, vorrei avere i dati buoni in OSM, quelli giusti. Se copiamo gli errori da altri non vedo il senso. Non mi ricordo se se ne era già parlato, ma i piani regolatori dei vari comuni non possono essere intesi come documenti ufficiali e quindi di pubblico dominio? In questo caso sarebbero molto più affidabili di tante altre fonti... Credo di poter dissentire. Conosco almeno tre casi solo a Vercelli in cui il piano regolatore è stato disatteso (progettato in un modo, si è fatto in un altro), senza contare le strade che hanno cambiato nome. Non metterei affatto la mano sul fuoco sul fatto che *oggi* il piano regolatore rifletta la reale situazione. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
ho visto che qualcuno ha usato name=Strada da denominare è una buona idea? Un problema dei vari tag proposti noname, unnamed, ecc. è l'ambiguità: il nome non esiste, non è scritto su un cartello, ecc. per evitare l'ambiguità si può descrivere la situazione delle note in italiano. ___ -1 Tautologico: aggiungiamo un'informazione per dire 'manca un'informazione' quando basta la mancanza del tag 'name' per capire che non ha nome; ancora peggio: un bot che verificasse la mancanza del tag 'name' in questo caso fallirebbe. Nei rari casi in cui la stada è senza nome lo segnalerei nel tag 'note' o al limite in 'description' Alessandro Ale_Zena_IT ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Il giorno lun, 12/09/2011 alle 14.46 +0200, G Zamboni ha scritto: Il 12/09/2011 12:56, Martin Koppenhoefer ha scritto: PS Piuttosto cerchiamo qualche servizio che ci possa concedere l'uso dei nomi delle vie per copiarle, Tuttocittà o simili. -1, vorrei avere i dati buoni in OSM, quelli giusti. Se copiamo gli errori da altri non vedo il senso. Non mi ricordo se se ne era già parlato, ma i piani regolatori dei vari comuni non possono essere intesi come documenti ufficiali e quindi di pubblico dominio? In questo caso sarebbero molto più affidabili di tante altre fonti... Posso confermarti che i piani regolatori NON sono documenti affidabili. Personalmente preferisco l'approccio classico: vai li e controlli, se non sei convinto/sicuro vedi di informarti e per il momento non metti niente. -- Ciao Gio. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
Il 12/09/2011 14:57, Simone Saviolo ha scritto: Il giorno 12 settembre 2011 14:46, G Zamboni gd.zamb...@tiscali.it ha scritto: Il 12/09/2011 12:56, Martin Koppenhoefer ha scritto: PS Piuttosto cerchiamo qualche servizio che ci possa concedere l'uso dei nomi delle vie per copiarle, Tuttocitt o simili. -1, vorrei avere i dati buoni in OSM, quelli giusti. Se copiamo gli errori da altri non vedo il senso. Non mi ricordo se se ne era gi parlato, ma i piani regolatori dei vari comuni non possono essere intesi come documenti ufficiali e quindi di pubblico dominio? In questo caso sarebbero molto pi affidabili di tante altre fonti... Credo di poter dissentire. Conosco almeno tre casi solo a Vercelli in cui il piano regolatore stato disatteso (progettato in un modo, si fatto in un altro), senza contare le strade che hanno cambiato nome. Non metterei affatto la mano sul fuoco sul fatto che *oggi* il piano regolatore rifletta la reale situazione. Sono d'accordo con te, ma non credo che nessuno possa mettere la mano sul fuoco in merito all'attendibilit di dati cartografici, qualunque sia la fonte. Ammesso e non concesso che si possano utilizzare i PRG (per questioni legali) io li intendo come una fonte relativamente affidabile di dati (nomi di vie, utilizzo del terreno) che va ovviamente integrata con altro, (conoscenza diretta, altre fonti, ecc...). Tutto sta, come sempre, a come il mappatore utilizza le fonti e per brevit evito di ripetere questa premessa ogni volta che scrivo sul talk ;-) Se uno o pochi errori invalidano l'affidabilit di tutta la fonte allora bisognerebbe gettare al macero PCN, Bing, dati della regione Veneto, ISTAT e molto altro. Sta a noi prendere ci che valido e scartare o meglio correggere ci che non lo . Ciao, Simone Ciao Giuliano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento elenco user-highways
Il 11/09/2011 23:51, Daniele Forsi ha scritto: che senso ha inserire delle residential senza dargli un nome? Per definizione le residential servono per andare a casa di qualcuno e come fai se non sai il nome della via? Intendiamoci ne ho anche io qualcuna da completare... Appunto, può essere una mappatura parziale: dopotutto è molto comodo aggiungere strade basandosi sulle ortofoto, ed è un lavoro che può essere utile per chi fa rilievi sul posto, ad esempio stampando la cartina con walkingpapers. -- Giacomo Boschi http://gwilbor.wordpress.com/ -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Dal 10 al 23 Settembre euro 55 per persona al giorno all'Hotel Ascot Riccione, bambino gratis fino a 5 anni in camera con due adulti Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11793d=12-9 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade senza nome (era Re: Aggiornamento elenco user-highways)
2011/9/12 sabas88 saba...@gmail.com: Si sta parlando (per quanto ho detto io perlomeno) di trovare qualcosa che faccia da base (ma non occorre che sia un import) per poi essere integrato con i sopralluoghi. Anche le coastline del PGS facevano schifo ma stanno venendo migliorate con i contributi successivi. Per fare controlli per poi dare sopraluoghi si possono usare tutti fonti del mondo. Per copiare dati in OSM l'unica affidabile è la connoscenza del territorio. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Linee amministravive mappe o s m
Grazie per le info. Non mi è chiara una cosa. Se con il mio tele o con un gps riesco a registrare un sentiero nuovo, posso farlo acquisire da osm semplicemente collegandomi al sito, senza editarlo con josm ? Perché il sentiero E1 che è importante, sulle mappe osm, è privo dell'indicazione E1? SAREBBE utile distinguerlo dagli altri. Grazie a tutti. Perdono. Il giorno 09/set/2011 13:20, groppo otto grop...@gmail.com ha scritto: Il 08 settembre 2011 23:18, giovanni di lorenzo giovannidilorenzo1...@gmail.com ha scritto: Grazie per il consiglio. Vorrei chiedere alcune cose. Per inviare delle tracce registrate su osm... Come dice la guida segnalata da sabas88, puoi caricare le tracce gps dal sito di OpenStreetMap. Cliccando su Tracciati GPS -- Carica un tracciato. Però, i dati di OSM (strade, punti d'interesse...) devono essere disegnati a mano, con un programma di editing, usando le tracce gps solo come riferimento, come base da cui ricalcare. Non ho esperienza con Android, ma nel Wiki sono segnalati questi editor: http://wiki.openstreetmap.org/wiki/Android#OpenStreetMap_editing_features Ciao, Groppo ___ Talk-it mailing list Talk-it@openstre... ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Linee amministravive mappe o s m
2011/9/12 giovanni di lorenzo giovannidilorenzo1...@gmail.com: Perché il sentiero E1 che è importante, sulle mappe osm, è privo dell'indicazione E1? SAREBBE utile distinguerlo dagli altri. Grazie a tutti. Perdono. A che tratto ti riferisci? http://hiking.lonvia.de/it/?zoom=10lat=45.67666lon=8.77658 I tratti che mancano non sono ancora stati mappati... Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Linee amministravive mappe o s m
Il 12/09/2011 22:55, giovanni di lorenzo ha scritto: Grazie per le info. Non mi è chiara una cosa. Se con il mio tele o con un gps riesco a registrare un sentiero nuovo, posso farlo acquisire da osm semplicemente collegandomi al sito, senza editarlo con josm ? Perché il sentiero E1 che è importante, sulle mappe osm, è privo dell'indicazione E1? SAREBBE utile distinguerlo dagli altri. Grazie a tutti. Perdono. Sembrerebbe che ci sia un malinteso di fondo. Quando registri un sentiero con un gps crei un file gpx che puoi caricare direttamente sul server di OSM. Questo però non vuol dire che hai caricato un sentiero nel database. Hai solo messo a disposizione una traccia che andrà ricalcata con JOSM o Potlatch. Finchè non ricalchi e carichi nel database non vedrai mai niente. In fase di ricalco gli aggiungerai tutti i tag appropriati. Ciao Giuliano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] OSMIT2011: stato delle regioni
Allora mancano all'appello ancora tante regione che hanno molti user e di cui mi aspetto una presentazione almeno ci sono queste: - Lombardia - Veneto - Emilia Romagna - Liguria - Toscana - Lazio Poi se venisse qualche pugliese e qualche siciliano Ovviamente quelle non citate non è che le denigro solo che hanno un po' meno utenti e perciò meno possibilità di partecipare PS Sabato ci sarà una gradita sorpresa (almeno spero che anche voi la penserete così) perciò non mancate! -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Tunja, origen de datos
Correcto. Cuando de verificacio'n de/en campo se trata, hay que tener en cuenta que de la jerarquia de fuentes de datos geograficos, lo que se verifica in situ, ya sea por observacio'n directa y hacer anotaciones como en el caso de los walking papers de lo que se encuentre en dicho sitio, y asociarlo a los registros obtenidos por medio del gps como los .gpx, estos son los de mayor valor de confiabilidad en terminos de metadatos. O el WalkingPaper o el gpx o una combinacion de los dos son un excelente origen o fuente de la informacion geografica. Date: Sun, 11 Sep 2011 20:08:44 -0500 From: hyan...@gmail.com To: talk-co@openstreetmap.org Subject: Re: [Talk-co] Tunja, origen de datos Verificación de capo es... WalkingPaper, .gpx? El 11 de septiembre de 2011 18:13, Bennet Campoverde benets...@hotmail.com escribió: Tengo entendido que esos datos se obtuvieron a partir de verificación de campo in situ. From: harrie...@hotmail.com To: talk-co@openstreetmap.org Date: Sun, 11 Sep 2011 12:42:39 -0500 Subject: Re: [Talk-co] Tunja, origen de datos Siempre he deseado saber cual es el origen de los datos que coloca Penelope 86. From: harrie...@hotmail.com To: talk-co@openstreetmap.org Date: Sun, 11 Sep 2011 12:39:56 -0500 Subject: [Talk-co] Tunja, origen de datos Cual es el origen de los ultimos datos que se colocaron en Tunja?? ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-dk] Sletning af kommunegrænser fra DAGI
On 06-09-2011 21:58, Jonas Häggqvist wrote: Pt. eksisterer i databasen en række kommunegrænser på Sjælland importeret fra DAGI. Disse imports blev foretaget under brugerkontoen OpenSOVS. Jeg foreslår at vi sletter dem, af følgende grunde (i rækkefølge fra mest til mindst vigtigt): De er nu væk. Processen har af en eller anden grund efterladt nogle løse punkter uden noget tilhørsforhold som jeg lige skal se om ikke jeg kan få ryddet op i. I processen måtte jeg føre Saltholm tilbage til den gamle kystlinie da den nuværende brugte kommunegrænsen. Så der er lige noget arbejde der skal gøres - det skal siges at øen er dækket af Bing, så det skulle kunne lade sig gøre at få en flot kystlinie igen. Der var også et par andre kyststrækninger (ved hhv. Næstved og Helsingør) som også var brugte kommunegrænse-data, men dem har jeg retracet på fornuftig vis efter Bing/Fugro. -- Jonas Häggqvist rasher(at)rasher(dot)dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-es] Presentación
Bienvenido! 2011/9/11 Jordi Duran jordu...@gmail.com: Hola, mi nombre es Jordi Duran y éste es mi primer mensaje para presentarme. Estoy leyendo para enterarme de como funciona todo ésto y mapear alguna cosa Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Victor mailto:xen...@gmail.com ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Importación NGMEP
Hola, El 10 de septiembre de 2011 01:43, Javier Sánchez javiers...@gmail.comescribió: * Comprobar si la población ya existe en OSM (se han filtrado pero puede haber escapado alguna), bien en forma de un nodo con etiqueta place=* o un área con etiquetas place=* o landuse=residential. Si ya existe, descartar el nodo de la importación borrándolo. Antes se puede copiar las etiquetas que interesen al nodo existente. estoy realizando la importación de los municipios de Huelva y me encuentro casos como este [1]. En OSM ya existe un área con landuse=residential marcando el casco urbano pero no tiene ninguna otra etiqueta como pueda ser el nombre. En casos como estos, ¿debo copiar las etiquetas del nodo al área y borrar el nodo? En caso afirmativo ¿cuales son las etiquetas que debería copiar? [1] http://www.openstreetmap.org/?lat=37.73982lon=-7.34157zoom=16layers=M Un saludo, Juan Luis. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Importación NGMEP
El 12/09/11, Juan Luis Rodriguez jlrodrig...@emergya.es escribió: estoy realizando la importación de los municipios de Huelva y me encuentro casos como este [1]. En OSM ya existe un área con landuse=residential marcando el casco urbano pero no tiene ninguna otra etiqueta como pueda ser el nombre. En casos como estos, ¿debo copiar las etiquetas del nodo al área y borrar el nodo? En caso afirmativo ¿cuales son las etiquetas que debería copiar?. Hola. Lo suyo es borrar el nodo (no tiene sentido duplicar la información) y las etiquetas a copiar serían todas las que el área no tenga. Para el caso de que la población en vez de área venga representada como un nodo, la forma de actuar sería la misma, dejando el nodo existente y copiándole las etiquetas de la importación. Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Importación NGMEP
El día 12 de septiembre de 2011 20:15, Matías Taborda Barroso taborda.barr...@gmail.com escribió: El 12/09/11, Juan Luis Rodriguez jlrodrig...@emergya.es escribió: estoy realizando la importación de los municipios de Huelva y me encuentro casos como este [1]. En OSM ya existe un área con landuse=residential marcando el casco urbano pero no tiene ninguna otra etiqueta como pueda ser el nombre. En casos como estos, ¿debo copiar las etiquetas del nodo al área y borrar el nodo? En caso afirmativo ¿cuales son las etiquetas que debería copiar?. Hola. Lo suyo es borrar el nodo (no tiene sentido duplicar la información) y las etiquetas a copiar serían todas las que el área no tenga. Hola. Es lo que estuvimos comentando en otro hilo hace unos días. Yo no borraría el nodo, por que es bueno relacionar los nodos de las capitales como centro administrativo de su término municipal. Es decir, añadirlo a la relación boundary de la frontera del municipio con el papel admin_centre. Si alguien no sabe como hacerlo que lo diga, para preparar un tutorial. En el área, pondría las etiquetas place=*, place_name=loquesea y no usar name. De esa forma el área queda relacionada con el nodo y no se repiten los nombres en el mapa. Para el caso de que la población en vez de área venga representada como un nodo, la forma de actuar sería la misma, dejando el nodo existente y copiándole las etiquetas de la importación. Saludos. Ok. Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-ee] Maakaart.ee lehel oleva kaardi andmebaasi uuendamine
11.09.2011 20:36, Jaak Laineste (Nutiteq) kirjutas: Ma toon SOTM-ilt mitmeid uusi ideid, kuidas importimist ja renderdust parandada, nii et saab tehtud. Üldiselt: - teha uuendusi näiteks korra nädalas kasutades imposm-i, mis peaks planeedi alla 24 tunniga sisse lugema, - imposm andmestruktuur kannatab kiiremat renderust ka madalatel zoomidel. Viimane on WMS/Eesti projektsiooni jaoks vajalik. - selle probleem on et vaikimisi mapniku xml sellega ei toimi, vajab eraldi kujundust, sest baasi/tabelite struktuur on teine. - live tileserver kasutab trunk-mapnikut, sest seal on tehtud olulisi renderduse kiiruseparandusi mida pole veel releasetud - http://mapproxy.org/ peaks panema WMS cachema et teha seda kasutatavalt kiireks. Seda kõike on jube tore kuulda, tõsiselt. See tähendab seda, et ka kujunduste osas saab edasi minna. http://svn.openstreetmap.org/applications/rendering/mapnik-german/ on sakslaste enese (www.openstreetmap.de) tarbeks tehtud kaardistiil. Üks tõsisem ajurünnak kujunduse osas oleks ilmselt vajalik. Nii näiteks ei renderdata ei Mapniku ega Osmarenderi abil torujuhtmeid, meil aga on metsades gaasijuhtmeid küll, mis tegelikult ka renderdatud võiksid olla. Kuna gaasijuhtmete ümber on tühjaks raiutud sihid, oleks täpsemate metsade puhul täitsa abiks näidata, mis selle sihi raiumise põhjuseks on olnud. - M - ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-ee] Maakaart.ee lehel oleva kaardi andmebaasi uuendamine
Osmarender renderdab vähemalt selliseid torujuhtmeid mille sisuks on määratud vesi: http://www.openstreetmap.org/?lat=59.23209lon=24.31805zoom=17layers=O Kuigi arutelu kaardistiili üle ei teeks paha, kuna Eestis leidub tõesti asju, mida mujal maailmas praktiliselt polegi nt. lauluväljakud. Mihkel 2011/9/12 Margus Värton mar...@dakar.ee 11.09.2011 20:36, Jaak Laineste (Nutiteq) kirjutas: Ma toon SOTM-ilt mitmeid uusi ideid, kuidas importimist ja renderdust parandada, nii et saab tehtud. Üldiselt: - teha uuendusi näiteks korra nädalas kasutades imposm-i, mis peaks planeedi alla 24 tunniga sisse lugema, - imposm andmestruktuur kannatab kiiremat renderust ka madalatel zoomidel. Viimane on WMS/Eesti projektsiooni jaoks vajalik. - selle probleem on et vaikimisi mapniku xml sellega ei toimi, vajab eraldi kujundust, sest baasi/tabelite struktuur on teine. - live tileserver kasutab trunk-mapnikut, sest seal on tehtud olulisi renderduse kiiruseparandusi mida pole veel releasetud - http://mapproxy.org/ peaks panema WMS cachema et teha seda kasutatavalt kiireks. Seda kõike on jube tore kuulda, tõsiselt. See tähendab seda, et ka kujunduste osas saab edasi minna. http://svn.openstreetmap.org/** applications/rendering/mapnik-**german/http://svn.openstreetmap.org/applications/rendering/mapnik-german/on sakslaste enese ( www.openstreetmap.de) tarbeks tehtud kaardistiil. Üks tõsisem ajurünnak kujunduse osas oleks ilmselt vajalik. Nii näiteks ei renderdata ei Mapniku ega Osmarenderi abil torujuhtmeid, meil aga on metsades gaasijuhtmeid küll, mis tegelikult ka renderdatud võiksid olla. Kuna gaasijuhtmete ümber on tühjaks raiutud sihid, oleks täpsemate metsade puhul täitsa abiks näidata, mis selle sihi raiumise põhjuseks on olnud. - M - __**_ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-eehttp://lists.openstreetmap.org/listinfo/talk-ee ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-ee] Maakaart.ee lehel oleva kaardi andmebaasi uuendamine
Tundub et parim kujunduse muutja oleks tilemill. Probleem on sellel et ta kasutab oma kujundusdefinitsiooni, ja konverdib selle mapniku omasse alles pärast modimise valmis saamist. Seega parimad vabalt saadaval valmiskujundused (default mapnik, openstreetmap.de või mapquest-i oma) sinna ei sobi. Samuti ei ole valmiskujundust imposm andmebaasi jaoks. Parim mis võtta on FOSS4G testi jaoks tehtud enamvähem default-mapnik saranane kujundus ( https://github.com/mapbox/foss4g-benchmark-style), sealt on aga väidetavalt ühtteist puudu (puud, elektriliinid näiteks). Igal juhul tuleb kujundust meie vajaduste jaoks tuunida. Jaak On 11.09.2011, at 11:36, Jaak Laineste (Nutiteq) wrote: Ma toon SOTM-ilt mitmeid uusi ideid, kuidas importimist ja renderdust parandada, nii et saab tehtud. Üldiselt: - teha uuendusi näiteks korra nädalas kasutades imposm-i, mis peaks planeedi alla 24 tunniga sisse lugema, - imposm andmestruktuur kannatab kiiremat renderust ka madalatel zoomidel. Viimane on WMS/Eesti projektsiooni jaoks vajalik. - selle probleem on et vaikimisi mapniku xml sellega ei toimi, vajab eraldi kujundust, sest baasi/tabelite struktuur on teine. - live tileserver kasutab trunk-mapnikut, sest seal on tehtud olulisi renderduse kiiruseparandusi mida pole veel releasetud - http://mapproxy.org/ peaks panema WMS cachema et teha seda kasutatavalt kiireks. ps. kujunduste modimiseks võiks http://tilemill.com/pages/index.html installida livemasinasse. Jaak Kuupäeval 11. september 2011 11:44 kirjutas Margus Värton mar...@dakar.ee: Hoi, http://kaart.maakaart.ee/map.html asub meie enda renderdatud kaart. Kas keegi oskab mulle öelda, kui sageli selle aluseks olevat andmebaasi uuendatakse? Tundub, et viimatine muutus on nädalaid, kui mitte kuid vana. Nii et kui kellegi võimuses on uus andmebaasiimport käivitada, siis palun tehtagu seda. Tänud, - M - ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee -- Jaak Laineste ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-at] Redundantes mapping zerstört routing und renderer!
On 11.09.11 18:35, adry wrote: ich habe bemerkt, dass seit einiger Zeit in Wien im Bereich zwischen/um die TU und Naschmarkt Gehsteige als footway gemapped wurden. Das war eine Einzelaktion von Darafei (OSM user Komяpa) anläßlich seines Besuchs der SOTM-EU. Wir sind uns eigentlich einig, dass das /so/ nicht sinnvoll ist. IMO sollte man sie nicht umtaggen, sondern wenn, wieder löschen und durch die (dort meist eh vorhandenen) Radstreifen/Radweg-Tags ersetzen. Grade in der Margaretenstraße gibt's einen Radweg auf dem Gehsteig, der schon immer als eigener Way gezeichnet war, den sollte man (als cycleway) belassen, der funktioniert auch renderingtechnisch. Und wenn's mal einen Gehsteig-Tag gibt, den verwenden, wobei das insgesamt relativ sinnlos ist, weil in Wien fast jede Straße Gehsteige hat. Das ganze fällt unter das übliche Problem, das man halt wie üblich mit Augenmaß lösen muss: man muß den Routing-Graphen im Auge behalten und das Flächen-mapping (ggf. bis hin zum Micro-Mapping), aber beides muß halt funktionieren. Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] See-Grenze, Knotenlimit
Hallo! Kannst Du bitte den Antworten Knopf benützen? Und wenn Du so einen dummen MUA verwendest, der kein In-Reply-To/References kann, dann verwende bitte einen anderen Mailer*)... Deine Beiträge sind ständig neue Threads, was es ziemlich mühsam macht, den Gedanken zu folgen... Danke! Servus, Andreas *) ML-Mails über einen Exchange-Server zu lesen ist sowieso irgendwie keine gute Idee... ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] LUGT/OSM-Stammtisch Innsbruck am 15. September 2011
Servus! Wir möchten zum nächsten gemeinsamen LUGT-/OSM-Stammtisch einladen: am Donnerstag, 15. September 2011 um 19:00 Uhr im Restaurant Kastanie Innsbrucker Straße 4, 6176 Völs Wir freuen uns auf ein zahlreiches Erscheinen! Grüße Simon Legner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] See-Grenze, Knotenlimit
Ist so eine gute Idee. Nur wenn du dann fertig bist würd ich die Relation wieder löschen. Außer es sind dann wirklich massenhaft Punkte vorhanden. Am 12. September 2011 22:47 schrieb Johannes Sixt j...@kdbg.org: Am 12.09.2011 08:09, schrieb Andreas Labres: On 11.09.11 22:39, Johannes Sixt wrote: Ich möchte demnächst die See-Grenze vom Attersee etwas genauer einzeichen (zumindest da und dort), weil die derzeit vielerorts einige Dutzend Meter daneben liegt (laut Geoimage.at). Insbesonders würde ich da doch eine Menge neuer Knoten einfügen. Gute Idee. :) Nun gibt es aber meines Wissens ein Limit von 2000 Knoten pro Way. Kein Limit, nur eine Empfehlung. Du kannst irgendwann überlegen, eine Multipolygon-Relation zu machen, aber damit würde ich mir Zeit lassen. Ok, danke für die Einschätzung. Aus folgendem Grund würde ich dennoch gleich eine Multipolygon-Relation machen: Derzeit ist der Attersee-Way mit source=SWDB;landsat getaggt. Ich würde dann meine Arbeit mit source=geoimage taggen, und den unbearbeiteten Rest mit dem ursprünglichen source Tag belassen. Die übrigen Tags (name, natural, etc.) würden natürlich in die Relation wandern. Spricht da was dagegen? -- Hannes ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at -- mfg Soldier Boy ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] See-Grenze, Knotenlimit
On 12.09.2011 22:47, Johannes Sixt wrote: Aus folgendem Grund würde ich dennoch gleich eine Multipolygon-Relation machen: Derzeit ist der Attersee-Way mit source=SWDB;landsat getaggt. Ich würde dann meine Arbeit mit source=geoimage taggen, und den unbearbeiteten Rest mit dem ursprünglichen source Tag belassen. Die übrigen Tags (name, natural, etc.) würden natürlich in die Relation wandern. Spricht da was dagegen? Inhaltlich nicht. Ist der Attersee wirklich zu groß um ihn in einem Rutsch zu mappen/verfeinern? Nur so ein Gedanke.. LG, Stefan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-ca] What should a Canadian style map look like?
Dear All, Just brain-storming, so let's have suggestions without debate for now. What should the OSM data look like when styled for Canadians? Just some quick ideas that appeal to me: - highway marker shields like 401, highway of heroes, Yellowhead, etc. - fewer road colors. - render cues about road surface so I can tell gravel roads. - make long-distance roads in the north render somehow. What else? Big ideas, small ideas? Which points of interest should be more prominent? Hockey and curling rinks? Trim this post and reply with your ideas. There is a similar thread starting on the talk-us list as well. Perhaps we can all play together on our continent. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] What should a Canadian style map look like?
I think passenger railways like VIA rail, GO, AMT, etc should be rendered prominently. Most of the web maps are too auto-centric. How about the Trans Canada trail, National vs Provincial parks? I'm not a fan of roads rendered in green. Matthew Buchanan On 2011-09-12, at 3:32 PM, Richard Weait rich...@weait.com wrote: Dear All, Just brain-storming, so let's have suggestions without debate for now. What should the OSM data look like when styled for Canadians? Just some quick ideas that appeal to me: - highway marker shields like 401, highway of heroes, Yellowhead, etc. - fewer road colors. - render cues about road surface so I can tell gravel roads. - make long-distance roads in the north render somehow. What else? Big ideas, small ideas? Which points of interest should be more prominent? Hockey and curling rinks? Trim this post and reply with your ideas. There is a similar thread starting on the talk-us list as well. Perhaps we can all play together on our continent. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] What should a Canadian style map look like?
I agree with most of these suggestions. OSM should render in a manner familiar to Canadian map readers. Road colours should be limited to indicate primary/trunk and secondary/county roads (in practice, that should probably mean no distinction between highway=primary and highway=trunk -- like Matthew, I don't think green works well, especially in a heavily forested country). Road surface should be indicated. Add to that another: toll highways, which are usually indicated on North American maps. The question of long-distance northern roads is a question of information density. At low zooms, the Canadian map can seem pretty empty if we follow rules appropriate to higher density countries (Guten Tag, Deutschland). Is there a way of changing the rendering threshold for, say, towns so that empty parts of the map would have smaller centres rendered? Generally speaking, I find too much of interest disappears when you zoom out. Points of interest (historic, tourism) only really appear at the highest zoom levels, and that's less useful in places where the point of interest is outside the nearest town (e.g., the Royal Tyrrell Museum). As for rendering things like railways and trails, that hinges on the question of what the map is used for -- i.e., why people are using the map. No one map can cover everything at once: a road map makes a lousy cycling map, and so on. That's where layers come in. But it'll be hard to figure out what information is important without some idea of why people are using the map -- we're still in building mode at this point, I think, so the answer is still to come. -- Jonathan Crowe http://www.jonathancrowe.net ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-cz] administrativní hranice
Ahoj, právě kontroluju administrativní hranice - jak se dalo čekat, sem tam něco se rozbilo v průběhu času... ale to se snad snadno opraví. Ale při prohlídce mě zarazila jedna věc - spousta obcí (admin_level=8) má nesouvislá území - skutečně to tak je? Odkud se tahle data brala? Petr Morávek aka Xificurk attachment: xificurk.vcf signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] administrativní hranice
Ahoj, kompletní seznam obcí s nesouvislým územím je tady (je jich přes 90) http://cs.wikipedia.org/wiki/Wikipedista:JAn_Dudík/work2 JD Dne 12. září 2011 21:57 Petr Morávek [Xificurk] xific...@gmail.com napsal(a): Ahoj, právě kontroluju administrativní hranice - jak se dalo čekat, sem tam něco se rozbilo v průběhu času... ale to se snad snadno opraví. Ale při prohlídce mě zarazila jedna věc - spousta obcí (admin_level=8) má nesouvislá území - skutečně to tak je? Odkud se tahle data brala? Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- -- Ing. Jan Dudík ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] administrativní hranice
Ahoj, On Mon 12-09-11 21:57:10, Petr Morávek [Xificurk] wrote: právě kontroluju administrativní hranice - jak se dalo čekat, sem tam něco se rozbilo v průběhu času... ale to se snad snadno opraví. Tady ještě stojí za zmínku, že průběh hranic místy neodpovídá současnému stavu z WMS CUZK. Hranice jsou příliš generalizované, což občas vadí při importu adresních bodů. Ale při prohlídce mě zarazila jedna věc - spousta obcí (admin_level=8) má nesouvislá území - skutečně to tak je? Odkud se tahle data brala? Nesouvislá území? Mohu příklad? Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] administrativní hranice
Dne 12.9.2011 21:57, Petr Morávek [Xificurk] napsal(a): Ahoj, práve( kontroluju administrativní hranice - jak se dalo c(ekat, sem tam ne(co se rozbilo v pru*be(hu c(asu... ale to se snad snadno opraví. Ale pr(i prohlídce me( zarazila jedna ve(c - spousta obcí (admin_level=8) má nesouvislá území - skutec(ne( to tak je? Odkud se tahle data brala? Cus, data vlastnich hranic jsou import z prehledky, co je horsi (a nevim jak moc to jeste zustalo) ze nektery uzemi byly spatne zarazeny do struktury (rodic - potomek) takze sem napr narazel na uzemi nejen mimo dany okres, ale i kraj ..., u vetsich admin lv se to blbe vyhodnocuje, protoze jen to stazeni trva minuty a prakticky se stim pak neda v josm operovat. Pokud nesouvislym uzemim myslis nekolik uzavrenych polygonu, tak to muze byt. Technicky by to melo pak jeste obsahovat stejny uzemi jako potomky lv 10. BTW: Nebylo by od veci neco jako zamek na nektery data = pri pokusu o hejbani snima by to aspon 3x rvalo estli opravdu zrovna tohle menit. Protoze trebas prave ty hranice spravuju taky celkem pravidelne a obcas nechapu, jak se neco takovyho mohlo nekomu povist (napr vyhazet hranicni cary z prislusnych relaci mi neprijde jako omyl/nahoda). Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk-fr] [blog] Recette pour du Web Mapping (en anglais)
Bonjour, La recette de Jason Sanford pour la construction du plan pour le FOSS4G 2011. Outils: PostGis, TileMill, Carto, TileStream, Leaflet, MapFish http://geojason.info/2011/the-2011-foss4g-map/ -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ceci n'est pas un spam
Le Vendredi 9 Septembre 2011 22:39:48 Vincent Pottier, vous avez écrit : http://osm.org/go/0CU5hXxZa- Vraiment. J'vous jure ! J'en ai un du même genre par chez moi (pas loin du CRAIG d'ailleurs ;-) ), mais ils changent régulièrement le parcours (il est différent entre les vues du CRAIG et Bing par exemple). C'est là http://sautter.com/map/?zoom=17lat=45.7781lon=3.18303layers=00BT -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Besoin de traffic (testeurs wanted!)
Le Samedi 10 Septembre 2011 10:35:27 yvecai, vous avez écrit : On 08. 09. 11 11:16, Nicolas Dumoulin wrote: J'ai testé le routage, sympa, mais : - Je n'ai pas compris comment juste sélectionner une piste pour avoir les infos, ça m'ajoute tout de suite un point. Tu pourrais peut-être charger le détail de la piste lors du survol (en laissant la piste sélectionnée après le survol) … Bon, j'y croyais pas trop à cette histoire de survol: c'était un coup à avoir une petite fenêtre clignotante quand tu n'arrives pas à sélectionner la piste. Mais avec une petite tempo avant de fermer la fenêtre, c'est pas mal: http://dev-yves.dyndns.org/alpha/pistes-nordiques-backend/ Ha oui, c'est pas mal :-) Le positionnement des boîtes a changé chez moi. La boîte « parcours » est passée de droite à gauche. Ça ne serait pas mieux de grouper tout dans un bandeau vertical à gauche ou à droite, ou bien d'utiliser des boîtes flottantes repositionnables ? Beau travail en tout cas ! -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [blog] Recette pour du Web Mapping (en anglais)
Bonjour, Sans oublier les tuiles de fond de plan, qui proviennent de Mapquest Le 12 septembre 2011 09:07, cyrille giquello cyrill...@gmail.com a écrit : Bonjour, La recette de Jason Sanford pour la construction du plan pour le FOSS4G 2011. Outils: PostGis, TileMill, Carto, TileStream, Leaflet, MapFish http://geojason.info/2011/the-2011-foss4g-map/ -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Besoin de traffic (testeurs wanted!)
Je préfére les fenêtres a un bandeau pour garder l'impression d'une carte plein écran. Les fenêtres repositionables, bonjour le boulot pour que ca marche sur tout les browsers ... Pour les longues doutées d' hivers peut être :) -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le Samedi 10 Septembre 2011 10:35:27 yvecai, vous avez écrit : On 08. 09. 11 11:16, Nicolas Dumoulin wrote: J'ai testé le routage, sympa, mais : - Je n'ai pas compris comment juste sélectionner une piste pour avoir les infos, ça m'ajoute tout de suite un point. Tu pourrais peut-être charger le détail de la piste lors du survol (en laissant la piste sélectionnée après le survol) … Bon, j'y croyais pas trop à cette histoire de survol: c'était un coup à avoir une petite fenêtre clignotante quand tu n'arrives pas à sélectionner la piste. Mais avec une petite tempo avant de fermer la fenêtre, c'est pas mal: http://dev-yves.dyndns.org/alpha/pistes-nordiques-backend/ Ha oui, c'est pas mal :-) Le positionnement des boîtes a changé chez moi. La boîte « parcours » est passée de droite à gauche. Ça ne serait pas mieux de grouper tout dans un bandeau vertical à gauche ou à droite, ou bien d'utiliser des boîtes flottantes repositionnables ? Beau travail en tout cas ! -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin _ 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] État du suivi des autoroutes
Le 1 septembre 2010 21:55, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Bonjour, Tout d'abord, merci à tous les osmoseurs qui ont mis la main à la patte pour remplir toutes les relations nécessaires pour établir les comparaisons avec wikipedia/wikisara sur: http://jocelyn.alwaysdata.net/osm/suivi-autoroutes.html On a atteint maintenant 96% d'autoroutes correctement mises dans une relation, ce qui remarquable :) J'ai passé un revue les autoroutes non-cohérentes dans OSM, et il faudrait vérifier/compléter les suivantes: - l'A46 est découpée en 2, parce qu'il y a deux opérateurs differents. Mais je lis que le consensus sur un sujet de discussion récent était de grouper les relations en une seule, en perdant l'infe d'opérateur. À moins que j'ai mal suivi le fil ? - l'A65 (id 446265) est une autoroute récemment ouverte dans la Gascogne, entre Langon et Pau. - l'A88 (id 157702) est aussi une autoroute récente, entre Sées et Falaise (juste avant Caen) - l'A844 (id 1146944) est par contre bizarre, et je ne suis pas sur le terrain pour vérifier. On dirait que cette relation contient uniquement la nationale N844 au lieu de l'autoroute A844. Quelqu'un pour confirmer et/ou corriger ? - il reste des petites autoroutes, mais je n'ai pas vérifié si elles existaient sur OSM. Je viens également de rajouter sur cette même page le nombre de kilométres de way en oneway=yes, en oneway=no, ou oneway non renseigné. Le but est de calculer la distance plus précisément, en faisant: km_total = km_oneway=yes / 2 + km_oneway=no + km_oneway=null Avant que je passe à ce calcul, il faudrait vérifier que les autoroutes sont bien renseignée: on dirait qu'un certain nombre de oneway sont manquantes. Par ailleurs, est-ce que quelqu'un saurait où trouver le décompte de sorties ou d'aires par autoroutes ? (si on n'a pas de source claire, je peux tenter de récupérer l'info sur le wiki de OSM, où quelques autoroutes sont renseignées) C'est pour renseigner les pages suivantes: http://jocelyn.alwaysdata.net/osm/suivi-autoroutes-sorties.html http://jocelyn.alwaysdata.net/osm/suivi-autoroutes-aires.html Merci, Jocelyn PS: pour les parisiens qui cherchent quelque chose à faire, il est possible de compléter toutes les sorties du périphérique :) cf: http://jocelyn.alwaysdata.net/osm/suivi-autoroutes-sorties.html#A%2086 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Bonjour, Un après, je passe par là car j'ai découvert que l'A16 avait perdu sa relation (et pas moyen de regarder l'historique : http://www.openstreetmap.org/browse/relation/1140893/history) Et malheureusement la page de synthèse n'est plus rafraichie. Est-il possible de la remettre en route ? De mon côté j'ai eu aussi une synthèse des FR-A Road mais moins complète (pas de comparaison avec d'autres Wikis). Merci bien, -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Re: État du suivi des autoroutes
bonjour regarde par les analyseurs de relation: http://ra.osmsurround.org/analyzeRelation?relationId=1140893_noCache=on ou regarde par l'analyseur osmose : http://analyser.openstreetmap.fr l'historique d'un way ne faisant plus parti de la relation te donneras le groupe de modification a l'origine de cette cassure didier --mapeur amateur-- - Mail d'origine - De: Marc SIBERT m...@sibert.fr À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Mon, 12 Sep 2011 14:39:22 +0200 (CEST) Objet: Re: [OSM-talk-fr] État du suivi des autoroutes Le 1 septembre 2010 21:55, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Bonjour, Tout d'abord, merci à tous les osmoseurs qui ont mis la main à la patte pour remplir toutes les relations nécessaires pour établir les comparaisons avec wikipedia/wikisara sur: http://jocelyn.alwaysdata.net/osm/suivi-autoroutes.html On a atteint maintenant 96% d'autoroutes correctement mises dans une relation, ce qui remarquable :) J'ai passé un revue les autoroutes non-cohérentes dans OSM, et il faudrait vérifier/compléter les suivantes: - l'A46 est découpée en 2, parce qu'il y a deux opérateurs differents. Mais je lis que le consensus sur un sujet de discussion récent était de grouper les relations en une seule, en perdant l'infe d'opérateur. À moins que j'ai mal suivi le fil ? - l'A65 (id 446265) est une autoroute récemment ouverte dans la Gascogne, entre Langon et Pau. - l'A88 (id 157702) est aussi une autoroute récente, entre Sées et Falaise (juste avant Caen) - l'A844 (id 1146944) est par contre bizarre, et je ne suis pas sur le terrain pour vérifier. On dirait que cette relation contient uniquement la nationale N844 au lieu de l'autoroute A844. Quelqu'un pour confirmer et/ou corriger ? - il reste des petites autoroutes, mais je n'ai pas vérifié si elles existaient sur OSM. Je viens également de rajouter sur cette même page le nombre de kilométres de way en oneway=yes, en oneway=no, ou oneway non renseigné. Le but est de calculer la distance plus précisément, en faisant: km_total = km_oneway=yes / 2 + km_oneway=no + km_oneway=null Avant que je passe à ce calcul, il faudrait vérifier que les autoroutes sont bien renseignée: on dirait qu'un certain nombre de oneway sont manquantes. Par ailleurs, est-ce que quelqu'un saurait où trouver le décompte de sorties ou d'aires par autoroutes ? (si on n'a pas de source claire, je peux tenter de récupérer l'info sur le wiki de OSM, où quelques autoroutes sont renseignées) C'est pour renseigner les pages suivantes: http://jocelyn.alwaysdata.net/osm/suivi-autoroutes-sorties.html http://jocelyn.alwaysdata.net/osm/suivi-autoroutes-aires.html Merci, Jocelyn PS: pour les parisiens qui cherchent quelque chose à faire, il est possible de compléter toutes les sorties du périphérique :) cf: http://jocelyn.alwaysdata.net/osm/suivi-autoroutes-sorties.html#A%2086 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Bonjour, Un après, je passe par là car j'ai découvert que l'A16 avait perdu sa relation (et pas moyen de regarder l'historique : http://www.openstreetmap.org/browse/relation/1140893/history) Et malheureusement la page de synthèse n'est plus rafraichie. Est-il possible de la remettre en route ? De mon côté j'ai eu aussi une synthèse des FR-A Road mais moins complète (pas de comparaison avec d'autres Wikis). Merci bien, -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re: État du suivi des autoroutes
Bonjour, De : didier2...@free.fr bonjour regarde par les analyseurs de relation: http://ra.osmsurround.org/analyzeRelation?relationId=1140893_noCache=on ou regarde par l'analyseur osmose : http://analyser.openstreetmap.fr l'historique d'un way ne faisant plus parti de la relation te donneras le groupe de modification a l'origine de cette cassure didier --mapeur amateur-- Ça semble s'être joué entre les versions 14 (pleine, changeset 8743475) : http://www.openstreetmap.org/api/0.6/relation/1140893/14 et 15 (vide, changeset 9087732) http://www.openstreetmap.org/api/0.6/relation/1140893/15 vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] État du suivi des autoroutes
Bonjour, Le 12 septembre 2011, Marc SIBERT a écrit : Le 1 septembre 2010 21:55, Jocelyn Jaubert a écrit : Tout d'abord, merci à tous les osmoseurs qui ont mis la main à la patte pour remplir toutes les relations nécessaires pour établir les comparaisons avec wikipedia/wikisara sur: http://jocelyn.alwaysdata.net/osm/suivi-autoroutes.html Un après, je passe par là car j'ai découvert que l'A16 avait perdu sa relation (et pas moyen de regarder l'historique : http://www.openstreetmap.org/browse/relation/1140893/history) Et malheureusement la page de synthèse n'est plus rafraichie. Est-il possible de la remettre en route ? De mon côté j'ai eu aussi une synthèse des FR-A Road mais moins complète (pas de comparaison avec d'autres Wikis). J'avais mis à jour la page sur un autre serveur qui hébergeait une base osmosis à jour de la France, mais le serveur est tombé récemment :( Je ne peux donc pas te donner des résultats à jour pour le suivi des routes. Au cas où, les scripts sont disponibles là: https://github.com/jocelynj/osm/tree/fb5d414618efdfe3e2b8ec9806a92035b476f4a9/autoroutes Il y a normalement de quoi récupérer les longueurs sur Wikipédia - avec quelques modifications personnelles, et générer les pages html de comparaison des résultats. -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] État du suivi des autoroutes
Le 12 septembre 2011 19:07, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Bonjour, Le 12 septembre 2011, Marc SIBERT a écrit : Le 1 septembre 2010 21:55, Jocelyn Jaubert a écrit : Tout d'abord, merci à tous les osmoseurs qui ont mis la main à la patte pour remplir toutes les relations nécessaires pour établir les comparaisons avec wikipedia/wikisara sur: http://jocelyn.alwaysdata.net/osm/suivi-autoroutes.html Un après, je passe par là car j'ai découvert que l'A16 avait perdu sa relation (et pas moyen de regarder l'historique : http://www.openstreetmap.org/browse/relation/1140893/history) Et malheureusement la page de synthèse n'est plus rafraichie. Est-il possible de la remettre en route ? De mon côté j'ai eu aussi une synthèse des FR-A Road mais moins complète (pas de comparaison avec d'autres Wikis). J'avais mis à jour la page sur un autre serveur qui hébergeait une base osmosis à jour de la France, mais le serveur est tombé récemment :( Je ne peux donc pas te donner des résultats à jour pour le suivi des routes. Au cas où, les scripts sont disponibles là: https://github.com/jocelynj/osm/tree/fb5d414618efdfe3e2b8ec9806a92035b476f4a9/autoroutes Il y a normalement de quoi récupérer les longueurs sur Wikipédia - avec quelques modifications personnelles, et générer les pages html de comparaison des résultats. -- Jocelyn Bonjour, J'ai retrouvé mon propre fichier : http://freeroute.fr/libosm/roads.htm que je mets à jour à l'insu de moi-même... Effectivement l'A16 n'a plus de longueur. Je regarde ton code ce soir pour voir si je sais l'intégré. A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Debian refuse de distribuer JOSM avec la projection Lambert 4 zones (France)
Le vendredi 09 sept. 2011 à 20:20:52 (+0200 CEST), Julien Valroff a écrit : Le vendredi 09 sept. 2011 à 20:00:30 (+0200 CEST), Rodolphe Quiedeville a écrit : Le 09/09/2011 17:41, Steven Le Roux a écrit : 2011/9/9 Pierenpier...@gmail.com: 2011/9/9 Rodolphe Quiedevillerodol...@quiedeville.org: Effectivement, la grille est déjà distribuée dans le paquet proj-data: http://packages.debian.org/squeeze/proj-data J'espère que cela va clore le débat. Ou au contraire le relancer au niveau de proj-data. Avant de rapporter un bug contre proj-data et de discuter avec les responsables du paquet josm dans Debian, j'ai creusé un peu et ai en plus noté que ni l'un ni l'autre des paquets n'indique la paternité de l'IGN (et ne respecte ainsi donc pas la licence d'utilisation). Par ailleurs, en plus des problèmes indiqués concernant cette grille, je me rends compte qu'elle est distribuée sous forme de binaire, sans source, ce qui est un problème pour Debian. Je crois comprendre que la grille a été générée à partir de la grille GR3DF97A qui elle est en format texte [0]. Il y a même une notice expliquant comment a été obtenue cette conversion [1]. Je ne trouve cependant pas la licence de la grille GR3DF97A, si quelqu'un avec plus d'expérience que moi sur le site de l'IGN arrive à mettre la main dessus… Maintenant, je me pose les questions suivantes : * Ne serait-il pas possible d'utiliser directement la grille GR3DF97A (qui est présentée comme la grille de référence par l'IGN) si sa licence le permet ? * Y a-t-il un moyen de faire la conversion GR3DF97A ntf_r93.gsb au moment la compilation de josm (toujours si la licence le permet) ? Je constate par ailleurs en passant que proj-data utilise le registre IGNF soumis à la même licence que ntf_r93.gsb. @+ Julien [0] http://www.ign.fr/telechargement/MPro/geodesie/CIRCE/gr3df97a.txt [1] http://lambert93.ign.fr/fileadmin/files/ntf_r93.pdf -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Debian refuse de distribuer JOSM avec la projection Lambert 4 zones (France)
2011/9/12 Julien Valroff jul...@kirya.net: Avant de rapporter un bug contre proj-data et de discuter avec les responsables du paquet josm dans Debian, j'ai creusé un peu et ai en plus noté que ni l'un ni l'autre des paquets n'indique la paternité de l'IGN (et ne respecte ainsi donc pas la licence d'utilisation). Si c'est vrai, c'est un problème. Il faut que la paternité soit mentionnée quelque part dans le paquet. Par ailleurs, en plus des problèmes indiqués concernant cette grille, je me rends compte qu'elle est distribuée sous forme de binaire, sans source, ce qui est un problème pour Debian. Il n'y a pas de source parce qu'il n'y a pas de logiciel. C'est juste un tableau de nombres qui permettent de compenser les écarts dans la transformation d'un système à l'autre. On passe d'une précision de 1 à 5 mètres à une précision de l'ordre de 5 cms. Pour avoir une idée, on peut regarder le graphique de la dernière page de ce document: http://www.ign.fr/DISPLAY/000/526/702/5267029/NTG_88.pdf Je crois comprendre que la grille a été générée à partir de la grille GR3DF97A qui elle est en format texte [0]. Il y a même une notice expliquant comment a été obtenue cette conversion [1]. Je ne trouve cependant pas la licence de la grille GR3DF97A, si quelqu'un avec plus d'expérience que moi sur le site de l'IGN arrive à mettre la main dessus… La licence est la même. C'est juste un format différent et compressé., le NTv2 qui est le standard de facto pour ce genre de grilles comme expliqué dans le document ntf_r93.pdf * Ne serait-il pas possible d'utiliser directement la grille GR3DF97A (qui est présentée comme la grille de référence par l'IGN) si sa licence le permet ? Je n'ai pas trouvé non plus de licence pour la grille en clair mais je ne vois pas pourquoi elle serait sous une autre licence à cause d'une conversion au NTv2 qui est un format ouvert. * Y a-t-il un moyen de faire la conversion GR3DF97A ntf_r93.gsb au moment la compilation de josm (toujours si la licence le permet) ? Euh, éventuellement on peut exploiter la grille en clair mais la convertir en live n'a strictement aucun intérêt puisque la licence n'est pas liée au format NTv2. N'importe qui peut faire cette conversion une fois pour toute, il obtiendra toujours le même résultat et personne ne pourra dire si la conversion a été faite par l'IGN ou par quelqu'un d'autre. Pieren A noter que la licence que j'ai cité en OP n'interdit nul part les modifications. Elle précise seulement dans sa 5e clause que l’attention des utilisateurs est attirée sur le risque de créer des incohérences si toutes les informations pertinentes ne sont pas utilisées.. Il faut comprendre qu'il est dans l'intérêt de l'IGN que sa grille soit utilisée le plus largement possible et pas de fixer des restrictions pour convertir des données géographiques qui existent dans une pléthore de formats différents de par le monde. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] [OSM-Tokai:151] 台風１２号の被害エリアのマッピング
Tomです。ちょっと十津川村の話しと反れますが・・・。 やはりYahoo/ALPSデータは離島や山間部のデータが充実しており インポートの効果は大きいです。 あと、森林域が分かるのも大きいです。 これにBingトレースで集落（多くは川の流域）をマッピングするとさらに 充実したマップになりますね。 最近、僕は思ったんですが、これはOSMの大きなメリットだと感じています。 某G地図と比較するのもアレですが、 あっちの山間部の地図は、そこがどんな土地なのがイメージするのが困難なケースが多いですよね。 今インポートしているYahoo/ALPSデータが離島や山間部において充実しているのは、 基盤地図をベースにしているからではないかと、地図業界素人の私は想像しています。 それに増して、OSMでは、森林地帯や川の流域はもちろんの事、田畑なども表現できますので、 ある程度描かれたOSM地図では、その土地の様子が想像できると思います。 これは、僕は、大きいと思うんですよね。 確かにOSMは地下街の表現が難しいなど、都市部では、ちょっと表現力に欠ける面もありますが、 離島や山間部では、表現力に優れていると思うんですよ。 こういう地域では自然環境も厳しいところも多いですので、災害による被害も大きかったりします。 今回の十津川村のようなケースでは、災害の起きた現場の様子がイメージしやすいかと思います。 また、同時に、過疎化や高齢化が進んでいたり、観光開発を計画しているようなケースも多いです。 特に観光で利用する地図であるならば、観光客がその土地をイメージできる地図が必要なはずです。 そういうケースにも、OSMの地図を使ってもらいたいと思うんですよ。 なんか、離島や山間部のネットワークにOSMを普及できるようなチャンネルがあるといいですよね。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-us] access=destination vs access=private
On 9/11/2011 6:12 PM, Anthony wrote: On Sun, Sep 11, 2011 at 10:59 AM, Nathan Edgars IInerou...@gmail.com wrote: (As opposed to http://maps.google.com/maps?q=orlandohl=enll=28.394553,-81.549518spn=0.0168,0.041199t=mz=16vpsrc=6layer=ccbll=28.394524,-81.549396panoid=f638RcwkM8_a-3tntIJmRgcbp=12,335.79,,1,3.19 which is on private property and hence presumably enforceable.) Hmm, I just looked at the Orlando Property Appraisers map, and it looks to me like it's right of way. What makes you say it is private property? You must be looking at the wrong road. Except for the intersection with Bonnet Creek Parkway and the crossing of Canal C-1, Vista Boulevard is entirely on land owned by WALT DISNEY PARKS AND RESORTS U S INC. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
