Re: [talk-ph] Cebu tracks.
On Wed, 2008-12-31 at 15:50 +0800, Jim Morgan wrote: Well thanks for the tip. Unfortunately I'd already finished my tracks the hard way by the time I read your post, so I'll have to use it next time. Anyway, the national highway is now in place northbound from Cebu, and the tiny 1km by 2km island of Malapascua now probably has the most detailed cartographic representation anywhere on the internet! Excellent work! In doing this, I've noticed that the major impediment to mapping in OpenStreetMap is the level of detail of satellite images on Yahoo. I could have filled in a lot more information if I was allowed to use the higher res images on Google Earth for eg, but that isn't possible of course. I think this will hold back our efforts in the Philippines unless we can think of some way around this. Without imagery, I think the best way is, GO LOCAL! 1. Map your own LOCALity and talk to others in mapping their LOCALity. 2. Talk to your LOCAL government unit. They might want to share data. I bet CEBU has an extensive GIS data we can add to OSM 3. Organize LOCAL mapping events I don't think Yahoo is in a position to be lobbied to provide more coverage at the moment, and what with Jerry Yang's departure, the future of the company is looking unsure. I think we need to find another source of satellite imagery which we can use, or at least reduce the dependency on Yahoo. Ahh. This new news to me. Keep on mapping! Jim Maning Sambale wrote, On Monday, December 29, 2008 09:24 PM: So, I've just processed the first track by using JOSM. I basically used the grey dots for a guide, and then clicked my way 40 km along the road with the way creation tool. Was that what I was meant to do? Seems a laborious way of doing it, but the data is in there now. In JOSM you can, right-click the gpx file in the layer window and convert to data layer. The whole gpx is now a way which you can add tags or simplify the geometry, by deleting points. You can simplify a way using the simplify plugin. -- 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] Maritme borders
On Wed, Dec 31, 2008 at 1:37 AM, Rory McCann r...@technomancy.org wrote: Some land borders, e.g. between Ireland and the UK are like that. No border control. It is not exactly the same. Anyone (say a person from Morocco or Colombia) is not allowed to walk across Ireland on his way to the UK without going through imigration, but he is allowed to sail through the Irish territorial waters on his way to the UK. The UK miltary is free to use the Irish economic zone (200 mile boundary) for military exercise and can sail through Irish territorial waters in their way there, but they are not free to march through Dublin on their way to a war game in Cork. I think maritime borders should be in OSM. I can't really think why they should be tagged differently. They are a boundary=adminitrative, and they do have an admin_level of 2 What border would you tag? The end of internal waters, the end of territorial waters or the end of the economic zone? I agree that they belong in OSM. But admin_level 2? To me, that implies that this is a boundary between two entities of level 2 (countries). The maritime borders, however, mark decreasing level of control with the same entity (country) on both sides of the border. The places where the territorial waters of two countries meet (that is, where there is less than 24 miles from shore to shore) tagging the same way as a land border makes more sense, in my opinion. - Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging of maritime borders
Message: 10 Date: Tue, 30 Dec 2008 22:32:45 +0100 From: Gustav Foseid gust...@gmail.com Subject: [OSM-talk] Tagging of maritime borders To: osm talk@openstreetmap.org Message-ID: 39f068130812301332s10bb9770y5af8ce4ace9b6...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 In Europe a number of maritime borders have been tagged recently as national borders, with boundary=administrative and admin_level=2. Exactly what is tagged varies: North of Norway: A part of the exclusive economic zone Finland: 24 mile contiguous zone South of Sweden: Looks like an approximation of the 24 mile contiguous zone Denmark: 24 mile contiguous zone Germany in the Baltic Sea: Seems to be territorial waters, but I have not checked the ED50 coordinates given in the source with the actual points Germany in the North Sea: Old 3 mile territorial waters? The Netherlands: Source is AND? Line approx 1 mile of the coast, unsure what this is. Belgium: 24 mile contiguous zone Italy: The coastline, but some places into the sea and other places on land. Greece/Turkey: Only tagged where islands from both countries are close to each other. This is, at best, confusing and, at worst, wrong. The territorial waters and contiguous zones have very different legal status from a national border, you can for instance pass through the territorial waters of a nation without any border controls. Some details are in the Wikipedia article for United Nations Convention on the Law of the Sea. I would suggest that maritime borders are not tagged the same way as land borders. Should we have a new tag for maritime borders? Stop tagging them? Ignore the problem? - Gustav I agree with you there, I have myself interpolated a border 12nm off the coast of Brazil, and tagged it just as the national border. I would like to see more people take a look at http://wiki.openstreetmap.org/wiki/Maritime_borders and help make up a proper set of tags for maritime borders. I would like to see the various forms of maritime borders to be tagged such as territorial waters, fishing limits, economic zones and more. -- Brgds Aun Johnsen (Over Web Mail) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maritme borders
On Wed, Dec 31, 2008 at 1:26 PM, D Tucny d...@tucny.com wrote: I'm not exactly up on laws, rules, treaties and agreements etc regarding borders and controls, but, is this not about politics? If Someone from, using your example, Morocco, flies to the UK via Ireland, they also won't need to go through imigration in Ireland, as long as they are only transferring... That is up to the country you are transferring through. In the US, for instance, you need to go through imigration even when you are transferring between two international flights. The borders are real, they do exist do they not, but, isn't it up to the ruling goverment to decide how they enforce those borders, be it at land, at sea, in the air and with whom they allow free passage across those borders? I suggest the following Wikipedia article as a good starting point: http://en.wikipedia.org/wiki/United_Nations_Convention_on_the_Law_of_the_Sea Should administative boundaries at level 2 show an area of border control only? Should the admin_level between EU member states or between schengen member states be a higher level? say 3 or 4? With an EU boundary at level 2? Or a Schengen boundary at level 2? Or overlapping schengen and EU boundaries at level 2 or 3... No, but I think admin_level should indicate that a line is a boundary between two entities of the same level. When you say that a boundary is admin_level 2, does that not indicate that you have one country on one side of the line and another country on the other side of the line? If used on maritime borders of 12 nm, it indicates that you have one country's territorial waters on one side and the contiguous zone of the same country on the other side. If used at 24 nm it indicates one contry's contiguos zone on one side and the same country's economic zone on the other side. - Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] ITO animation for 2008
Hi all, I know Peter Miller will hate me from now on for announcing this before he does, but behold: http://itoworld.blogspot.com/2008/12/openstreetmap-animation-for-2008.html http://www.vimeo.com/2598878 (Log in to vimeo with an account from http://www.bugmenot.com/view/vimeo.com to download the hi-res version) Cheers, -- -- Iván Sánchez Ortega i...@sanchezortega.es Un ordenador no es un televisor ni un microondas, es una herramienta compleja. signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] ITO animation for 2008
http://itoworld.blogspot.com/2008/12/openstreetmap-animation-for-2008.html http://www.vimeo.com/2598878 All I can say is: wow Great animation you at ITO put there together. Happy new year of mapping :) Joerg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Invisible coastline errors in Potlatch
2009/1/1 Cartinus carti...@xs4all.nl On Wednesday 31 December 2008 18:40:18 Peter Miller wrote: Dodgy circular ways --- There are a number of islands off the Swedish coast that are showing up as errors: http://tile.openstreetmap.nl/coastlines.html?zoom=16lat=57.80195lon=11.66 246layers=B00 If one switches to a OSM view ( http://www.openstreetmap.org/?zoom=16lat=57.80195lon=11.66246layers=B00 ) one can edit them. Using 'h' I can see that they haven't been touched for months, however if I click on them the tagging looks fine and the way is shown as circular. Here is the history of one of them: http://www.openstreetmap.org/browse/way/25610508/history Notice that the way appears to be a triangle, but that the way has four points on it. If it does have an extra segment in the way then why does it show up as a circular way in Potlatch? The simples thing will probably be to delete them and recreate them but I though it was worth pointing it out first. With any circular way the first and the last nodes are the same. So to define a triangle you get four nodes in the xml. But, the problem is that often with the coastline imports, one of those nodes is a duplicate... i.e. there are really 4 nodes, but the last one is at the same point as the first... Those Swedish islands show up as errors because they are too small. Anything with a diameter of less than approximately 10 meter shows up as an error. Are you sure? or is it the previous problem? d ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Invisible coastline errors in Potlatch
On Wednesday 31 December 2008 20:00:24 Peter Miller wrote: On 31 Dec 2008, at 18:20, Cartinus wrote: Those Swedish islands show up as errors because they are too small. Anything with a diameter of less than approximately 10 meter shows up as an error. However the checker explanation doesn't say that (http://wiki.openstreetmap.org/index.php/Coastline_error_checker ) What should one do... 1) Delete all features smaller than 10 meters 2) Keep them in a have loads of people go an investigate false problems 3) Make them bigger so the islands as accepted by the coastline checker 4) Adapt the coastline checker to that is accepts smaller islands. 5) Add a tag to tell the coastline checker to ignore this feature because it really is a small island. I vote for 4), everything else is a cop-out (1 and 3) or will waste lots of people time (2) or be confusing (5). By the way, who maintains the coastline checker and how does one talk to the people who maintain the code? Shouldn't there be information for all tools about how to report problems, how to request features and details of maintaining them? On Wednesday 31 December 2008 20:13:12 Karl Newman wrote: What about 6) Convert tiny islands to a node tagged as a rock or navigation hazard. See this thread for some answers: http://lists.openstreetmap.org/pipermail/talk/2008-November/031934.html I've used 2), 3) and almost 6) -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Invisible coastline errors in Potlatch
On Wednesday 31 December 2008 20:29:50 D Tucny wrote: 2009/1/1 Cartinus carti...@xs4all.nl On Wednesday 31 December 2008 18:40:18 Peter Miller wrote: Here is the history of one of them: http://www.openstreetmap.org/browse/way/25610508/history Are you sure? or is it the previous problem? Try that hyperlink, then you'll know the answer too. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Invisible coastline errors in Potlatch
Shaun McDonald wrote: http://openstreetmap.org/browse/way/22359503/history looks like it is a 2 node way. Seems that there is a bug in Potlatch, causing it to not show the coastline here. But the way contains the same node twice, thus is meaningless. That's not a bug in Potlatch, that's dodgy data. /me looks for the created_by tag and walks away whistling innocently cheers and Happy New Year Richard -- View this message in context: http://www.nabble.com/Invisible-coastline-errors-in-Potlatch-tp21234805p21236868.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Who went mapping over the holidays?
Just out of curiosity, how many folks spent some extra time mapping over the holidays? In my case I was off to visit family in Perth, ON, Canada. I did do part of the town when I was in Perth last September, but now, the road grid within Perth is (as far as I know) completed. Some of the street names have been entered (I do have a few more names and features still to add, hopefully over the next few days...). Does leave a major gap between Perth and nearby Smiths Falls. Even though Smiths Falls is larger than Perth (approx. 10,000 vs. 6,000 people), Smiths Falls has a total of some 4 streets in Open Street Map. Also, of course a lot of the rural roads around Perth are not yet entered... My time in Perth was limited and I couldn't just go mapping... Still, good to see one town more-or-less completed... Small side note, when I was in Perth in September, I saw people were building a small new housing development south of Lally Lane, but cars were not allowed down the (modest length) street. So, I noted what I could of the street, and left things at that. Now, three months later, the street is open to traffic and is in OSM... Take that other maps :-) . Colin McGregor ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Invisible coastline errors in Potlatch
2009/1/1 Cartinus carti...@xs4all.nl On Wednesday 31 December 2008 20:29:50 D Tucny wrote: 2009/1/1 Cartinus carti...@xs4all.nl On Wednesday 31 December 2008 18:40:18 Peter Miller wrote: Here is the history of one of them: http://www.openstreetmap.org/browse/way/25610508/history Are you sure? or is it the previous problem? Try that hyperlink, then you'll know the answer too. It's true! coastline checker bug... :( Sorry for doubting you... d ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Who went mapping over the holidays?
On 31 Dec 2008, at 20:50, Colin McGregor wrote: Just out of curiosity, how many folks spent some extra time mapping over the holidays? I've mapped a whole village (didn't get onto house numbers as it was too cold) in Germany, that is remote enough that I was only able to get ~6KBytes/sec on average, and if I was lucky 30KBytes/sec. It was a good holiday with family, I last seen when I was half my current age. http://openstreetmap.org/?lat=50.27414lon=7.83668zoom=15 Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maritme borders
On Wed, Dec 31, 2008 at 9:44 AM, Steven te Brinke s.tebri...@student.utwente.nl wrote: The maritime borders clearly are administrative and probably are admin_level 2. However, on the wiki Iceland has defined the EEZ to be admin_level 1. I It's not actually used though, Iceland only has admin_level=6 borders defined at the moment. I just listed all the others I could think of along the axis given. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] ITO animation for 2008
We have tried to show to dynamics on OSM for different parts of the world over the year by cutting back to January a few times - the changes over the year are very impressive. Do take a look at it and tell your friends - we have geared the animation and the text around it to promote the project and ensure that people see what a force OSM is becoming. We are up to 4,000 viewing of our flickr image 'OSM - A Year of Edits' and hope to exceed that with this animation. ITO can also produce animations of this sort for particular countries and are happy to take requests. It's beautiful - such an animation for the SF Bay Area would be great to see. Thank you! -mike. michal migurski- m...@stamen.com 415.558.1610 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] ITO animation for 2008
On Dec 31, 2008, at 5:59 PM, Michal Migurski m...@stamen.com wrote: We have tried to show to dynamics on OSM for different parts of the world over the year by cutting back to January a few times - the changes over the year are very impressive. Do take a look at it and tell your friends - we have geared the animation and the text around it to promote the project and ensure that people see what a force OSM is becoming. We are up to 4,000 viewing of our flickr image 'OSM - A Year of Edits' and hope to exceed that with this animation. ITO can also produce animations of this sort for particular countries and are happy to take requests. It's beautiful - such an animation for the SF Bay Area would be great t Can the guys at itoWorld talk about how they made this video? I'd like to do a semi realtime rotating globe with edits. I think that'd be awfully neat. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maritme borders
2008/12/31 Ævar Arnfjörð Bjarmason ava...@gmail.com: On Wed, Dec 31, 2008 at 9:44 AM, Steven te Brinke s.tebri...@student.utwente.nl wrote: The maritime borders clearly are administrative and probably are admin_level 2. However, on the wiki Iceland has defined the EEZ to be admin_level 1. I It's not actually used though, Iceland only has admin_level=6 borders defined at the moment. I just listed all the others I could think of along the axis given. I think 1 was intended more as a continental 'boundary' even though it may be fuzzily defined at places. In other news, I've converted the 12nm line around the UK and Ireland to be fully tagged, so it's now showing in its own bubble on the mapnik render. I do note that Foula is not included in this line, so I'm looking for details on how they were originally created so I can modify it to include this island. -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maritme borders
On Thu, Jan 1, 2009 at 2:50 AM, Thomas Wood grand.edgemas...@gmail.com wrote: 2008/12/31 Ævar Arnfjörð Bjarmason ava...@gmail.com: On Wed, Dec 31, 2008 at 9:44 AM, Steven te Brinke s.tebri...@student.utwente.nl wrote: The maritime borders clearly are administrative and probably are admin_level 2. However, on the wiki Iceland has defined the EEZ to be admin_level 1. I It's not actually used though, Iceland only has admin_level=6 borders defined at the moment. I just listed all the others I could think of along the axis given. I think 1 was intended more as a continental 'boundary' even though it may be fuzzily defined at places. Edit out that definition for Iceland if you don't think it makes sense, like I said it's not even being used and might be confusing currently. I don't see how a continent boundary depends under any sort of administrative tagging. Continents aren't collectively administered, they're geographical and historical features. In other news, I've converted the 12nm line around the UK and Ireland to be fully tagged, so it's now showing in its own bubble on the mapnik render. I do note that Foula is not included in this line, so I'm looking for details on how they were originally created so I can modify it to include this island. Maybe I'm just imagining this but it looks like the nuances of the coastline aren't reflected in the maritime border which always looks relatively straight or curved. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] Just for fun
It wouldn't be the first time someone got the decimal-place wrong . . . Make sure the grave is at least 3.0 metres deep and 2.0 metres long . . . Mike -Original Message- From: talk-au-boun...@openstreetmap.org [mailto:talk-au-boun...@openstreetmap.org] On Behalf Of Liz Sent: Thursday, 1 January 2009 1:24 PM To: talk-au@openstreetmap.org Subject: [talk-au] Just for fun have a look at this place on google maps http://maps.google.com.au/maps?f=qhl=engeocode=q=cadia+valleysll=-25.335 448,135.745076sspn=57.82946,47.197266ie=UTF8ll=-33.456866,148.993363spn= 0.026996,0.039353z=15 then check the satellite view ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p
Am Dienstag, 30. Dezember 2008 19:18 schrieb Tobias Knerr: Bei einer Modellierung per Relation ist die Sache doch recht klar: Eine Spur entspricht genau einem primitiven OSM-Objekt: Way oder Relation. Diese lassen sich in gleicher Weise mit Tags versehen und in gleicher Weise in die zusammenfassende Relation einbinden. Können wir dann nicht wenigstens die Anzahl der Relationen begrenzen ala: 1. Hauptrelation mit highway member 2. Maximal eine weitere Ebene mit einer Relation pro Spur. Im Moment dürfte ich nach dem Vorschlag auch noch Unterrelationen von Unterlationen machen. Die Spur -Relation könnte dann auch einen anderen Typ bekommen als die Haupt-Relation z.B. * lane_group für die Gruppe und * lane_object für die einzelne Spur. ? ist durchaus eine mögliche Lösung. Ich hätte der Einfachheit halber (Sonderfälle...) allerdings bislang daran gedacht, jede Lane nur einem der Highways zuzuordnen -- bei deinem Beispiel erscheint etwa der Grünstreifen in der Mitte als plausible Trennstelle. Auch eine Möglichkeit. Aber wenn dann die Grunfläche eine Area wird, dann wird das ultrakompliziert für Renderer etc. Andere Möglichkeit ist zu sagen das es zwei lane_groups mit jeweils einem highway sind wo nur rechts davon je ein Fußweg und ein Radweg angehängt sind... Brauchen wir dann denn überhaupt lane=cycleway oder könnte man dann nicht gleich wieder highway=cycleway machen? Bei den Straßen machen wir das ja auch nicht, obwohl wir in meinem Beispiel gerade zwei Straßen haben. Dein Ansatz hat leider relative viele Fehlerquellen, wo es nicht valide Ergebnisse gibt. z.B. mehrere nicht verbundene highway member. z.B. zwei Lanes mit der gleicher Nummer (liegen die dann übereinander?) Naja das gibt sich dann mit API 0.6 z.B. illegale Nummernwerte z.B. eins oder one Auch muß der Highway auf jeden Fall unterteilt werden, wenn sich die Anzahl der Spuren ändert (z.B eine Busspur / ein Fahrradweg dazu kommt). Geht der auswertenden Software damit Information verloren, an die ich bislang nicht gedacht habe? == Was würde das für Renderer und Tools bedeuten? == * Beim drehen einer Straße müsste evtl. die Relation angepasst werden, aber warum sollte jemand die Straßen drehen wollen Das ist ein wichtiger Punkt, an den ich bislang nicht gedacht habe -- solche Spuren gehören in der Tat zu den richtungsabhängigen Informationen. Weitere Punkte: * Joinen von Wegen bei dem nur einer Member der Relation ist. Programmiertechnisch ist das auch nicht wirklich simpel, um (wie bei opencycleway.org) die Radwege rechts und links einer Straße zu zeichnen muss man: 1. Testen ob eine lane_group Relation zum highway vorhanden ist 2. Alle Member der lane_group nach lane=cycleway durchsuchen 2a Wenn der Member ein Way ist entscheiden ob man den Verlauf vereinfacht oder selbst zeichnet 2b Wennn der Member eine Relation ist, anhand der Position in der Relation selbst rechts oder links vom highway zeichnen. BTW Es ist beim Entwurf noch nicht festgelegt wo die Mitte (der Member highway), in der lane_group ist. Hast du mal Probiert das für Osmarender umzusetzen? Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienb?ndeldiskussion (Re:Kreuzung Radweg)
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Dienstag, 30. Dezember 2008 10:15:23 schrieb talk-de-requ...@openstreetmap.org: Hallo, Sicher, nur diesen einfachen fall gibt es in der realit?t nur selten. Also hier in Aachen besteht dieser einfache Fall fast ausschlie?lich. Das ist aber f?r dich kein problem; denn du hast ja bereits verk?ndet, dass dich die wirkliche kreuzungssituation nicht interessiert. Der genaue Verlauf des Fahrradsweges interessiert mich dann wenn er mehr als sagen wir 10m vom 'normalen' Verlauf abweicht. bordsteinradwege haben zwischen kreuzungen gern verengungsstellen, wechseln den belag Ich habe noch nirgendwo gesehen, da? jemand Breiten eintr?gt, und wenn w?rde ich f?r einen Abschnitt jeweils die engste Stelle und den schlechtesten Belag nehmen. haben verschwenkungen an bushaltestellen Me?genauigkeit haben absperrungen zwischen fahrbahn und radweg Und wie taggst Du die bei separatem Radweg? MAchst Du dann einen Weg fence dazwischen? Wenn Ja OK. haben abweichende oneway-regelungen cycleway=opposite wechseln zwischen z240, z239, und Radfahrer absteigen Und wie tagst Du das? haben von der fahrbahn abweichende abbiegevorschriften. bei denen gibt es bereits ein exept und man sollte meiner Meinung nach noch ein only hinzuf?gen. Zum teil hast du das ja auch schon erkannt, aber zugleich sagst du nun, dass relationen die dinge komplizierter machen. Meine Erfahrung ist, 90% der Radwege verlaufen entweder auf der Fahrbahn oder unmittelbar daneben, und es tr?gt keiner Breiten oder Fahrbahnbelege ein. Diese 90% m?chte ich m?glichst einfach taggen. Alles andere darf dann komplizierter sein. Taggt man grunds?tzlich Fahrradwege,.. als eigene Wege ist alles kompliziert. Genau! lern, mit den endlichen ressourcen auszukommen. Sie reichen nicht, entweder sehen die Karten schlecht aus oder ein Router kann damit nichts anfangen. Genau! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anlieger?
On Wed, 31 Dec 2008, Johann H. Addicks wrote: Problem sind da eher die Anwohner, die spätestens wenn man das dritte Mal mit auswärtigem Kennzeichen durch dieselbe Nebenstraße kommt (lässt sich oft ja nicht vermeiden), die Köpfe nicht nur verschämt, sondern offensichtlich verdrehen nach dem Eindringling. Das passiert Dir auf dem Dorf schon, wenn Du auf der Hauptstraße langfährst :-) Und wenn Du die Straße bis zum Ende fährst und schon wieder mal mitten auf einem Bauernhof stehst, oder die Straße hinterm Hof sogar noch weitergeht, dann guckt man selbst etwas verwirrt. Meinem Bruder (auch Vermesser) hat mal der Bauer einen Misthaufen aus dem Weg geräumt, damit er zum TP weiterfahren konnte. Sachen gibts ... Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mappen von verzweigten Wegen
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Dienstag, 30. Dezember 2008 17:28:19 schrieb talk-de-requ...@openstreetmap.org: LiLi, Wie mappe ich einen verzweigten Weg? Zum Beispiel in einem Wohngebiet, wenn die Stra?e pl?tzlich noch einen Abstecher macht, um einige zur?ckgesetzte H?user anzubinden? Oder wenn die Einfahrt in eine Stra?e von einer gr??eren Stra?e aus zwei Teilen (einmal von links, einmal von rechts) besteht? Zu sehen gibt es beides im Ort Herzhausen http://openstreetmap.org/?lat=50.95015lon=8.08453zoom=17layers=0B00TTF mfG, Peter Zunächst fällt mir mal auf das da wahrscheinlich etwas nicht stimmt.. Der Bach dort, heißt Dreisbach. Die Straße heißt, An der Dresibach? Was ist denn richtig? Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mapping Quality - Frage zur Bestimmung d er Größe eines Places - Tag?
hi, mir ist die idee gekommen, für places ein tag in die db einzugeben, sodass wir dann die größe des place in etwa wissen. das ist natürlich freiwillig und kann von denjenigen benutzt werden, denen meine radien im augenblick nicht passen. ich selbst eingeschlossen :-) ich dachte an radius=1.3 oder diameter=2.6 [in km] natürlich ist das dann immer noch kreisförmig, aber besser als das, was wir nun haben. ich würde mein programm dann trimmen, auf diese infos zu hören! und es könnte bestätigte radien in einer anderen farbe eintragen und die daten als gesichert oder so kennzeichnen. markus hatte den vorschlag gemacht, eine art siedlungsgrenze einzuführen, die alle gebiete (wohn, industrie etc.) umfasst. ist aber deutlich aufwendiger... ich weiß, es ist keine 100% lösung, aber schon viel besser, als nun... probleme machen mehr so die aneinandergrenzenden vororte, weniger frei gelegene orte. was haltet ihr davon? ciao gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p
Sven Anders schrieb: Können wir dann nicht wenigstens die Anzahl der Relationen begrenzen ala: 1. Hauptrelation mit highway member 2. Maximal eine weitere Ebene mit einer Relation pro Spur. Im Moment dürfte ich nach dem Vorschlag auch noch Unterrelationen von Unterlationen machen. Die Spur -Relation könnte dann auch einen anderen Typ bekommen als die Haupt-Relation Kann man zugunsten der Bearbeitbarkeit tun, zugegeben ist sonst eine Handhabung ohne Sondertools wirklich kaum mehr möglich. Hab das also mal vereinfacht: http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group In dieser Version besser? Die Spur-Relationen sind type=lane, die einzige gruppierende Relation ist vom Typ lane_group. ist durchaus eine mögliche Lösung. Ich hätte der Einfachheit halber (Sonderfälle...) allerdings bislang daran gedacht, jede Lane nur einem der Highways zuzuordnen -- bei deinem Beispiel erscheint etwa der Grünstreifen in der Mitte als plausible Trennstelle. Auch eine Möglichkeit. Aber wenn dann die Grunfläche eine Area wird, dann wird das ultrakompliziert für Renderer etc. Andere Möglichkeit ist zu sagen das es zwei lane_groups mit jeweils einem highway sind wo nur rechts davon je ein Fußweg und ein Radweg angehängt sind... Das ist die sonderfallfreiste Lösung, also würde ich das für den Moment empfehlen. (Die Busspur können wir trotzdem noch ranhängen, halt links in einer der beiden lane_groups.) Brauchen wir dann denn überhaupt lane=cycleway oder könnte man dann nicht gleich wieder highway=cycleway machen? Grund für den Lane-Key ist: a) nicht jeder Highway-Typ ist auch als Spur sinnvoll. Was ist eine secondary-Spur? Und kann sie auch in einem highway=motorway vorkommen? Und so weiter. Eigentlich gibt es eine Überlappung nur bei den highways, die in der Realität halt i.d.R. nur einspurig vorkommen (Fußweg, Radweg...), so dass kaum Spur und gesamter, einspuriger Verkehrsweg unterschieden werden können. b) Wenn sich ein Renderer entscheidet (sei es in einer Zoomstufe oder generell), auch als Way gezeichnete lanes nicht separat zu zeichnen, sondern sich auf die Highways zu beschränken, dann braucht er nicht auf Mitgliedschaft in irgendwelchen Relationen zu testen. Das vereinfacht das Schreiben eines Minimal-Renderers. Bei den Straßen machen wir das ja auch nicht, obwohl wir in meinem Beispiel gerade zwei Straßen haben. Eigentlich(TM) wäre eine Modellierung als ein Highway mit zwei Lanes und einem Separator dazwischen möglich. Ist aber nicht kompatibel mit Bestehendem und fehleranfällig, also betrachten wir das halt als 2 Straßen. Bei dieser Betrachtung sind dann auch 2 Lane-Groups konsequent. Dein Ansatz hat leider relative viele Fehlerquellen, wo es nicht valide Ergebnisse gibt. z.B. mehrere nicht verbundene highway member. z.B. zwei Lanes mit der gleicher Nummer (liegen die dann übereinander?) Naja das gibt sich dann mit API 0.6 z.B. illegale Nummernwerte z.B. eins oder one Die lassen sich tendenziell leicht von einem Validator feststellen. Punkt 2 und 3 haben sich ja hoffentlich bald erledigt. Es gibt aber zugegeben noch einige kritischere, etwa: tatsächlicher Verlauf der Ways passt nicht zu ihrer Anordnung in der Relation. So etwas lässt sich nicht ohne weiteres automatisiert prüfen. Auch muß der Highway auf jeden Fall unterteilt werden, wenn sich die Anzahl der Spuren ändert (z.B eine Busspur / ein Fahrradweg dazu kommt). Das müsste er bei fast allen Lösungen -- insbesondere auch bei Tag-basierten. Halte ich aber für akzeptabel. Weitere Punkte: * Joinen von Wegen bei dem nur einer Member der Relation ist. Nicht trivial, da hast du leider recht. Im Zweifel (beide Wege haben Lanes oder es sind Way-Lanes dabei) wird man wohl den Benutzer die Reaktion wählen lassen müssen. Programmiertechnisch ist das auch nicht wirklich simpel, um (wie bei opencycleway.org) die Radwege rechts und links einer Straße zu zeichnen muss man: 1. Testen ob eine lane_group Relation zum highway vorhanden ist 2. Alle Member der lane_group nach lane=cycleway durchsuchen 2a Wenn der Member ein Way ist entscheiden ob man den Verlauf vereinfacht oder selbst zeichnet 2b Wennn der Member eine Relation ist, anhand der Position in der Relation selbst rechts oder links vom highway zeichnen. Es wird einfacher, wenn man 2a pauschal entscheidet: * Wenn man immer nur einen gefärbten Rand zeichnen will, ist die Unterscheidung zwischen Relation und Way nicht nötig. * Wenn man Ways immer separat zeichnet, kann man das Randzeichnen auf Relationen beschränken und lane=cycleway wie highway=cycleway behandeln. Schwierig wirds in der Tat, wenn man Ways nur manchmal nicht separat zeichnen will. Das liegt aber nicht am Schema, sondern dürfte, so weit ich das sehe, ein inhärentes Problem beim Verwenden eigener Ways sein. BTW Es ist beim Entwurf noch nicht festgelegt wo die Mitte (der Member highway), in der lane_group ist. Nirgends, es sei denn, er ist nicht
Re: [Talk-de] Mappen von verzweigten Wegen
Wenn ich dort auch alle Tags eintrage, wird der Name extrem hässlich in diese Wege gerendert. Es gibt da irgendein Tag um das rendern zu unterbinden, komme aber gerade nicht drauf. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)
Hallo, Allerdings würde man dabei halt etwas aus dem Rahmen fallen im Vergleich zu footway=right/left/both das auch Teil des Proposals ist cycleway=track/lane ist aber schon etabliert, deshalb würde ich versuchen dieses Schema auf footway auszuweiten statt es ganz neu zu machen. Aber von mir aus kann man auch ein Programm alles alte anpassen lassen. Wir sollten eine allgemeingültige Lösung für right/left finden, damit nicht bei jedem Tag das Seitenabhängig ist wieder die Editoren angepaßt werden müssen. Deshalb sollte meiner Meinung nach das right/left am Anfang notfalls am Ende aber nicht in der Mitte stehen. Dann können die Editoren alles was mit Left: beginnt beim drehen automatisch in Right: wandeln ohne den Tag kennen zu müssen. Meiner Meinung nach sollte es also so aussehen: Jedes Key/Value Paar das so für beide Straßenseiten gilt kann durch right/left ergänzt werden um sie auf eine Seite zu beschränken. Jedes Key/Value Paar das so nur für eine Straßenseiten gilt kann durch both ergänzt werden um sie auf beide Seiten zu beschränken. Nach dem aktuellen Proposalstand macht das aber nur bei footway Sinn, da footways bei einigen highway-Typen implizit vorhanden sind OK 'both' bezieht sich auf 'beide Seiten', nicht auf 'beide Richtungen'. Insofern ist es keine Alternative zu cycleway=opposite. Doch, zumindest für einen Teil, oft gibt es Einbahnstraßen mit Fahrradwegen auf beiden Seiten, da könnte man both nutzen, ist nur ein bidirektionaler Fahrradweg vorhanden wäre oneway:bicycle=no richtig. I.W.? Über die Kleinigkeiten diskutieren wir ja gerade ;-) Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mappen von verzweigten Wegen
Hallo. Am Mittwoch, 31. Dezember 2008 schrieb Dimitri Junker: Wenn ich dort auch alle Tags eintrage, wird der Name extrem hässlich in diese Wege gerendert. Es gibt da irgendein Tag um das rendern zu unterbinden, komme aber gerade nicht drauf. Nein. Es gibt Tags um IN OSMARENDER das Namens-Rendering zu verhindern. Was bitte bringt es, wenn in Osmarender etwas mehr oder weniger hässlich ist? Fast nur Mapper benutzen momentan die Osmarender-Karten. In Mapnik sieht sowas i.A. nicht hässlich aus. Bitte keine spezifischen Renderer-Tweaks in die Daten einbauen! Gruß, Bernd -- Wenn du kritisiert wirst, dann mußt du irgendetwas richtig machen. Denn nur derjenige wird angegriffen, der den Ball hat. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] right/left
Hallo, Ich habe mal ein Proposal geschrieben: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left Bitte schaut es Euch an und korigiert formale Fehler und diskutiert es. Und wo soll ich dies jetzt außer hier noch bekannt geben? Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)
Dimitri Junker schrieb: Hallo, Allerdings würde man dabei halt etwas aus dem Rahmen fallen im Vergleich zu footway=right/left/both das auch Teil des Proposals ist cycleway=track/lane ist aber schon etabliert, deshalb würde ich versuchen dieses Schema auf footway auszuweiten statt es ganz neu zu machen. Aber von mir aus kann man auch ein Programm alles alte anpassen lassen. Würdest du also statt einfach footway=left lieber immer explizit footway=left:track schreiben wollen? Eigentlich fände ich cycleway=both auch etwas einleuchtender, da es direkt zeigt, dass es auf beiden Seiten ist. cycleway=track sagt das nicht aus. Etwas problematisch finde ich auch, dass bei cycleway=track/lane im Wiki nichtmal dabeisteht, dass der Radweg damit auf beiden Seiten ist. Aber wie soll man es sonst interpretieren? Raten auf welcher Seite er ist? Vielleicht wäre es doch besser etwas ganz Neues zu machen, wenn die bisherigen Tags so uneindeutig sind. Wenn du mit alles alte anpassen die Daten in der Datenbank direkt meinst, da halte ich eigentlich nichts davon, da man nicht einfach so in die Arbeit von anderen reinpfuschen sollte. Wir sollten eine allgemeingültige Lösung für right/left finden, damit nicht bei jedem Tag das Seitenabhängig ist wieder die Editoren angepaßt werden müssen. Deshalb sollte meiner Meinung nach das right/left am Anfang notfalls am Ende aber nicht in der Mitte stehen. Dann können die Editoren alles was mit Left: beginnt beim drehen automatisch in Right: wandeln ohne den Tag kennen zu müssen. Meiner Meinung nach sollte es also so aussehen: Jedes Key/Value Paar das so für beide Straßenseiten gilt kann durch right/left ergänzt werden um sie auf eine Seite zu beschränken. Jedes Key/Value Paar das so nur für eine Straßenseiten gilt kann durch both ergänzt werden um sie auf beide Seiten zu beschränken. Da bin ich dagegen. Ich sehe kein Problem darin einfach die gesamten Schlüssel und Werte nach left/right zu durchsuchen und jeweils zu tauschen. Da man sowieso gefragt werden sollte ob man die Werte wirklich tauschen will, ist es auch nicht so schlimm wenn man mal etwas erwischt das nicht richtungsabhängig ist. Zumal man Wege auch nicht so häufig dreht. Davon ausnehmen könnte man auch Dinge die freien Text enthalten wie note, FIXME oder name. Alle anderen Schlüssel die left/right enthalten dürften dann auch tatsächlich richtungsabhängig sein. Dagegen bin ich, da es die Hierarchie durchbricht. Ich finde es besser wenn alle Schlüssel die sich auf cycleway beziehen auch mit cycleway beginnen. So hat man dann: cycleway=track cycleway:left.width=1.5 cycleway:right.width=2.5 Statt: cycleway=track left:cycleway.width=1.5 right:cycleway.width=2.5 Zumal auch noch Tags dazwischen auftauchen können, da die Tags in den Editoren meist alphabetisch geordnet sind. Würde man als Hauptschlüssel left und right nehmen, dann wäre es etwas anderes. Dann wäre eben die linke und rechte Straßenseite der Hauptschlüssel, statt der Radweg: left=cycleway:track right=cycleway:track left:cycleway.width=1.5 right:cycleway.width=2.5 Oder auch: both=cycleway:track left:cycleway.width=1.5 right:cycleway.width=2.5 Oder auch (da man sonst ja nur einen Weg angeben kann, da der Schlüssel 'both' nur einmal vorkommen darf): both:cycleway=track left:cycleway.width=1.5 right:cycleway.width=2.5 Allerdings könnte man dann auch so Scherze machen wie: both:cycleway=track left:cycleway=lane right:cycleway=track right:footway=track Was bedeutet das dann? Mit cycleway, track und footway muss man auf maximal drei Tags schauen, um zu wissen was überhaupt vorhanden ist. Etwas weiter schauen muss man dann, um die Eigenschaften der Wege zu erfahren, also ob es lane/track ist, die Breite oder was auch immer noch interessant sein könnte. 'both' bezieht sich auf 'beide Seiten', nicht auf 'beide Richtungen'. Insofern ist es keine Alternative zu cycleway=opposite. Doch, zumindest für einen Teil, oft gibt es Einbahnstraßen mit Fahrradwegen auf beiden Seiten, da könnte man both nutzen, ist nur ein bidirektionaler Fahrradweg vorhanden wäre oneway:bicycle=no richtig. Aber ein cycleway=* (außer opposite) definiert immer eine irgendwie zur restlichen Fahrbahn seperaten Radweg. cycleway=opposite gibt eigentlich nur Einbahnstraßen zur Verwendung für Radfahrer in die Gegenrichtung frei, also Einfahrt verboten mit Radfahrer frei. Eigentlich ein unlogischer Tag, eher eine Behelfslösung. Sowas wie oneway:bicycle=no wäre doch viel konsistenter und logischer. I.W.? Über die Kleinigkeiten diskutieren wir ja gerade ;-) Ich wollte eigentlich wissen was I.W. bedeutet.. ;) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hinweise zur Qualitätskontrolle bei ecki gen Straßenverläufen
Über die stille Zeit zwischen den Jahren habe ich mal ein wenig Gelegenheit gefunden, mich an den Rechner zu setzen und das vor ein paar Wochen diskutierte Thema eckiger Verläufe aufgearbeitet. Wenn Ihr verlegen um ein paar Anregungen seid, hier ist ein kurzes Protokoll: http://derwisch.wikidot.com/blog:coarsehighways. -- 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] INFAS Kreisgrenzen
Bernd Wurst schrieb: Hallo. Am Mittwoch, 31. Dezember 2008 schrieb Frederik Ramm: Ich habe den Import jetzt angestossen, allerdings geht der Upload doch etwas gemächlich, so dass der groesste Teil des 31.12. wohl noch damit herumgeht, die Daten hochzuladen. Die Nodes sind bei mir schon da, der Way darauf noch nicht. ;-)) Ich bin gespannt. :) Ich hab auch gerade bei mir ein paar Taglose, Waylose Nodes gefunden und war kurz davor die einfach zu löschen. Da hab ich mir grad noch angeschaut, wer die denn erstellt hat und als ich Geofabrik las wusste ich gleich Lass das in Frieden, das passt schon so. Also Glück gehabt, will gar nich wissen was der Bot macht wenn er die ways erstellen will und die nodes sind weg. Euch allen einen guten Rutsch und ein schönes 2009. Jannis ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Your whishlist for Debian Packages?
Am Dienstag 30 Dezember 2008 schrieb Joerg Ostertag (OSM Tettnang/Germany): On Dienstag 30 Dezember 2008, Rainer Dorsch wrote: Am Dienstag, 30. Dezember 2008 schrieb Joerg Ostertag (OSM Tettnang/Germany): Repository for lenny (testing) /etc/apt/sources.list # Gpsdrive Packages deb http://www.gpsdrive.de/debian etch main deb-src http://www.gpsdrive.de/debian etch main Soll das wirklich etch (für lenny?) heißen? Ja, denn noch gibt es von allem nur debian-testing packages (Das ist noch Altlast aus der Zeit als etch das debian-testing war). Aber da bin ich grad am schrauben, damit das repository dann auch wirklich mit den Namen das reflektiert, was auch wirklich drin ist. wenn du schon beim schrauben bist: es waere toll, wenn pakete die icons, skripte, und andere plattformunabhaengige dinge enthalten, auch als solche gekennzeichnet sind. sonst krieg ich das alles nur auf x86 installiert, und z.B. nicht auf armel... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hinweise zur Qualitätskontrolle bei ec kigen Straßenverläufen
hi, sehr schön, habe es gleich mal auf den QA seiten des wiki eingetragen. ciao gerhard gary68 Am Mittwoch, den 31.12.2008, 14:28 +0100 schrieb Johannes Huesing: Über die stille Zeit zwischen den Jahren habe ich mal ein wenig Gelegenheit gefunden, mich an den Rechner zu setzen und das vor ein paar Wochen diskutierte Thema eckiger Verläufe aufgearbeitet. Wenn Ihr verlegen um ein paar Anregungen seid, hier ist ein kurzes Protokoll: http://derwisch.wikidot.com/blog:coarsehighways. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frohes Neues Jahr!
Wer es noch nicht gesehen hat; seit heute ist das Neu-Jahrs-Geschenk von ITO verfügbar! Ein Video mit den Edits des Jahres. Sehr beeindruckend das ganze und ein wenig stolz macht es auch. http://www.vimeo.com/2598878 In diesem Sinne Rutscht gut Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frohes Neues Jahr!
Toll! Torsten Breda schrieb: Wer es noch nicht gesehen hat; seit heute ist das Neu-Jahrs-Geschenk von ITO verfügbar! Ein Video mit den Edits des Jahres. Sehr beeindruckend das ganze und ein wenig stolz macht es auch. http://www.vimeo.com/2598878 In diesem Sinne Rutscht gut Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de begin:vcard fn:Dr. Franz-Josef^Behr n:Behr;Franz-Josef org:Stuttgart University of Applied Sciences (SUAS);Faculty of Geomatics, Computer Science and Mathematics adr;quoted-printable:;;Schellingstra=C3=9Fe 24, ;Stuttgart;;D-70174;Germany title:Prof. tel;work:+49) 711/8926-2606 tel;home:+49 (0)721 / 453980-1 url:http://www.hft-stuttgart.de/ version:2.1 end:vcard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hallo, leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben und weil dieser halt nun doch laenger dauert, massiv Nodes, die noch nicht zu Ways verbunden wurden. Ich habe die alle angemailt und stelle die Nodes wieder her, aber falls jemand die User Ropino und Stefano kennt und mal direkt anrufen/anmailen kann, das waere hilfreich - die haben zusammen naemlich schon ueber 1000 Nodes geloescht ,-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Frederik Ramm schrieb: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben Hi Frederik, sind die Nodes denn nicht mit einem entsprechenden Hinweis versehen? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel, Radwege
Dimitri Junker schrieb: Wenn nämlich nachher doch alle Arbeit umsonst ist, stelle ich meine Mitarbeit lieber gleich ein. Mach es so wie Du es für sinnvoll hälst, shreib ggf. irgendwas als note rein, so daß Du sie einfach wiederfindest, wenn wir dann mal einen Konsens gebildet haben kannst Du sie anpassen, alles was bisher nicht tagbar ist kannst Du entweder provisorisch in eigene Tags schreiben oder auch ins Note cycleway=lane:right bzw. cycleway=lane:left getaggt, Ich wollte mal ein Proposal zu right/left machen, hab aber noch nie ein Proposal geschrieben. Ich vermute, daß es programiertechnisch geschickter ist das right/left vor den Value zu schreiben, also cycleway=left:lane Aber da werde ich die unterschiedlichen Varianten zur Diskussion stellen. Eine solche Radspur ist standardmäßig nicht für Fußgänger zugelassen, sonst foot=yes. das müßte dann um in Deiner Nomenklatur zu bleiben cycleway=foot:yes. sein, sonst kann man ja nicht unterscheiden ob Fußgänger auf diesem Fahrradweg oder auf dem daneben liegendem Bürgersteig gehen dürfen. Radweg, der von der Straße nur durch eine Kante wie eine Bürgersteigkante abgetrennt ist, insbesondere im innerstädtischen Bereich. Häufig unterbrochene schmale (1m) Grünstreifen oder Parkstreifen würde ich auch noch erlauben. Bei optisch getrenntem Rad/ Fußweg (Zeichen 241) wird segregated=yes ergänzt, Wo ist segregated definiert? Ist klar, daß es sich auf den Fußgänger-/Fahrradweg bezieht? sonst wieder: cycleway=segregated:yes. Ansonsten würde ich dafür stimmen Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ich weiß ich Wiederhole mich, aber eine Lane-Relation (mit Hilfe des Plugins für JOSM z.B.) ist IMO noch die effektivste und eindeutigste Methode diese Detaildaten zu erfassen. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hallo. Am Mittwoch, 31. Dezember 2008 schrieb Chris-Hein Lunkhusen: sind die Nodes denn nicht mit einem entsprechenden Hinweis versehen? Die Nodes sind ungetagged. Tags kommen dann an die zugehörigen Ways. Das ist eigentlich durchaus normal, nur dauert es hier scheinbar einfach etwas arg lang bis die Ways mit den Infos hochgeladen sind. Wenn man das vorher gesehen hätte, wäre es vermutlich so gemacht worden, dass man nicht erst alle nodes und dann die Ways dazu hochläd sondern immer erst ein paar Nodes, dann den betreffenden Way. Aber jetzt alles nochmal von vorne zu starten wäre auch unoptimal. Gruß, Bernd -- Mein Computer kann 1000 falsche Daten in einer Sekunde sortieren. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hallo, Chris-Hein Lunkhusen wrote: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben Hi Frederik, sind die Nodes denn nicht mit einem entsprechenden Hinweis versehen? TomH würde mir was husten, wenn ich 600.000 Nodes mit jeweils langwieriger Erklaerung hochladen wuerde ;-) - im Nachhinein war es ungeschickt von mir, den Import in einem Rutsch zu machen, ich haette lauter einzelne Nodes und dann immer gleich die dazu passenden Ways hochladen sollen statt erst alle Nodes und spaeter alle Ways. Durch den grossen Zeitabstand gibt es nun diese Probleme, die man sonst vermeiden haette koennen... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hi, Frederik Ramm wrote: falls jemand die User Ropino und Stefano kennt und mal direkt anrufen/anmailen kann Hat sich erledigt, danke. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Frederik Ramm schrieb: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben und weil dieser halt nun doch laenger dauert, massiv Nodes, die noch nicht zu Ways verbunden wurden. Da haben sich auch ein paar Leute schon im Forum beschwert, dass sie nichts davon mitbekommen haben, ich würde daher davon ausgehen, dass Nicht-Mailinglistenleser da tatsächlich unzureichend informiert wurden. Solche Löschungen sind leider also durchaus nicht verwunderlich. http://forum.openstreetmap.org/viewtopic.php?pid=12770#p12770 Tobias Tordanik Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hi, On Wed, Dec 31, 2008 at 06:44:56PM +0100, Tobias Knerr wrote: Frederik Ramm schrieb: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben und weil dieser halt nun doch laenger dauert, massiv Nodes, die noch nicht zu Ways verbunden wurden. Da haben sich auch ein paar Leute schon im Forum beschwert, dass sie nichts davon mitbekommen haben, ich würde daher davon ausgehen, dass Nicht-Mailinglistenleser da tatsächlich unzureichend informiert wurden. Solche Löschungen sind leider also durchaus nicht verwunderlich. http://forum.openstreetmap.org/viewtopic.php?pid=12770#p12770 Weil ich eh gerade schlechte laune habe - Haben die leute die hier wirklich etwas machen und sich engagieren eigentlich fuer den letzten mapper dieser Erde eine bringschuld? Gibs auch schon eine Liste von Tageszeitugnen wo das veroeffentlicht werden muss? Oder koennten nicht alle die sich unterinformiert fuehlen hier gleich ihre twitterid, icqid, yahoo, aim, msn, openid, mailaddress, telefonnummer, pagernummer etc angeben. Dann koennte ich vorher mich mal eben hinsetzen und jeden Persoehnlich abholen. Flo der wohl bald jedem den Arsch einzeln abwischt -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)
der Workaround mit dem JOSM-lane-plugin wäre - Weg auswählen. - lane links hinzufügen - lane rechts hinzufügen - attribute setzen - fertig und damit hätten wir eine ziemlich genaue Darstellung der Realität im Rahmen der möglichen Genauigkeit (5m) Dann könnte man jeder Spur Atrribute wie Breite, maxspeed, direction, etc. geben. Wenn der Radweg dann einen krassen Schlenker (z.B. weil er in einer Spirale ein Level hoch runter (Tunnel/Brücke) geführt wird, oder einfach da chaotisch sich von der STraße abwendet, dann zeichnet man ab dieser Stelle eben einen seperaten cycleway. Manchmal verstehe ich nicht, warum die Leute so komplitziert denken ;-) Guten Rutsch euch allen :-) -- Mario Sebastian Hohmann schrieb: Dimitri Junker schrieb: Versteh ich nicht. Das gibt doch nur an auf welcher Seite der Radweg liegt. Oder bemängelst du damit, dass man zusätzlich noch cycleway.type=lane angeben muss? Bisher haben wir zum Key cycleway u.a. track und lane. Das von Dir vorgeschlagene right/left ist keine Alternative dazu sondern ein Zusatz. Man muß angeben können, daß der rechte Fahrradweg ein lane und der linke ein track ist. Deshalb z.B. cycleway=left:track Ein cycleway.type=lan würde da auch nicht helfen. Natürlich könnte man auch optional einen Wert wie left:track definieren, um gleich beide Informationen auf einmal angeben zu können. Man muß sie zusammen angeben, weil es ja 2 Fahrradwege geben kann. Also wenn es dir nur darum geht, dann ist es kein Problem. cycleway.type=lane setzt den Typ auf alle cycleways, egal ob man nun right/left oder auch both angegeben hat. Möchte man nur für eine Seite den Typ angeben (das macht nur bei 'both' Sinn), dann kann man dies mit cycleway:right.type=lane machen. Das Ganze ist halt quasi hierarchisch aufgebaut: both - right - left Lässt man die Angabe von right/left im Schlüssel weg, wird automatisch 'both' angenommen. cycleway.width=2.5 setzt also die Breite für 'both' und 'vererbt' es an 'right' und 'left'. Was zuvor mit cycleway=right/left/both/none angegeben wurde ist dabei egal, es setzt einfach die Breite für beide Seiten. Wenn auf einer Seite keiner vorhanden ist, wirkt es sich logischerweise eben nur auf eine Seite aus. Gibt man keinen 'type' an, wird automatisch angenommen, dass es sich um einen 'track' handelt. Willst du allerdings den Typ ohne ein extra-Tag angeben, könnte man natürlich auch sowas wie left:lane benutzen. Allerdings würde man dabei halt etwas aus dem Rahmen fallen im Vergleich zu footway=right/left/both das auch Teil des Proposals ist und bei dem 'lane' wohl eher selten vorkommt. Nimmt man weiterhin zusätzlich an, dass ein Weglassen des Types automatisch ein 'track' ist, hätte man eben statt 4-Hauptwerten plötzlich 7: right/left/both/none/right:lane/left:lane/both:lane. Zusätzlich müsste man dann noch die bisherigen cycleway=track/lane mit einberechnen, die einen Radweg des jeweiligen Typs auf beiden Seiten definieren. Man hat dann also z.B.: - cycleway=lane für 'lane' auf beiden Straßenseiten - cycleway=both für 'track' auf beiden Straßenseiten - cycleway=right:lane für 'lane' rechts - cycleway=right für 'track' rechts Allerdings wären andere Schreibweisen wohl auch gültig, also: - cycleway=right:track für 'track' rechts - cycleway=both:track für 'track' auf beiden Straßenseiten usw. Das kann man natürlich auf die Spitze treiben. Und da sind noch nichtmal footway und path mit dabei. Das kommt halt davon wenn man zum einen versucht bisherige Tags zu berücksichtigen und es zusätzlich auch noch versucht 'einfacher' zu machen indem viele Werte impliziert werden. :) Ob man das will ist halt die Frage, das macht irgendwie alles noch komplizierter, sowohl für den Mapper als auch den Benutzer. Wobei der Mapper es natürlich auch als angenehmer weil kürzer empfinden könnte. Aber wiegesagt, irgendwie fällt es so aus dem Rahmen. Die Renderer könnte z.B. anstatt Regeln für alle Fälle zu erstellen die Wege vor dem Rendern in ein einheitliches Schema umschreibem, so wie sie es eben brauchen. Alternativ könnte man natürlich auch ganz streng sein und sagen: Wir geben immer einen Typ an. Also: - cycleway=lane für 'lane' auf beiden Straßenseiten - cycleway=track für 'track' auf beiden Straßenseiten - cycleway=right:lane für 'lane' rechts - cycleway=right:track für 'track' rechts Somit hätte man das bisherige Tagging beachtet und gleichzeitig nicht mehr so viele Ausnahmen. Oder man macht es halt einfach so wie in meinem Proposal. Was ist nun besser? Man weiß es nicht. :) cycleway=none/both:track/right/.. sollte dann aber auch möglich sein. Der Nutzen von none ist mir noch nicht klar, both wäre z.B. bei Einbahnstraße sinnvoll als bessere Alternative zu cycleway=opposite 'none' sagt einfach aus, dass sich dieser Typ nicht an der Straße befindet. Nach dem aktuellen
Re: [Talk-de] Fläche von Polygon berechnen?
Gary G: schrieb: hi, hat jemand einen algorithmus zum berechnen der (ungefähren) fläche eines polygons (gegeben durch lon/lat nodes) unter der berücksichtigung, dass die erde keine scheibe ist? perl wäre super, anderes ebenfalls willkommen! Hallo Gary, wenn du dir die komplizierte Berechnung auf einem Ellipsoid sparen willst, kannst du auch die Positionen in GK umrechnen. Dann ist die Gauß'sche Trapezformel ein Klacks: http://de.wikipedia.org/wiki/Gaußsche_Trapezformel Hat halt den Nachteil, dass es dort die Umrechnung der Koordinaten langsamer ist und du musst für GK den richtigen Meridian ermitteln. Sonst wirds mit wachsender Entfernung zum gewählten Meridian immer ungenauer. VG, ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Quality - Frage zur Bestimmung der Gr öße eines Places - Tag?
Am 31.12.08 schrieb GS gerhardschw...@yahoo.de: hi, mir ist die idee gekommen, für places ein tag in die db einzugeben, sodass wir dann die größe des place in etwa wissen. das ist natürlich freiwillig und kann von denjenigen benutzt werden, denen meine radien im augenblick nicht passen. ich selbst eingeschlossen :-) ich dachte an radius=1.3 oder diameter=2.6 Ich halte place_radium für besser, damit man sieht daß es sich der Radius bzgl des place-tags ist und nicht von irgendwas anderem (z.B. highway=mini_roundabout;radius=10). Macht die Suche einfacher, da man weniger unpassende rausfiltern muss. [in km] natürlich ist das dann immer noch kreisförmig, aber besser als das, was wir nun haben. ich würde mein programm dann trimmen, auf diese infos zu hören! und es könnte bestätigte radien in einer anderen farbe eintragen und die daten als gesichert oder so kennzeichnen. markus hatte den vorschlag gemacht, eine art siedlungsgrenze einzuführen, die alle gebiete (wohn, industrie etc.) umfasst. ist aber deutlich aufwendiger... ich weiß, es ist keine 100% lösung, aber schon viel besser, als nun... probleme machen mehr so die aneinandergrenzenden vororte, weniger frei gelegene orte. was haltet ihr davon? Schau mal auf http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing#City da ist zusammengefasst, wie das momentag läuft. Ich halte es für eine gute Idee, für den Fall, daß man nicht mal ein ungefähres Polygon um den Ort ziehen kann. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Florian Lohoff schrieb: Hi, On Wed, Dec 31, 2008 at 06:44:56PM +0100, Tobias Knerr wrote: Frederik Ramm schrieb: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben und weil dieser halt nun doch laenger dauert, massiv Nodes, die noch nicht zu Ways verbunden wurden. Da haben sich auch ein paar Leute schon im Forum beschwert, dass sie nichts davon mitbekommen haben, ich würde daher davon ausgehen, dass Nicht-Mailinglistenleser da tatsächlich unzureichend informiert wurden. Solche Löschungen sind leider also durchaus nicht verwunderlich. http://forum.openstreetmap.org/viewtopic.php?pid=12770#p12770 Weil ich eh gerade schlechte laune habe - Haben die leute die hier wirklich etwas machen und sich engagieren eigentlich fuer den letzten mapper dieser Erde eine bringschuld? Gibs auch schon eine Liste von Tageszeitugnen wo das veroeffentlicht werden muss? Oder koennten nicht alle die sich unterinformiert fuehlen hier gleich ihre twitterid, icqid, yahoo, aim, msn, openid, mailaddress, telefonnummer, pagernummer etc angeben. Dann koennte ich vorher mich mal eben hinsetzen und jeden Persoehnlich abholen. Eigentlich dachte ich ja, du hättest hier übertrieben. Aber wenn ich den Forumsthread lese, bist du fast komplett an der Realität drann. Wenn man das/die Prinzipien von OSM (es gibt eigentl. nur eine handvoll) nicht verstanden hat bzw. verstehen will und auch sonst nicht lernbereit ist, dann ist wirklich nicht zu helfen. Da ist nichts konstruktives bzw. halbwegs objektives dabei, da hab ich dann auch keine Lust mehr zu helfen. Allen anderen positiv eingestellen, motivierten Lesern ein erfolgreiches (OSM-) Jahr 2009! Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] INFAS Kreisgrenzen
Hallo, Frederik Ramm wrote: Ich habe den Import jetzt angestossen, allerdings geht der Upload doch etwas gemächlich, so dass der groesste Teil des 31.12. wohl noch damit herumgeht, die Daten hochzuladen. Parallel beginne ich mit dem Umtaggen der existierenden Daten. Schaun wir mal... Die Nodes haben rund 20 Stunden gedauert, die Ways und Relations waren dann fix, so dass der Import noch 2008 abgeschlossen war. Während der Import lief, habe ich ständig anhand der stündlichen Diffs kontrolliert, ob jemand importierte Nodes gelöscht hat, und diese dann wiederhergestellt (samt Nachricht an den Löscher). Insgesamt haben rund 30 verschiedene Leute rund 2500 Nodes gelöscht. Das war fuer mich zwar unerfreulich, aber andererseits ist es ein imposanter Beweis dafuer, wie viel mit unseren Daten gearbeitet wird. Das laesst hoffen, dass z.B. ein Akt von Vandalismus tatsaechlich sehr schnell bemerkt und beseitigt wuerde. - Am Ende ging fast alles gut, einige Ways haben noch Handarbeit gebraucht. Nun haben wir rund 650.000 Nodes, 1.500 Ways und 400 Relations mehr. Ich habe mir das Ergebnis noch gar nicht im Inspector Co. angeschaut. Von den manuellen Korrekturen abgesehen muessten die Aenderungen alle noch im Jahreswechsel-Diff gelandet sein, so dass sie am fruehen Nachmittag des 1.1. im Inspector und auch in den Geofabrik-Downloadfiles aufschlagen sollten. Jetzt hoffe ich mal, dass nicht irgendwo noch ein systematischer Fehler drin steckte ;-) Die Kreisreformen Sachsen und Sachsen-Anhalt haben wir insofern in die Daten eingebaut, als dass alle Kreiszusammelegungen beruecksichtigt wurden; die komplizierteren Aenderungen (Kreis Neu-1 bekommt die Stadt X aus Kreis Alt-2, der Rest von Alt-2 wird Kreis Neu-3 zugeschlagen) aber nicht, hier ist also im einen oder anderen Fall noch Handarbeit noetig, und zwar: Sachsen-Anhalt: Aufteilung von Aschersleben-Stassfurt auf LK Harz und Salzlandkreis (beide neuen Kreise schon angelegt). Anhalt-Zerbst aufteilen und LK Anhalt-Bitterfeld neu anlegen (+Bitterfeld +Koethen). Stadt Dessau-Rosslau neu anlegen. Sachsen: sollte alles komplett sein; hier ist aber die Staatsgrenze bei Görlitz zu prüfen, eventuell sind die alten Daten hier z.T. besser als die neuen, die ab und zu auf unvermittelt die Flussuferseite wechseln. Wie gewünscht, ist der gesamte Umriss von Wesel vom Import ausgenommen worden. Dadurch sind alle Kreise, die an Wesel anschliessen, unvollständig; die vorhandenen Grenzlinien von Wesel müssen von Hand in die entspr. Relationen eingefügt werden. Wenn irgendjemand irgendwo ein Problem mit dem Import hat und partiell einen alten Zustand wiederhergestellt wuenscht - das laesst sich machen. Die Diskussion im Forum ist höchst unerfreulich, aber ich sehe mich ausserstande, neben dieser Mailingliste auch noch Foren zu verfolgen. Ich verlasse mich darauf, dass es immer ein paar Wanderer zwischen den Welten gibt, die wichtige Informationen in beide Richtungen transportieren. Eventuell brauchen wir eine Super-Wichtig-Haupt-Master-Ankündigungs-Seite im Wiki, und jeder wird gezwungen, sich da einen RSS-Feed von einzufangen ;-) so dass jeder sein gewohntes Medium (Forum, IRC, Mailingliste, Wiki, was weiss ich) weiter nutzen kann, aber alle wenigstens diese Ankuendigungsseite lesen. Ich mache mir allerdings keine Illusionen - auch mit so einer Ankuendigung haette es noch Beschwerden gegeben. Und wer ist dann zustaendig, um wichtige Infos der Englaender auf die Super-Wichtig-Haupt-Master-Ankuendigungs-Seite zu schreiben? Da brauchen wir wieder die Wanderer... So, jetzt bin ich gespannt, wie die Sache aussieht, wenn sich der Staub gelegt hat. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
John07 schrieb: http://forum.openstreetmap.org/viewtopic.php?pid=12770#p12770 Weil ich eh gerade schlechte laune habe - Haben die leute die hier Eigentlich dachte ich ja, du hättest hier übertrieben. Oh, ich werde mich nie wieder über Diskussionskultur hier beschweren. Dort geht's fast so zu wie in den Heise-Foren. Ein frohes Neues! -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?Kreisgrenzen-Import / gelöschte Nodes
Johann H. Addicks addi...@gmx.net wrote: Oh, ich werde mich nie wieder über Diskussionskultur hier beschweren. Dort geht's fast so zu wie in den Heise-Foren. Ähm ja, wie war das mit der Realnamendiskussion auf der Mailingliste... The History repeating... Warum zum Teufel denken die Leute Webforen seien besser als Mailinglisten oder Usenetgruppen? Ich werd alt. n8 Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Quality - Frage zur Bestimmung d er Größe eines Places - Tag?
hi, also radium gibt es nicht, außer latein vielleicht? und, bei anderen dingen schreiben wir auch immer name= und nicht highway_name= amenity_name= etc. meiner meinung nach ist ein standardisiertes tag über alle ways und nodes sinnvoll. weiterhin ist die information redundant! wenn ich einen node mit place=X habe, dann brauche ich die info place nicht auch noch im namens-tag des selben nodes! kartenzeichnern wird es unheimlich schwer gemacht, weil sie überall nach anderen tags suchen müssten! ps: habe einige places in deutschland gefunden, die mit place_name= getaggt sind. finde ich nicht gut! es gibt in deutschland ~51.000 places, davon sind nur 450 mit place_name keys versehen. also weniger als 1%. pps: amenity_name gibt es in deutschland z.b. gar nicht! ciao gerhard Am Mittwoch, den 31.12.2008, 21:51 +0100 schrieb Marcus Wolschon: Am 31.12.08 schrieb GS gerhardschw...@yahoo.de: hi, mir ist die idee gekommen, für places ein tag in die db einzugeben, sodass wir dann die größe des place in etwa wissen. das ist natürlich freiwillig und kann von denjenigen benutzt werden, denen meine radien im augenblick nicht passen. ich selbst eingeschlossen :-) ich dachte an radius=1.3 oder diameter=2.6 Ich halte place_radium für besser, damit man sieht daß es sich der Radius bzgl des place-tags ist und nicht von irgendwas anderem (z.B. highway=mini_roundabout;radius=10). Macht die Suche einfacher, da man weniger unpassende rausfiltern muss. [in km] natürlich ist das dann immer noch kreisförmig, aber besser als das, was wir nun haben. ich würde mein programm dann trimmen, auf diese infos zu hören! und es könnte bestätigte radien in einer anderen farbe eintragen und die daten als gesichert oder so kennzeichnen. markus hatte den vorschlag gemacht, eine art siedlungsgrenze einzuführen, die alle gebiete (wohn, industrie etc.) umfasst. ist aber deutlich aufwendiger... ich weiß, es ist keine 100% lösung, aber schon viel besser, als nun... probleme machen mehr so die aneinandergrenzenden vororte, weniger frei gelegene orte. was haltet ihr davon? Schau mal auf http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing#City da ist zusammengefasst, wie das momentag läuft. Ich halte es für eine gute Idee, für den Fall, daß man nicht mal ein ungefähres Polygon um den Ort ziehen kann. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Erfahrung Strato virtual server?
hi, hat jemand hier erfahrungen in dem bereich? vor allem würde mich interessieren, was die sterne bei prozessor power bedeuten. und wie ist das mit max ram. wie wahrscheinlich ist es, dass ich das auch bekomme... tnx gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] kleines script, um älteste dateien z u finden?
hi, ich hätte gerne ein linux script, dass mir aus einem verzeichnis und seinen unterverzeichnissen eine liste mit den files, sortiert nach datum ausgibt. ich bin sicher, da kommt ein kurzes script raus, aber soweit bin ich mit meinem linux noch nicht :-) ls -lrtR geht in die richtung, gruppiert aber nach verzeichnissen... tnx gary68 gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-es] Traducción de JOSM en Launchpad
creo que es trolebs ya que pertenece a railway Bus Trap = es un pequeo foso donde quedan retenidos los automviles (mejor dicho sus ruedas) pero no los autobuses. Yo no los he visto en Espaa y no encuentro referencia alguna en espaol. me pasa igual Trampa de autobs? Me parece bien. Siempre estaremos a tiempo para cambiarlo si sabemos como se llama en espaol. me queda el mas bsico: key = ? plugin = plugin? complemento? o extensin? Por si sirve de algo y por usar los mismos trminos, yo en QGIS lo traduzco como complemento. As lo he traducido yo en un par de cadenas, como complemento. En las pginas de la wiki traduje: tag=etiqueta; key=clave ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.1/1868 - Release Date: 29/12/2008 10:48 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción de JOSM en Launchpad
residential = urbana ? living_street = calle residencial ? Hay algo que falta en OSM - 'unclassified' es teoréticamente para calles y carreteras urbanos sin conexión directa a casas, y 'residential' para pequeños calles. Tambien 'service' son calles pequeños para acceder a edificios etc, pero también se utilicen para polígonos industriales. Bus Guideway = ¿carril bus? Es no es trolébus - es un tipo de carril bus separada del carretera - los autobuses tienen control óptica o mecánica externa. Creeo que en español se llama Bus guiado http://farm3.static.flickr.com/2204/2467390168_f83452a132.jpg?v=0 http://www.youtube.com/watch?v=EtpBd-AIf2o 'tag' es de uso moderno, normalmente se usan 'key' y 'value'. La palabra 'tag' significa las dos partes. - para las Vías Pecuarias, creo que es mejor utilizar Relaciones, o quizás un modificación de 'highway'. La mayoría no tienen su uso original como uso principal contemporáneo. Cattleway no es un buen frase en ingles para estos - los caminos de trashumancia puede ser para otros animales, y es mejor creer un etiqueta general. (ver http://es.wikipedia.org/wiki/Cañadas) Las vías pecuarias de Madrid son muy variables. Veo que la Cañada Real Segoviana en Villalba es ahora un parque, otros tienen nuevos señales y mojónes (?) James -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción de JOSM en Launchpad
Emilio Gómez Fdez. escribió: Bus Trap = es un pequeño foso donde quedan retenidos los automóviles (mejor dicho sus ruedas) pero no los autobuses. Yo no los he visto en España y no encuentro referencia alguna en español. me pasa igual ¿Trampa de autobús? Me parece bien. Siempre estaremos a tiempo para cambiarlo si sabemos como se llama en español. es que trampa de autobús quizás parece el concepto contrario.. es mas bien una trampa *para* coches (un foso con un ancho que solo deja pasar autobuses que tienen la suficiente distancia entre las ruedas) pero a falta de algo mejor... me queda el mas básico: key = ? plugin = plugin? complemento? o extensión? Por si sirve de algo y por usar los mismos términos, yo en QGIS lo traduzco como complemento. Así lo he traducido yo en un par de cadenas, como complemento. yo también lo he traducido como complemento porque me parecía que ya había algunos así pero luego me he encontrado con las otras formas En las páginas de la wiki traduje: tag=etiqueta; key=clave de acuerdo clave. aunque creo que el problema viene de concepto desde el inglés cual es la diferencia entre clave, etiqueta y valor (key, tag, value) por ejemplo: en highway=primary es clave=etiqueta ó etiqueta=valor etiqueta y clave son sinónimos? etiqueta y valor son sinónimos? o son tres cosas distintas? ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción de JOSM en Launchpad
Increíble lo del 'bus trap'. Un mar de dudas me invade. A qué mente retorcida se le habrá ocurrido? Y si se queda un coche atrapado la calle queda bloqueada hasta que lo sacan? Habrá cocodrilos dentro? Si pasas a 120 la inercia te salva de quedar atrapado? etc. Feliz año 2009 Lucas De: talk-es-boun...@openstreetmap.org en nombre de sergio sevillano Enviado el: mié 31/12/2008 12:27 Para: Discusi#243; n en Espa#241;ol de OpenStreetMap Asunto: Re: [Talk-es] Traducción de JOSM en Launchpad Emilio Gómez Fdez. escribió: Bus Trap = es un pequeño foso donde quedan retenidos los automóviles (mejor dicho sus ruedas) pero no los autobuses. Yo no los he visto en España y no encuentro referencia alguna en español. me pasa igual ¿Trampa de autobús? Me parece bien. Siempre estaremos a tiempo para cambiarlo si sabemos como se llama en español. es que trampa de autobús quizás parece el concepto contrario.. es mas bien una trampa *para* coches (un foso con un ancho que solo deja pasar autobuses que tienen la suficiente distancia entre las ruedas) pero a falta de algo mejor... me queda el mas básico: key = ? plugin = plugin? complemento? o extensión? Por si sirve de algo y por usar los mismos términos, yo en QGIS lo traduzco como complemento. Así lo he traducido yo en un par de cadenas, como complemento. yo también lo he traducido como complemento porque me parecía que ya había algunos así pero luego me he encontrado con las otras formas En las páginas de la wiki traduje: tag=etiqueta; key=clave de acuerdo clave. aunque creo que el problema viene de concepto desde el inglés cual es la diferencia entre clave, etiqueta y valor (key, tag, value) por ejemplo: en highway=primary es clave=etiqueta ó etiqueta=valor etiqueta y clave son sinónimos? etiqueta y valor son sinónimos? o son tres cosas distintas? ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción de JOSM en Launchpad
2008/12/31 Emilio Gómez Fdez. ego...@terra.es: Bus Trap = es un pequeño foso donde quedan retenidos los automóviles (mejor dicho sus ruedas) pero no los autobuses. Yo no los he visto en España y no encuentro referencia alguna en español. me pasa igual ¿Trampa de autobús? No he hecho muchas traducciones al español pero siempre soy de la opinion que es mejor dejar en ingles un par de frases que inventar nuevas en caso de que evidentemente no exista una traduccion comun. Asi por lo menos le dejas a la persona que usa josm localizado la posibilidad de averiguar que es bus trap en wikipedia o a lo mejor ya lo conoce en ingles. Tambien palabras como plugin y tag creo que ya se han hecho internacionales, pero esas por lo menos hay una probabilidad de que en dos programs diferentes esten traducidas de la misma manera y el usuario no se pierda por completo. Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción de JOSM en Launchpad
Esoy de acuerdo. Yo usaría plugin o extensión mucho antes que complemento. Creo que el 'bus trap' no es algo muy conocido en ningún país y sí se podría traducir por 'trampa para coches' o 'foso anti-turismos', etc. Lucas De: talk-es-boun...@openstreetmap.org en nombre de andrzej zaborowski Enviado el: mié 31/12/2008 13:19 Para: Discusi#243, n en Espa#241,ol de OpenStreetMap Asunto: Re: [Talk-es] Traducción de JOSM en Launchpad 2008/12/31 Emilio Gmez Fdez. ego...@terra.es: Bus Trap = es un pequeo foso donde quedan retenidos los automviles (mejor dicho sus ruedas) pero no los autobuses. Yo no los he visto en Espaa y no encuentro referencia alguna en espaol. me pasa igual Trampa de autobs? No he hecho muchas traducciones al espaol pero siempre soy de la opinion que es mejor dejar en ingles un par de frases que inventar nuevas en caso de que evidentemente no exista una traduccion comun. Asi por lo menos le dejas a la persona que usa josm localizado la posibilidad de averiguar que es bus trap en wikipedia o a lo mejor ya lo conoce en ingles. Tambien palabras como plugin y tag creo que ya se han hecho internacionales, pero esas por lo menos hay una probabilidad de que en dos programs diferentes esten traducidas de la misma manera y el usuario no se pierda por completo. Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] St. Pölten
Hallo, Ich habe für St.Pölten im Wiki eine Bestandsseite über den Import angelegt (sonst finde ich mich bald selbst nicht mehr zurecht). Hier sind auch Fehler/Unschönheiten festgehalten, die noch zu verbessern sind, und so nicht vergessen werden. Zu finden: http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_plan.at/St.P%C3%B6lten#Fertig_importiert Frage: (habe offen bar etwas missverstanden oder es gibt einen Widerspruch zwischen früheren und akt. Postings) Sollen Importdaten (Straße die es überhaupt nicht gibt, oder solche die umgelegt/verändert wurden) gelöscht werden oder nicht? (habe entsprechend früherer Info diese Straßen gelöscht) lG Erich ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] [plan.at] St. Pölten
Area-Flächen, zumindest (vorerst) im Bereich Waitzendorf-Siedlung stimmen sicher nicht (Kupferbrunn endet beim Friedhof (ca. 1km östlich). Ich entflächte vorerst die sicher falschen Verknüpfungspunkte, damit eine spätere Korrektur leichter möglich ist (oder soll ich besser die areas ignorieren?) lG ErichS ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] St. Pölten
Wenn es die Importdaten nicht mehr gibt dann loeschen. Wenn die Straßen falsch liegen, dann zurecht schieben. Wenn schon alte Straßen vorhanden, dann entweder richtig hin schieben und alte Straße loeschen, oder die Tags auf die alte Straße uebertragen. Erich Schubert wrote: Hallo, Ich habe für St.Pölten im Wiki eine Bestandsseite über den Import angelegt (sonst finde ich mich bald selbst nicht mehr zurecht). Hier sind auch Fehler/Unschönheiten festgehalten, die noch zu verbessern sind, und so nicht vergessen werden. Zu finden: http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_plan.at/St.P%C3%B6lten#Fertig_importiert Frage: (habe offen bar etwas missverstanden oder es gibt einen Widerspruch zwischen früheren und akt. Postings) Sollen Importdaten (Straße die es überhaupt nicht gibt, oder solche die umgelegt/verändert wurden) gelöscht werden oder nicht? (habe entsprechend früherer Info diese Straßen gelöscht) lG Erich ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] St. Pölten
Am Wednesday 31 December 2008 16:22:15 schrieb Felix Hartmann: Wenn es die Importdaten nicht mehr gibt dann loeschen. Wenn die Straßen falsch liegen, dann zurecht schieben. Wenn schon alte Straßen vorhanden, dann entweder richtig hin schieben und alte Straße loeschen, oder die Tags auf die alte Straße uebertragen. Passt. Danke Erich Schubert wrote: Hallo, Ich habe für St.Pölten im Wiki eine Bestandsseite über den Import angelegt (sonst finde ich mich bald selbst nicht mehr zurecht). Hier sind auch Fehler/Unschönheiten festgehalten, die noch zu verbessern sind, und so nicht vergessen werden. Zu finden: http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_plan.at/St. P%C3%B6lten#Fertig_importiert Frage: (habe offen bar etwas missverstanden oder es gibt einen Widerspruch zwischen früheren und akt. Postings) Sollen Importdaten (Straße die es überhaupt nicht gibt, oder solche die umgelegt/verändert wurden) gelöscht werden oder nicht? (habe entsprechend früherer Info diese Straßen gelöscht) lG Erich ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at -- Mit freundlichen Grüssen / with best regards Erich Schubert mailto:erich.schub...@sca-gesmbh.at http://www.sca-gesmbh.at/ Dipl.Ing. Erich Schubert Schubert Computer- Automationstechnik GesmbH A-3100 St. Pölten, Hessstrasse 14 Tel: +43-2742-35 35 48-12 Fax: +43-2742-35 35 48-15 FN: FN101866d UID: ATU19774108 ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-ca] Deleting Ways
2008/12/30 Richard Weait rich...@weait.com On Tue, 2008-12-30 at 22:52 -0500, Michel Gilbert wrote: The new file with boundaries at 500 nodes is ready for an upload. But first I have to delete the current ones. Dear Michel, Bravo. The first run of the border import is a wonderful improvement, even if imperfect. Thank you for doing it. For the re-upload, may I suggest these changes? source = name of your conversion script and version # then make it available on the wiki / SVN as GPL? created_by = name of your upload script and version # then make it available on the wiki / SVN as GPL? nat_ref does not apply in my opinion. OSM expects ref for highway shields. Use a new tag like geobase:nat_ref = nat_ref# so that it is namespaced and does not break other uses of nat_ref. Use geobase:uuid = uuid# where geobase provides them. I will take your suggestions. I like when people gives good ideas. Right now, I have my two hands deleting the current boundaries. Thanks, Michel Best regards, Richard ___ 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
[Talk-ca] What we dont know from GeoBase
Hi all, I'll try to separate the ideas into separate discussions :) We don't know: 1. Is GeoBase/GeoGratis going to make available the dataset so that it can be shown as Nodes ONLY? We need this because; 1.1 - thats how any updates can happen. ... it's like a bar-code for everything that is imported, so we know how to deal with it. 1.2 For those areas of EXTREME osm coverage, is handy, because its easy to spot where new mapping work is needed. 2. Re: Road Name/Numbers Is geobase going to have all of the road names and numbers available for all the provinces? and when? We need to know this because: 2.1 StatsCAN already has available, so it could be an option to grab the raw data directly from there? 2.1.1 but does statsCAN also contain Road numbers? http://www.statcan.gc.ca/bsolc/olc-cel/olc-cel?catno=92-500-XWE〈=enghttp://www.statcan.gc.ca/bsolc/olc-cel/olc-cel?catno=92-500-XWElang=eng 2.2 For the issue of QUALITY data. we know that it not possible to manually copy the road numbers FROM geobase data TO osm data. ... but... manually copying all the other features FROM osm data TO geobase roads, is much easier. 3. Re: CanVec data Then why has this dataset been created? ... why doesnt all the data which is available ONLY on CanVec, just simply be merged into the GeoBase dataset?.. We need to know this because: 3.1 It makes it rather confusing when looking at the canvec data list, to see the chart included in geoabase = yes ... but then we dont know, which one is more accurate? ... why even include it in the CanVec list? 3.2 It makes the referencing confusing, as it's a sub-reference which is need. 3.3 Will the next version of CanVec data, only include CanVec data? .. and no GeoBase Data? I think that should cover it so far, sorry if some questions have already been answered (sometimes it takes a little while for facts to settle in). As we'd rather not be making decisions from assumptions. Cheers, Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] What we dont know from GeoBase
After that last message I sent, I thought it might be a good time to reiterate my one point of view here. My impression is that the goal of the OSM project is to create the most useful Free (capital F Free) map of the world possible. For a long time, the only real way to do this was to gather data from various user contributed sources. Tracklogs, POIs etc., and so the project grew. Much data was contributed, and many man hours went in to the maps. The result of all that effort was very good coverage in some areas. (specifically areas where those involved in the project had interest). Enter the government.. Of course all of this data already existed in various forms in various places. No one who makes a street map these days goes out and surveys all the streets involved. The data was slowly amalgamated in to larger and larger sets by governmental agencies (municipal feeding provincial, feeding federal, with additions made at each level, and data agreements allowing various attributes to be shared or not). With new technologies, and public demand, it became possible (and economically feasible) to make this data available on a national level, and to make it Free (capital F Free), which is really cool. But where does this leave projects like OSM? Do they pack up and say oh well, I guess our job is done now. We can all pack up and go home.? No. There is still much to be added to the governmental datasets that the 'man on the street' can do faster than the government. Heck, the Quebec roadset in the Geobase dataset is 6 years old! So where do we go? What we need, is a way to take advantage of the government datasets (it would be foolish to ignore them), in a way that promotes future additions to the dataset from users (in the form of filling in missing data, adding attributes, etc, etc, etc). Fortunately, the data contains a built in method for keeping track of whats what. We just need to keep the NIDs intact. Then any future releases of the government datasets can be integrated with the 'live' dataset in a way that doesn't compromise the user contributed edits (totally new roads will unfortunately have to be manually dealt with, but given that these should mostly be in areas of high interest, its unlikely that they will go unnoticed for long). Who does the above not make sense to? What problems can people point to in the above (one obvious one, is the problem of what to do with the existing data. My feeling is we need to filter out all road data with 'additional attributes', back it up, and then hope to manually add it back in (note, this would only be a major issue in areas where an effort had been made to name streets in a province that currently has no street names on geobase). Anyways, I'm off to bed. Happy new year everyone. Dale ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk-fr] Cartographier un GR. Re: nouvel inscrit
nono wrote: [...] Ensuite je m'attellerai au GR qui traverse la commune. D'ailleurs... Comment procédez-vous pour référencer un GR sachant qu'il emprunte des chemins et des routes qui elles, sont parfois déjà référencées (exemple D34). J'ai entendu parler de relation. Comment procède-t-on ? Effectivement la solution est d'utiliser une relation. Tu devrais trouver toutes les info nécessaires ici : http://wiki.openstreetmap.org/wiki/Relations/Routes Aurel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet de production de cartes scolaires, fond de cartes, etc...
Guilhem Bonnefille a écrit : Le 23 décembre 2008 15:31, Axel R. a...@esperanto-jeunes.org a écrit : C'est un peu lié à ma demande. Je pense que si certaines choses apparaissait sur les rendus, ça motiverait ceux qui mappent à utiliser ces relations/fonction. Mais je comprends que l'on ne peut pas tout mettre sur le même rendu et qu'il faut avoir un rendu par usage que l'on veut. Un pour la voiture Un pour le vélo (avec les dénivelé, magasin de location, borne vélib...) Un pour la rando à pied (les GR, les petits chemins) Un pour les scolaires (avec les lacs, forêt, délimitation administrative) Un pour les déplacements en transport en commun. Certains rendus peuvent répondre à des besoins différents, mais en surchargeant le moins possible une carte, on la rend d'autant plus lisible. Je suis mille fois d'accord : c'est parce qu'il y aura des *usages* variés, que nous aurons des utilisateurs variés et donc, potentiellement, des contributeurs. Concernant la variété de cartes, n'est'il pas possible de produire des *couches* transparentes (overlay en anglais) ? Ainsi, l'utilisateur peut afficher et mixer les informations qui l'intéressent. Techniquement tout existe dans le projet ti...@home pour faire cela, il faut juste mettre les mains dans le cambouis. signature.asc Description: PGP signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Animation vidéo 2008 par ITO world
Pour ceux qui ne lisent pas la MailingList en anglais, Peter Miller d'ITO World a mis en ligne comme promis une vidéo présentant l'avancement d'OSM pour cette fin d'année. Vous trouverez la vidéo ici: http://itoworld.blogspot.com/2008/12/openstreetmap-animation-for-2008.html http://www.vimeo.com/2598878 (si vous créez un compte chez vimeo, vous pourrez aussi charger la vidéo haute résolution). Meilleurs voeux à tous. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Animation vidéo 2008 par ITO world
Géniale cette vidéo ! 2008/12/31 Pieren pier...@gmail.com Pour ceux qui ne lisent pas la MailingList en anglais, Peter Miller d'ITO World a mis en ligne comme promis une vidéo présentant l'avancement d'OSM pour cette fin d'année. Vous trouverez la vidéo ici: http://itoworld.blogspot.com/2008/12/openstreetmap-animation-for-2008.html http://www.vimeo.com/2598878 (si vous créez un compte chez vimeo, vous pourrez aussi charger la vidéo haute résolution). Meilleurs voeux à tous. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[Talk-GB] Updated Birmingham Render
Hi, Birmingham was finished earlier this month and in celebration of this I have done two renders of all the GPX traces that have been recorded for the area since OSM began. The two versions are the same data rendered at different rates. Fast : http://blip.tv/file/1625650 Slow : http://blip.tv/file/1625734 Enjoy. Ciarán ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
