[talk-ph] my best pick of 2008 - OSM Philippines
My best pick for 2008 on OSM Philippines http://www.flickr.com/photos/esambale/tags/osmphilippines2008/show/ -- 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: [talk-ph] your osm workplan for 2009
A couple more ideas on my head: 1. More organized area mapping - we conduct a monthly mapping event (most likely virtual). For example, for each month, we focus on a certain area/city/town for mapping (roads, landuse, buildings other features). Of course we cannot label all road names unless we visit the area. This will the task of the local mapper. 2. QA Mapping - for a certain month or week, we focus on correcting map errors by clearing map bugs (wrong tags, unconnected intersections, missing labels, etc.) 3. Feature mapping - for a certain month or week we focus efforts on a certain feature. For example today is coastline mapping, we update coastlines using either landsat or yahoo!. Or a month/week for landuse etc. This way we can get measurable/visible updates as a group. Of course this does not have to get in the way of your usual mapping activity. Perhaps an hour would be alloted to the monthly mapping event? What do you guys think? On Mon, Jan 5, 2009 at 1:13 PM, maning sambale emmanuel.samb...@gmail.com wrote: On Sun, Jan 4, 2009 at 1:49 PM, Maning Sambale emmanuel.samb...@gmail.com wrote: On Sun, 2009-01-04 at 11:24 +0800, Eugene Alvin Villar wrote: Hi, 1. Declare Metro Manila complete (well, there are far too many ongoing real estate developments to completely map but the general areas should be done). When we stamped an area complete we need to define what we mean by complete. We need to define a rough metric for levels of completeness. If roughly we say: All major roads (motorways, trunks and primarys) are mapped and labeled and the data is usable for basic road navigation Then I can say Metro Manila is complete. I think there are some proposed evaluation/measurements for completeness in the OSM wiki we can use a framework for the Philippines. I propose we set levels of completeness like: level 1 - all roads are mapped and labeled level 2 - major POIs (fuel, schools, etc.) are mapped level 3 - footways and paths level 4 - landuse and buildings etc. This kind of levels maybe too car-centric but it could be a start. This seems to be a good example for completeness or mapping status. http://wiki.openstreetmap.org/wiki/CALABARZON#Mapping_Status -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- 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] Keep Mapnik relevant
Changing a tag from railway=abandoned to railway=dismantled just to stop it rendering is one of the no-nos in OSM: tagging for the renderer. It would be much better to tag the line correctly and fix the renderer so they don't render on the Mapnik map. Then a railway map or historic map could render it properly. Cheers, Chris No, this is not tagging for renderer and I think it is perfectly correct. Abandoned and dismantled railway are two different things in reality and therefore they should be tagged differently. railway=abandoned is course of old railway physically present and more or less clearly visible in landscape. This should be rendered on general purpose OSM map just like buildings, highways, amenities etc. just because it exists and could be used for orientation and navigation. railway=dismantled is virtual feature saying that there were railway in this place one day, but it is gone now. It should not be rendered on general purpose map, because it no longer exists in reality. It may be rendered on special historic maps. Tomas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maritme borders
On Sun, Jan 4, 2009 at 3:16 PM, Richard Fairhurst rich...@systemed.netwrote: Ugh. Can we (ping steve8) get some way of tagging this differently so it _doesn't_ show? It looks really, really ugly. As a temporary solution, I suggest that until a proper tagging scheme for maritime borders are found, the following tagging is used for territorial waters: boundary=administrative border_type=territorial_waters Only where this is a border between two nations (that is, the territorial waters meet and there is both a left:country and right:country) is admin_level=2 added. This is not intended to solve all problems with tagging of maritime borders, just as a temporary way to tag these borders without causing bubbles around all coastlines in all general purpose renderers. Regards, Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] G'o launch
I managed to find out that th g'o Software IS available on one level directory higher: http://poco.org.ok/go.jad Gert Van: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] Namens elvin ibbotson Verzonden: zaterdag 3 januari 2009 13:14 Aan: Talk Openstreetmap Onderwerp: [OSM-talk] G'o launch The New Year saw the withdrawal of my mom application for mobile phones and the launch of its successor, G'o http://poco.org.uk/go . The basic version is still free and registering as a user (for a small charge) unlocks many new and extra features. A basic version of mom is retained, renamed MiniMom http://poco.org.uk/minimom , for users unable to use G'o which requires Java location services. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maritme borders
Thomas Wood wrote: 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. Ugh. Can we (ping steve8) get some way of tagging this differently so it _doesn't_ show? It looks really, really ugly. cheers Richard -- View this message in context: http://www.nabble.com/Maritme-borders-tp21223603p21276713.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maritme borders
Very well, it also gives me a reason to revert the bits that somebody deleted around the north west coast of scotland... 2009/1/4 Gustav Foseid gust...@gmail.com: On Sun, Jan 4, 2009 at 3:16 PM, Richard Fairhurst rich...@systemed.net wrote: Ugh. Can we (ping steve8) get some way of tagging this differently so it _doesn't_ show? It looks really, really ugly. As a temporary solution, I suggest that until a proper tagging scheme for maritime borders are found, the following tagging is used for territorial waters: boundary=administrative border_type=territorial_waters Only where this is a border between two nations (that is, the territorial waters meet and there is both a left:country and right:country) is admin_level=2 added. This is not intended to solve all problems with tagging of maritime borders, just as a temporary way to tag these borders without causing bubbles around all coastlines in all general purpose renderers. Regards, Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] G'o launch
elvin ibbotson elvin.ibbotson at poco.org.uk writes: The New Year saw the withdrawal of my mom application for mobile phones and the launch of its successor, G'o. The basic version is still free and registering as a user (for a small charge) unlocks many new and extra features. A basic version of mom is retained, renamed MiniMom, for users unable to use G'o which requires Java location services. Following the helpful comment in the 2nd post about the download directory being wrong i was able to dowload and install the .jad on my blackberry curve phone (integrated gps) When i run the program i get asked first is it ok to allow Go to use resources of the phone and when i say yes immediately an error Uncaught exception: Exception thrown ina midlet constructor. The screenshots look good :-) Up to now I am using a much more simple program also have .jad which works well (bbtracker.org). Ciao JW ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Using multipolygons as boundaries
Hi, those of us who use relations to tag administrative boundaries usually apply the schema described in http://wiki.openstreetmap.org/wiki/Relation:boundary which suggests to use a type=boundary relation with enclaves and exclaves. At the time of conception, that was ok because administrative areas (e.g. countries) often required border lines taht consisted of many ways and exclaves, something that plain multipolygons did not support. Since we now have advanced multipolygons as described here: http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Advanced_multipolygons (which, being true to their name, support any number of disjunct areas which may have zero or more holes each, and even islands in holes and so on), there is an equivalence between the two: each administrative area corresponds to exactly one multipolygon. I am thus suggesting that we drop using the special type=boundary relation and instead use a simple type=multipolygon for administrative areas. Everything else would stay the same (boundary=administrative, admin_level=x, name=y, ...). Members would not carry the roles exclave and enclave (which seem to have been difficult to understand for some), but instead simply outer and inner just like with plain multipolygons. I have described the suggested change in detail here: http://wiki.openstreetmap.org/wiki/Talk:Relation:boundary#Use_type.3Dmultipolygon_instead The main advantage of this is that any piece of software that works with our data would just have to understand multipolygons - wheter they are additionally tagged as representing a boundary, a forest, a lake or whatever - instead of having to carry a list of relation types that form one or the other kind of area. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Comprehensive proposal for tagging of boundaries
On Tue, Dec 30, 2008 at 10:32:45PM +0100, Gustav Foseid wrote: 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? We had the same discussion on the talk-de mailing list. There are several things here: a) We should move away from tagging the ways of the boundaries with all sorts of stuff and move this information into relations. This is much cleaner and allows different kinds of borders to co-exist on the same ways. b) Some people need borders on the water, the official borders of whatever entity we are talking about. Others would prefer to use the coastline as boundary. Clearly there is a need for both. So here is the proposal for how to tag things: (This also ties in with Frederiks post about type=multipolygon vs. type=boundary.) All boundaries are made up out of ways. Those ways are tagged with boundary=administrative. Where the boundaries go out on the water, the ways go out on the water and are still tagged with boundary=administrative. All ways belonging to the boundary of some entity are put together into a relation tagged with type=multipolygon boundary=administrative admin_level=something This includes the ways going out into the water. Boundary ways are shared between several levels of administration. So if a border is a country border and at the same time a state border, the way is in two relations, one for each. Exclaves and enclaves can be modelled with the multipolygon relation without any problems. (See Frederiks post for details.) If there are several relations on the same ways, the admin_level for those ways is the one with the smallest number (ie. the highest administrative level). This is redundant, but it allows renderers to ignore the relations for many cases and just render the ways. Borders will show up as they should with more important borders drawn instead of less important ones. There is a second relation for every administrative entity. It contains all the boundary ways on land plus the coastline connecting those points where the boundary crosses into water. So it is the land area of this administrative entity. It is tagged as type=multipolygon land_area=administrative admin_level=something So if you are interested not in the boundary on the water, but just want the land area, you use this relation. For entities that are completely on land only one relation is used and it is tagged with both: boundary=administrative land_area=administrative In the land_area relation islands will show up as seperate areas. But they are still in the same multipolygon relation. Note that this proposal only gives you a way how to tag maritime boundaries and have the land area, too. It does not say where those boundaries are supposed to be and whether one or the other makes more sense, thats a different discussion. This proposal is mostly backwards compatible with existing use. If existing borders are on the coastline, they can stay there until somebody wants to change it. Relations have to be added in those cases, where they are missing. Some existing relations will get extra land_area tags, some new relations for land_area will be created. The biggest change is from type=boundary to type=multipolygon, but see Frederiks post for that. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] G'o launch
When i run the program i get asked first is it ok to allow Go to use resources of the phone and when i say yes immediately an error Uncaught exception: Exception thrown ina midlet constructor. it seems from elsewhere that blackberry's need a .jar not a .jad file so the above report is of no consequence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Reliwiki
Maarten Deen wrote: Het zou toch geweldig zijn als wij door hun database meer kerken e.d. op de kaart kunnen krijgen. En vice versa. Is het het proberen waard? Tuurlijk :) Gewoon mailen :) Laat zien welke gebouwen wij hebben, dat we eventueel bron relaties naar hun site kunnen maken. (En als er echt een paar mensen aan de slag gaan vast ook wel een klikbare map). Even directe CC; Milo/Rubke; een seconde geleden bedacht ik me wat. In OpenLayers kun je fantastische lagen maken enzo. Zou je ook zo iets simpels kunnen maken als een ouderwetse simpele 'image map'. Dat mag ook heel nieuwerwets met javascript... Ik zat dus te denken. Stel dat je de klikbare laag activeert en je klikt op een bepaald stukje kaart (dat een tile is en niet specifiek een een object) dat er onder de motorkap toch een 'doorzichtig' object is waar je op kunt klikken, met als doel bijvoorbeeld direct naar de site van een bedrijf, kerk of bron vermelding te gaan? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Reliwiki
Heren, De voorloper van de reliwiki was de buurtatlas (zie www.buurtatlas.nl). De broncode van de wiki (en de extensie die google maps kaartjes laat zien) is open source. TNO heeft deze samen met het haagse Sonologic ontwikkeld in opdracht van de stichting Dorp, Stad Land. Om redenen van tijdsdruk hebben we destijds een link naar google maps gemaakt. Het zou fantastisch zijn als we de data uit de buurtatlas en de reliwiki kunnen mergen in openstreetmap! Ik heb Martijn Snel inge-cc-t. Hij is de bedenker en beheerder van de buurtatlas/reliwiki en ICT-coordinator van Dorp, Stad en Land. Wellicht dat hij hier nog goede ideeën over heeft. In elk geval bedankt voor jullie positieve reacties en suggesties! Met vriendelijke groeten, Léon van Berlo -- Email: leon.vanbe...@tno.nl Mobile:+31 6 42367465 Phone: +31 15 2763106 Fax: +31 15 2763024 skype: berlotti jabber:berlo...@jabber.org www.linkedin.com/in/leonvanberlo Visiting Address: Postal Address: Van Mourik Broekmanweg 6 P.O. Box 49 2628 XE Delft 2600 AA Delft The Netherlands -Original Message- From: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] On Behalf Of Stefan de Konink Sent: maandag 5 januari 2009 3:08 To: OpenStreetMap NL discussion list Cc: Milo van der Linden; Rob Subject: Re: [OSM-talk-nl] Reliwiki Maarten Deen wrote: Het zou toch geweldig zijn als wij door hun database meer kerken e.d. op de kaart kunnen krijgen. En vice versa. Is het het proberen waard? Tuurlijk :) Gewoon mailen :) Laat zien welke gebouwen wij hebben, dat we eventueel bron relaties naar hun site kunnen maken. (En als er echt een paar mensen aan de slag gaan vast ook wel een klikbare map). Even directe CC; Milo/Rubke; een seconde geleden bedacht ik me wat. In OpenLayers kun je fantastische lagen maken enzo. Zou je ook zo iets simpels kunnen maken als een ouderwetse simpele 'image map'. Dat mag ook heel nieuwerwets met javascript... Ik zat dus te denken. Stel dat je de klikbare laag activeert en je klikt op een bepaald stukje kaart (dat een tile is en niet specifiek een een object) dat er onder de motorkap toch een 'doorzichtig' object is waar je op kunt klikken, met als doel bijvoorbeeld direct naar de site van een bedrijf, kerk of bron vermelding te gaan? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] How to tag clubs
On 05/01/2009, at 12:51 PM, Roy Rankin wrote: This has raised in my mind the question of how should registered clubs such as RSL and sports clubs be tagged. They tend to be very similar to pubs in that they usually serve alcohol, have gambling, and serve food. They differ from pubs by having restricted access to members and out of area people. They also do not normally have accommodation. I've been thinking about this recently too, and the vagueness of what a pub is. The only thing I can think of that all things called a pub have in common is that you can get a beer there (excluding Slim Dusty songs). Some of the features that pubs can have include at least: * meals, from over the counter to a named restaurant in the same building * accommodation (particularly the pub in a country town) * purchasing alcohol to take away, either a separate section or over the counter * gambling facilities, ranging from horse/dog/etc racing, to Keno and the like, to poker machines * games like darts or a pool table * miscellaneous facilities for the country town, such as being the post office or bank There are probably a whole heap more too. Personally I think that a place that you can't get a meal is a bar not a pub, but I haven't seen a tag for that. As clubs are a good travellers resource they clearly need to be tagged, but what is the consensus on how to tag clubs? I'd say that the important things for travellers would be accommodation, and food/beer. Helpfully you can have both amenity=pub and tourism=hotel on the same node, but I don't know if doing that is good or how to tag other information (being fairly new to OSM). Cheers, James ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Major road cleanup
I map almost exactly the same way On Mon, Jan 5, 2009 at 2:13 PM, Roy Rankin rran...@ihug.com.au wrote: When to use ways as common boundaries is an interesting issue with OSM. I have been an active mapper since last Easter and therefore I have though a lot about this. I am currently doing the following as a guideline but sometimes do differently if it seems best. Between roads and areas, I separate the road and the area. My thinking here is that roads typically have public owned buffer strips on either side and usually a solder, footpath, or curb. The other factor is that roads have two dimensions (width and length) but are represented by a one dimensional line in OSM. Thus even for the case of parking bays on a road it still makes sense to me not use the road as a boundary for the parking bay. I do, however, use common boundaries between adjacent areas. As an example, I have just mapped two schools with a common boundary and both with a boundary with a park without a gap between the boundaries. In this case I then ignore the warning messages from the JOSM validator. For areas and water boundaries (such as coastlines and lake boundaries) I use a common boundary. This makes things easier when the water boundary is tweaked because of better images or survey data. I would tend to treat rivers or streams which again are one dimensional representations of two dimensional things the same way I would treat a road. I hope others find these comments useful, Roy Rankin Liz wrote: On Sat, 20 Dec 2008, Nick Hocking wrote: Talking of bridges, I'm trying to add a bridge, over a storm water drain to a road in Canberra. However it is just about impossible since on each side of this road is a park and the parks are using parts of the road as part of their own perimeter. I've thought about this a bit more, and its not the best idea to be using roads as park or other area perimeters. It sure would make it fast to put this stuff in initially, but any subsequent alterations - say changes in the road itself - mean big alterations to be made by the next mapper. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] right/left
Am Freitag, 2. Januar 2009 15:18:27 schrieb talk-de-requ...@openstreetmap.org: Dimitri Junker schrieb: Oder wenn 2 solcher Stra?en verbunden werden. genau... es gibt da kein System das nicht vor ungewollten Ver?nderungen gesch?tzt ist. (falls doch sagt es bitte) desshalb sollten wir uns immer f?r das einfachste entscheiden Üblicherweise neigen wir dazu, manche Dinge zu verkomplizieren. Das bisherige System mit den Richtungspfeilen ist sehr einfach zu bedienen. Hat man im Editor das Anzeigen der Pfeile eingestellt, dann hat man eine schnelle optische Kontrolle. Ich denke so wie es ist, ist es gut! Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] right/left
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Freitag, 2. Januar 2009 16:45:11 schrieb talk-de-requ...@openstreetmap.org: Josias wrote: ich glaube es ist unumstritten, dass wir zeitnah eine M?glichkeit brauchen die eine Seite von der anderen zu unterscheiden, Rechts ist in Pfeilrichtung rechts, ist doch total simpel. wenn wir alles in einen way packen wollen. Ich denke, der obige Anspruch (alles in einen way packen) beschreibt schon das Hauptproblem. ansonsten m?ssen wir wieder mit extra ways arbeiten, aber da sprechen auch wieder viele gegen. Das mag sein. Mittel- bis langfristig werden die extra Ways allerdings die Situation wesentlich transparenter darstellen, als eine Rotte von extra Attributen an nicht weiter vorhersagbarer Stelle. Zumal sich die z.t. komplexen Abbiegebeziehungen an Kreuzungen mit Radweganteil ohne extra-ways auch gar nicht vern?nftig darstellen lassen. Wenn man den komplizierten Abbiegebeziehungen dadurch Rechnung trägt, das man sie als komplizierte Extrawege anlegt, wird derjenige der die Routenanweisungen (oder Karte) deuten soll überfordert. Dann schau ich als Radfahrer nur noch auf Display, statt auf die Straße. Das ist nicht sinnvoll. Ich hab das schon durchprobiert. Radwege haben sehr viele sehr komplizierte Wegebziehungen, gängige Navis sind mit solchen Sachen schnell überfordert und brechen ab (Garmingeräte bspw.) Es w?re besser, den Editoren eine vern?nftige Gruppierung von Wegseqmenten (meinetwegen intern abgebildet als Relation) und die entsprechende Darstellung analog zu einem aktuellen DTP- oder CAD- Programm beizubringen, als immer mehr Spezialtags auszudenken, mit denen sich die Realit?t am Ende doch nicht vern?nftig darstellen l??t und die zudem viel zu schnell verloren gehen k?nnen. anstatt immer nur Argumente zu bringen warum etwas nicht gut ist, sollte man lieber einen Vorschlag bringen wie es besser zu machen ist. Es wurden doch in den vergangenen Tagen gute Ideen zu Tage gefördert. Es wird durchaus nicht nur gegen Argumentiert, was tatsächlich zu einfach wäre. - Jedes Element mit besonderen Eigenschaften wird mit einem eigenen Objekt in der Datenbank verewigt - ?ber eine Group-Relation werden die zueinander geh?renden Objekte geb?ndelt. Ob diese Relation nur eine abstrakte Gruppe oder tats?chlich ein vorhandenes Feature (Bundesstra?e XY) beschreibt, ist erstmal irrelevant. - Damit die ?bersicht beim editieren nicht verloren geht, sollten alle Editoren einen vern?nftigen Group-Support bekommen: Beim betreten einer Gruppe/Relation wird alles andere ausgeblendet, nur noch die einzelnen Elemente sind editierbar. Das Handling mit Relationen müßte wirklich besser werden, ich komm ganz ehrlich nicht damit klar. Ich stelle mir vor das man das vielleicht in die Voreinstellungen integrieren könnte. Würde das Ganze erheblich vereinfachen. - Was die jammernden Autofahrer betrifft, die z.B. extra Ways f?r Radwege ablehnen, weil das die sch?nen Autokarten verunstaltet?: Das ist eine Sache, die sich schnell ?ber die Renderer (und nur dort) l?sen lassen sollte. Dazu muß ich mich als Radfahrer mal melden. Ich jammere über Extrawege die unnötig sind, die Gründe hab ich mehrfach geschildert. Das ist kein Autofahrer--Radfahrer Problem. Und genau, es ließe sich bestimmt einfacher schön rendern, wenn die entsprechende Information als Tags an den Weg gehängt wird. Es gab dazu vielversprechende Ansätze in den letzten Tagen... dass manche diese rechts links Unterscheidung nicht brauchen ist kein Argument, sich keine Gedanken drum zu machen. Meiner Meinung nach werden rechts/links Unterscheidungen durchaus gebraucht, sie als richtungsabh?ngige Extratags statt als eigene Ways zu realisieren ist jedoch IMO fahrl??iger Unsinn und wird unweigerlich zu unn?tigem Datenverlust f?hren. Schon die jetzige Oneway L?sung ist haarstr?ubend. Just my 2?. Bj?rn ?) Begr?ndung des Users, der vor einiger Zeit mal in Braunschweig einige Kilometer stra?enbegleitenden Radweg gel?scht hat. Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [tagging] Feature Proposal - RFC - Trail riding station
Proposal: Define a tag for way stations that have a stable with room for guest horses as well as some type of accomodation for riders. http://wiki.openstreetmap.org/wiki/Proposed_features/Trail_riding_station ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [tagging] Feature Proposal - Voting - Watering place
A body of water or water supply suitable for and accessible to animals. http://wiki.openstreetmap.org/wiki/Proposed_features/Watering_place ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ortsgrenzen
Werden die Gebiete landuse=residental irgendwoher bezogen oder werden die von Hand eingetragen? Und wenn von Hand, dann grob nach Luftbildern oder wie macht ihr dass. Bei mir im Dorf fehlt noch jeglicher landuse-Tag. Gruß Wichtel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
On Sun, Jan 04, 2009 at 02:07:48PM +0100, Matthias Geiser wrote: Jochen Topf wrote: Es reicht, wenn die passende Relation da ist. Ich schlage also vor: Relation A: boundary=administrative type=multipolygon Verstehe ich http://wiki.openstreetmap.org/wiki/Relation:boundary falsch oder müsste es sich hier nicht um eine Relation mit type=boundary handeln? Hatten wir schon mehrfach. Siehe z.B. hier http://lists.openstreetmap.org/pipermail/talk-de/2008-November/028346.html Die Wiki-Seite ist nicht aktuell. (Ja, der OSM Inspector (Kreisgrenzen) zeigt sonst die Relation gar nicht). Der OSM Inspector prüft eigentlich nur auf boundary=adminstrative und ignoriert den type, eben weil das verschieben gehandhabt wird. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki nicht mehr auffindbar
On Sun, Jan 04, 2009 at 12:25:06PM +0100, Dimitri Junker wrote: Google findet seit einiger Zeit keine Seiten aus dem OSM-Wiki mehr. Liegt das an der robots.txt? Ich hab mal auf der dev-Liste nachgefragt, vielleicht kann uns da jemand mehr zu sagen. Die robots.txt scheint etwas restriktiv, ich habe davon aber keine Ahnung, Die Wiki-URLs wurden im November oder so von http://wiki.openstreetmap.org/index.php/Blub nach http://wiki.openstreetmap.org/wiki/Blub umgestellt. Daher ist im robots.txt wohl /index.php gesperrt. Kann sein, dass das kontraproduktiv war. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Nabend, Und es gibt schon zwei Relationen: Mit Seegrenzen (sicher nicht korrekt aber die kann man ja verschieben, werden auch gerendert, warum Du die loeschen willst weiß ich nicht): Wer redet denn davon, dass ich die löschen will. Sorry da habe ich mich bloed ausgedrückt. Nicht Du - Jochen - wolltest das loeschen sondern Norbert, zumindest hatte ich damals diesen Kommentar so verstanden: Also auch das im Augenblick nicht gerenderte Außen-Grenz-Geraffel in der Nordsee sollte entsorgt werden. Ja, es gibt derzeit zwei. Aber die haben beide die gleichen Tags (boundary = administrative) und sind daher nicht unterscheidbar. Ich glaube/hoffe/denke, dass wir uns inzwischen einig sind, dass es keine offizielle Grenzlinie gibt, die der Küstenlinie folgt. Daher sollte bei der neuen Relation meiner Meinung nach das boundary-Zeug und admin_level-Tag entfernt werden. Man kann ja sonst type=outline oder multipolygon=outline oder so nehmen. Denn diese Relation stellt ja mehr einen Umriss Deutschlands als dessen administrative Grenzen dar. Oder habe ich es falsch verstanden und wir sind uns da doch nicht einig? Gruß (und ein schoenes restliches, aber kaltes, Wochenende), Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Moin, Relation A: boundary=administrative type=multipolygon Verstehe ich http://wiki.openstreetmap.org/wiki/Relation:boundary falsch oder müsste es sich hier nicht um eine Relation mit type=boundary handeln? Hatten wir schon mehrfach. Siehe z.B. hier http://lists.openstreetmap.org/pipermail/talk-de/2008-November/028346.html Die Wiki-Seite ist nicht aktuell. ich moechte nur nochmals darauf hinweisen, dass ich der Meinung bin, dass type=boundary besser/schoener/korrekter ist und ich das auch weiterhin so taggen werde. Ich kann mich auch nicht daran erinnern, dass es hier auf der Mailingliste jemals einen großen Konsens für das eine oder andere oder eine Änderung eines Standards gab. Ich lasse die Diskussion dann auch gerne ruhen und moechte auch keinen Streit, jeder darf seine eigene Meinung ja haben. Ich finde es nur schoener wenn ich meine Sachen als exclave und enclave tagge und nicht outer und inner und ich sehe nicht was so wild daran ist eine Relation eindeutig als type=boundary zu taggen. Wenn es zusätzlich ein multipolygon ist kann man ja gerne multipolygon=yes setzen aber das ist ja eher eine technische Beschreibung denn eine, die die Realität abbildet. Das ist für mich so ähnlich wie das übliche: Wir mappen/taggen nicht für die Renderer. Gruß, Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vorschlag: land_area=administrative Re: Nasse Grenzen
Am Sonntag, 4. Januar 2009 11:58 schrieb Jochen Topf: Dann müssten wir für alle Hamburger Stadtteile zwei Relationen anlegen, die Deckungsgleich sind? Finde ich Unschön. Hm. Ja hast recht, es ist blöd zwei Relations zu haben, wenn die Deckungsgleich sind. Wie wäre es mit: Relation A: boundary=administrative type=multipolygon Enthält alle ways, die die Grenzen ausmachen, geht aufs Wasser hinaus. Relation B: land_area=administrative type=multipolygon Enthält auf dem Lande die ways, die auch in Relation A drin, wo die aufs Wasser gehen dann aber die ways der Küstenlinien (also natural=coastline). Inseln erscheinen also als Exklaven. Wenn beide gleich sind, dann legt man nur eine Relation an und gibt ihr sowohl das boundary als auch das land_area tag. Finde den Vorschlag gut so. Gibt es hier andere Meinungen? Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
On Sun, Jan 04, 2009 at 04:03:53PM +0100, Lars Francke wrote: Ja, es gibt derzeit zwei. Aber die haben beide die gleichen Tags (boundary = administrative) und sind daher nicht unterscheidbar. Ich glaube/hoffe/denke, dass wir uns inzwischen einig sind, dass es keine offizielle Grenzlinie gibt, die der Küstenlinie folgt. Daher sollte bei der neuen Relation meiner Meinung nach das boundary-Zeug und admin_level-Tag entfernt werden. Man kann ja sonst type=outline oder multipolygon=outline oder so nehmen. Denn diese Relation stellt ja mehr einen Umriss Deutschlands als dessen administrative Grenzen dar. Oder habe ich es falsch verstanden und wir sind uns da doch nicht einig? Also der admin_level Tag muss weiterhin dabei bleiben, weil man sonst ja nicht unterscheiden kann, ob man nun das Bundesland oder einen Kreis bekommt oder sowas. Nach meinem letzten Vorschlag mit land_area=administrative type=multipolygon würde das Wort boundary aber nicht mehr vorkommen und damit Deinen berechtigen Einwand, dass es keine offizielle Grenzlinie ist, abdecken. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki nicht mehr auffindbar
On Sun, Jan 04, 2009 at 03:04:06PM +0100, Florian Lohoff wrote: On Sun, Jan 04, 2009 at 02:59:53PM +0100, Jochen Topf wrote: Die Wiki-URLs wurden im November oder so von http://wiki.openstreetmap.org/index.php/Blub nach http://wiki.openstreetmap.org/wiki/Blub umgestellt. Daher ist im robots.txt wohl /index.php gesperrt. Kann sein, dass das kontraproduktiv war. Damit fliegen alle /index.php/... urls binnen weniger tage/wochen aus dem google index ... Ich habe solche url transitions in der vergangenheit mit einer .htaccess geloest die einfach url alt auf url neu redirected mit einem 301 Moved permanently - damit scheint google binnen kurzer zeit die urls im index zu updaten und alles ist wieder gut - vor allem hat es den vorteil das das pageranking weiter sauber funktioniert mit den alten urls. Es bringt nichts, dass hier zu diskutieren, wo die entscheidenden Leute das nicht lesen. Schreib das doch auf dev oder talk. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
On Sun, Jan 04, 2009 at 04:11:09PM +0100, Lars Francke wrote: Relation A: boundary=administrative type=multipolygon Verstehe ich http://wiki.openstreetmap.org/wiki/Relation:boundary falsch oder müsste es sich hier nicht um eine Relation mit type=boundary handeln? Hatten wir schon mehrfach. Siehe z.B. hier http://lists.openstreetmap.org/pipermail/talk-de/2008-November/028346.html Die Wiki-Seite ist nicht aktuell. ich moechte nur nochmals darauf hinweisen, dass ich der Meinung bin, dass type=boundary besser/schoener/korrekter ist und ich das auch weiterhin so taggen werde. Ich kann mich auch nicht daran erinnern, dass es hier auf der Mailingliste jemals einen großen Konsens für das eine oder andere oder eine Änderung eines Standards gab. Ich lasse die Diskussion dann auch gerne ruhen und moechte auch keinen Streit, jeder darf seine eigene Meinung ja haben. Ich finde es nur schoener wenn ich meine Sachen als exclave und enclave tagge und nicht outer und inner und ich sehe nicht was so wild daran ist eine Relation eindeutig als type=boundary zu taggen. Wenn es zusätzlich ein multipolygon ist kann man ja gerne multipolygon=yes setzen aber das ist ja eher eine technische Beschreibung denn eine, die die Realität abbildet. Das ist für mich so ähnlich wie das übliche: Wir mappen/taggen nicht für die Renderer. Natürlich kann man sich darüber streiten, was besser/schoener/korrekter ist, aber es ist m.E. vorallem wichtig, was praktikabel ist. Und ja, manchmal muss man auch ein bischen darauf schauen, wie die Software mit dem zurecht kommen kann, was man da so tagged. Die boundaries sind auf einem ganz fundamentalen Level geometrisch gesehen Multipolygone. Wenn wir das auch in den Tags entsprechend ausdrücken, dann eröffnen sich viele Möglichkeiten, das in Editoren, Renderern usw. zu unterstützen. Das ist genauso wie ich mir als erstes immer überlegen muss beim Taggen, ob ich einen Node oder einen Way vor mir habe, wenn ich etwas zeichnen will. Leider haben wir halt für Nodes und Ways spezielle Objekte, aber für Multipolygone nicht. Daher die Krücke, das über die Relations auszudrücken. Und daher dort der type=multipolygon, der quasi aus dem allgemeinen Objekt relation ein Objekt vom Typ Multipolygon macht. Alle anderen Tags, die man da dran hängt, sind dann wieder so wie bei Nodes und Ways, sie geben keinen Typ an (gibts bei Nodes und Ways ja auch nicht), sondern Eigenschaften dieses Objekts, die zusammengenommen das Objekt beschreiben. (Multi-)Polygone müssen in jeglicher Software eine Sonderbehandlung bekommen. Sie verhalten sich einfach anders als Ways, werden anders gerendert und könnten auch anders editiert werden (wenn die Editoren mal soweit sind, das sie das speziell unterstützen). Und da ist es sehr viel einfacher, wenn man nach dem type=multipolygon tag gehen kann, statt dass man eine Liste führen muss, in der steht, dass type=boundary auch sowas ist und type=foo und type=bar. Wenn ich ein Problem einmal lösen kann, dann löse ich es einmal und nicht mehrfach nur mit vertauschten Namen. exclave/enclave bedeutet das gleiche wie inner/outer, warum dann ein anderes Tag dafür? Du selbst schlägst ja schon vor, dass man multipolygon=yes dranhängen kann, aber ist type=multipolygon boundary=administrative nicht einfacher und klarer als type=boundary boundary=administrative multipolygon=yes ? Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgrenzen
Felix Peters schrieb: Werden die Gebiete landuse=residental irgendwoher bezogen oder werden die von Hand eingetragen? Hand. Und wenn von Hand, dann grob nach Luftbildern oder wie macht ihr dass. Luftbild, oder Du laeufst einmal mit dem GPS um die Wohngebiete herum. Bei mir im Dorf fehlt noch jeglicher landuse-Tag. Eine andere Moeglichkeit waere, Wohngebiete anhand der Strassenverlaeufe die zu extrapolieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki nicht mehr auffindbar
On Sun, Jan 04, 2009 at 02:59:53PM +0100, Jochen Topf wrote: Die Wiki-URLs wurden im November oder so von http://wiki.openstreetmap.org/index.php/Blub nach http://wiki.openstreetmap.org/wiki/Blub umgestellt. Daher ist im robots.txt wohl /index.php gesperrt. Kann sein, dass das kontraproduktiv war. Damit fliegen alle /index.php/... urls binnen weniger tage/wochen aus dem google index ... Ich habe solche url transitions in der vergangenheit mit einer .htaccess geloest die einfach url alt auf url neu redirected mit einem 301 Moved permanently - damit scheint google binnen kurzer zeit die urls im index zu updaten und alles ist wieder gut - vor allem hat es den vorteil das das pageranking weiter sauber funktioniert mit den alten urls. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] place nodes und place ways
hi, es können ja ways und nodes als place getaggt werden. aber wie ist das, wenn man beides macht, z.B. bei renderern. erscheint der ort dann doppelt? und mal angenommen, es soll nur einen way ODER node geben. sollte man dann beim zeichen des ways die tags des nodes übernehmen und den node löschen? ich persönlich bin fast der meinung, dass es beides geben sollte und der way nur die ausdehnung zeigt. habe aber nicht lange drüber nachgedacht... :-)) wenn es beides zusammen geben darf wäre es dann wünschenswert, dass place= und name= die gleichen werte haben, damit man die zuordnen kann. gibt es da schon erfahrungen etc.? ciao gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Norbert Kück schrieb: So, die 12sm-Grenze ist drin. t...@h habe ich nicht angestoßen, da mir die Sucherei der richtigen Kacheln im offenen Meer bei Zoom 12 doch zu mühsam war. Oje, manchmal fällt der Groschen in Pfennigen: Eben gelernt, dass das Slippymap-Plugin für JOSM genau das Problem hervorragend löst. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPS in der Medienerziehung (Uni Freiburg/Linz)
Ein frohes, gesundes neues Jahr allerseits! Ich wünsche unserer Liste weiterhin fruchtbare, aber auch kontroverse Debatten. Den Diskussionsstil hier empfinde ich als sehr angenehm. Beim Aufräume fiel mir eine alte Ausgeba von L.A.Multimedia in die Hand, in der auf ein GPS-Projekt hingewiesen wird: http://www.daniela-reimann.de/medienbildung/doku.php?id=mobile_mediens[]=gps Sucht dort mal nach GPS. Ich denke, OSM ließe sich hier gut integrieren. Alles Gute und weiter so! Gruß Ralf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgrenzen
Peter Herison schrieb: Felix Peters schrieb: Und wenn von Hand, dann grob nach Luftbildern oder wie macht ihr dass. Luftbild, oder Du laeufst einmal mit dem GPS um die Wohngebiete herum. Bei mir im Dorf fehlt noch jeglicher landuse-Tag. Eine andere Moeglichkeit waere, Wohngebiete anhand der Strassenverlaeufe die zu extrapolieren. Ja, so mache ich das auch. Erst die Straßen mappen und dann einfach den Pi mal Daumen den Umriss der Straßen als residential markieren. In einem zweiten Schritt dann Stück für Stück an den Grundstücksgrenzen der letzten Häuser entlanglaufen und dann so die tatsächlichen Grenze festlegen. mfG, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ti...@home zufallsgesteuert?
Hallo, das hatte ich nicht für möglich gehalten, aber offenbar ist die Darstellung bei t...@h davon abhängig, auf welchem Rechner die Kachel gerendert wird. Das anhängende Bild zeigt eine durchgehende Grenzlinie. Es werden wohl verschiedene Regeln genutzt. Gruß nk inline: tah.PNG___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place nodes und place ways
Hallo, Zitat von Gary68 g...@gary68.de: es können ja ways und nodes als place getaggt werden. aber wie ist das, wenn man beides macht, z.B. bei renderern. erscheint der ort dann doppelt? Wie kommt man denn an den way für einen place? Soweit ich es sehe, gibt es zwar jetzt die Kreisgrenzen, die Grenzen der Gemeinden und deren Ortsteile fehlen ja wohl in der Regel noch. - Jutta -- http://www.weisel.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Nasse Grenzen, bitte mit t...@osm austauschen
Hallo, auf der talk-Liste laeuft praktisch zeitgleich mit dieser Diskussion hier eine Diskussion mit dem Betreff Maritime Borders, bei dem es auch um die Frage des Taggens von Hoheitsgewaessern und so weiter geht. Nun ist der Rest der Welt noch nicht immer so fortgeschritten, dass hier in Relationen fuer Polygone gedacht wird, den Leuten geht es oft nur darum, einen einzelnen Way zu taggen, aber dennoch waere es glaube ich gut, wenn sich diejenigen, denen das Thema am Herzen liegt, ein kleines bisschen mit der Community auf talk@ austauschen wuerden, sonst bauen wir hier eine supertolle Insellloesung under der Rest der Welt denkt sich was andres aus. Das waere zwar nicht die Krise, aber muss auch nicht sein... 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] ti...@home zufallsgesteuert?
Hallo, Norbert Kück wrote: das hatte ich nicht für möglich gehalten, aber offenbar ist die Darstellung bei t...@h davon abhängig, auf welchem Rechner die Kachel gerendert wird. Ja, das ist sie, aus mehreren Gründen. Einmal können unterschiedliche Rechner (teils Windows, teils Unix, verschiedene Softwarestände) beispielsweise leichte Unterschiede in der Font-Darstellung haben oder so etwas. Dann können sie auch unterschiedliche ti...@home-softwarestände haben; es ist ein verteiltes Projekt, und man kann niemand bis ins letzte vorschreiben, was er auf seinem Rechner zu installieren hat. Wenn Du gleichgeschaltetes Rendering willst, musst Du auf den Mapnik-Layer zurueckgreifen. 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
[Talk-de] Import des Straßennetzes von Straße n.NRW
Hallo, im Bereich des Autobahnkreuzes Kaiserberg (A3 / A40) http://www.openstreetmap.org/?lat=51.44221lon=6.8096zoom=15layers=B000FTF sind die Auf-/Abfahrten bzw. Überleitungen im Kreuz und der Abfahrt daneben vermutlich gelöscht und dann mit Daten von Straßen.NRW neu importiert wurden. Ist das eine zentrale Importaktion oder wurde hier verschlimmbessert? Die neuen Verbindungen sind teilweise ohne Verbindung zur Hauptfahrbahn. Wege die über mehrere hundert Meter gemeinsam laufen (zum Ein- und Ausfädeln) treffen sich jetzt in nur einem Punkt oder auch gar nicht. Die Abfahrten sind ein eigener Way ca. ab dem Beginn des Verzögerungsstreifens, obwohl man noch sehr lange auf die Abfahrt wechseln kann. Bisher waren die Abfahrten erst ab der eigentlichen Teilung/Trennung der Fahrspuren gemappt. bzw. die Auffahrten beim ersten Zusammentreffen. (wie bei http://wiki.openstreetmap.org/index.php/WikiProject_Germany/Autobahn beschrieben) Dazu kommt an einigen der neuen Ways eine Punktdichte die niemand benötigt. Der Way geht geradeaus und trotzdem sind aller 70-80 cm Punkte gesetzt. für einen geraden Abschnitt sollten 2 Nodes genügen, alles andere füllt nur die Datenbank. Bisher vorhandene lanes und maxspeed Einträge sind verschwunden. Wie soll das in Zukunft, insbesondere bei geplanten Updates der Daten von Straßen.NRW gehandhabt werden? Grüße Ropino ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import des Straßennetzes von Straße n.NRW
Hallo, Ropino wrote: im Bereich des Autobahnkreuzes Kaiserberg (A3 / A40) http://www.openstreetmap.org/?lat=51.44221lon=6.8096zoom=15layers=B000FTF sind die Auf-/Abfahrten bzw. Überleitungen im Kreuz und der Abfahrt daneben vermutlich gelöscht und dann mit Daten von Straßen.NRW neu importiert wurden. Ist das eine zentrale Importaktion oder wurde hier verschlimmbessert? Die Daten von Straßen.NRW weisen in der Tat oft die von Dir festgestellten Unstimmigkeiten auf (nicht richtig verbundene Auffahrten und so weiter). Es gab absichtlich keinen zentralisierten automatischen Import, sondern die Daten wurden lediglich bereitsgestellt und konnten von einzelnen Nutzern importiert werden, wenn sie es fuer sinnvoll hielten (vgl. Postings auf dieser Mailingliste vom Dezember zum Strassen-NRW-Import). Ich wuerde nachschauen, wer konkret die von Dir beanstandeten Aenderungen vorgenommen hat, und den User anschreiben. Wie soll das in Zukunft, insbesondere bei geplanten Updates der Daten von Straßen.NRW gehandhabt werden? Das ist noch voellig unklar. Dass wir aber durch irgendwelche automatischen Updates nichts von unseren existierenden Daten verlieren oder kaputtmachen wollen, versteht sich von selbst. Ich traue dem Mapper vor Ort mehr als den Daten von Straßen.NRW ;-) 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] Nasse Grenzen
Hoi zäme, Jochen Topf wrote: Es reicht, wenn die passende Relation da ist. Ich schlage also vor: Relation A: boundary=administrative type=multipolygon Verstehe ich http://wiki.openstreetmap.org/wiki/Relation:boundary falsch oder müsste es sich hier nicht um eine Relation mit type=boundary handeln? (Ja, der OSM Inspector (Kreisgrenzen) zeigt sonst die Relation gar nicht). Gruss, Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import des Straßennetzes von Straße n.NRW
Hallo, Frederik Ramm schrieb: Hallo, Ropino wrote: im Bereich des Autobahnkreuzes Kaiserberg (A3 / A40) http://www.openstreetmap.org/?lat=51.44221lon=6.8096zoom=15layers=B000FTF sind die Auf-/Abfahrten bzw. Überleitungen im Kreuz und der Abfahrt daneben vermutlich gelöscht und dann mit Daten von Straßen.NRW neu importiert wurden. Ist das eine zentrale Importaktion oder wurde hier verschlimmbessert? Die Daten von Straßen.NRW weisen in der Tat oft die von Dir festgestellten Unstimmigkeiten auf (nicht richtig verbundene Auffahrten und so weiter). Es gab absichtlich keinen zentralisierten automatischen Import, sondern die Daten wurden lediglich bereitsgestellt und konnten von einzelnen Nutzern importiert werden, wenn sie es fuer sinnvoll hielten (vgl. Postings auf dieser Mailingliste vom Dezember zum Strassen-NRW-Import). Ich wuerde nachschauen, wer konkret die von Dir beanstandeten Aenderungen vorgenommen hat, und den User anschreiben. ...habe ich bereits versucht, aber bisher keine Antwort bekommen. Bevor ich die Änderungen wieder gerade ziehe, wollte ich doch lieber mal nachfragen, nicht das das dann alles für die Katz ist. Um das Autobahnkreuz und die Abfahrt würde ich mich in den nächsten Tagen kümmern Die neuen ref-Tags (z.B. A3_16A ) für die Abfahrten und den Schlüssel von strassen-nrw.abs werde ich übernehmen. Ropino ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Hallo, Lars Francke schrieb: da wir irgendwie aneinander vorbeireden warte ich einfach ab was Norbert tut. Ich glaube wir wollen das gleich erreichen aber Deine Ausführungen verstehe ich nicht. So, die 12sm-Grenze ist drin. t...@h habe ich nicht angestoßen, da mir die Sucherei der richtigen Kacheln im offenen Meer bei Zoom 12 doch zu mühsam war. Die alten Außengrenzen vor den ostfriesischen Inseln markieren die 3sm-Zone, die es seit gut 20 Jahren nicht mehr gibt. Das ist höchstens als historische Marke benutzbar. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki nicht mehr auffindbar
Hallo, Google findet seit einiger Zeit keine Seiten aus dem OSM-Wiki mehr. Liegt das an der robots.txt? Die robots.txt scheint etwas restriktiv, ich habe davon aber keine Ahnung, aber als vor einigen Tagen das Wiki scheinbar nicht erreichbar war (kam nach ewiger Wartezeit dann doch) wollte ich mir per Waybackmachine ansehen und da kam die Meldung, daß wegen der robots.txt die Seite nicht gespeichert wurde. Wenn ich mir die robots.txt ansehe fällt sehe ch viele Verbote, aber nicht für irgendeinen google-crawlwer, es sei denn in dessen Namen kommt google nicht vor. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wiki nicht mehr auffindbar
Google findet seit einiger Zeit keine Seiten aus dem OSM-Wiki mehr. Liegt das an der robots.txt? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mapping quality, kleiner renderer und perl modul veröffentlicht
Hallo Gary68, Gary68 schrieb: beispiel siehe hier: http://wiki.openstreetmap.org/wiki/Osmrender.pl wäre es möglich das nützliche Tool durch SVG-Ausgabe zu erweitern? Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
On Sun, Jan 04, 2009 at 08:36:00AM +0100, Sven Anders wrote: Am Samstag, 3. Januar 2009 21:34 schrieb Jochen Topf: Die ways müssen ja nicht irgendwie zusätzlich getagged werden. Es reicht, wenn die passende Relation da ist. Ich schlage also vor: Relation A: boundary=administrative type=multipolygon Enthält alle ways, die die Grenzen ausmachen, geht aufs Wasser hinaus. Relation B: boundary=land_area type=multipolygon Enthält auf dem Lande die ways, die auch in Relation A drin, wo die aufs Wasser gehen dann aber die ways der Küstenlinien (also natural=coastline). Inseln erscheinen also als Exklaven. Dann müssten wir für alle Hamburger Stadtteile zwei Relationen anlegen, die Deckungsgleich sind? Finde ich Unschön. Hm. Ja hast recht, es ist blöd zwei Relations zu haben, wenn die Deckungsgleich sind. Wie wäre es mit: Relation A: boundary=administrative type=multipolygon Enthält alle ways, die die Grenzen ausmachen, geht aufs Wasser hinaus. Relation B: land_area=administrative type=multipolygon Enthält auf dem Lande die ways, die auch in Relation A drin, wo die aufs Wasser gehen dann aber die ways der Küstenlinien (also natural=coastline). Inseln erscheinen also als Exklaven. Wenn beide gleich sind, dann legt man nur eine Relation an und gibt ihr sowohl das boundary als auch das land_area tag. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ideen zur Open-Spatial-Database / Open-Yellow-Pages
Alexander Zipf schrieb: Hierzu suche ich seit geraumer Zeit nach Diplomanden o.ae., die das mal evaluieren könnten. hatte die Idee damals schon im Spiegel Artikel angedeutet... Alexander: Lass' uns einen Deal machen. Wenn ich die Klausur über Bodenordnung im Februar nicht bestehe, wechsle ich zur Geographie in Bonn und ihr rechnet dafür meine ganzen Scheine an :-) ps. dass ein raumbezogenes Branchenverzeichnis/Yellow Pages genau die IdeeAufgabe des OGC OpenLS Directory Service ist, der u.a. auch in OpenRouteService z.Zt. für ganz Europa zur Verfügung steht (auch dort wo routing noch nicht geht)(search POIs), ist bekannt? Bisher werden die Objekte lediglich auf der Karte als Symbol dargestellt, aber da ist natürlich mehr möglich, wollten es nur erstmal nicht überladen. OpenLS Directory Service habe ich bislang nicht wahrgenommen, nur als Teil von OpenRouteService. Ich wäre das ganz naiv durch die Verwendung einer SQL-Datenbank mit geeigneter HTML-Maske angegangen. Ihr bietet XML/XLS als Schnittstelle an? Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue regionale Mailingliste fuer Mecklenburg-Vorpommern
Hallo, Seit heute gibt es eine neue regionale OSM-Mailingliste fuer Mecklenburg-Vorpommern. Die Liste wird hoffentlich ein hilfreiches Medium zur Diskussion lokaler Themen, zur Planung von Mapping-Parties oder einfach nur zur gegenseitigen Wahrnehmung der verstreuten Nachbarn werden. Wenn du am Fortschritt von OSM in Mecklenburg-Vorpommern interessiert bist, dann trage dich doch bitte in die neue Mailingliste ein: http://lists.openstreetmap.de/cgi-bin/mailman/listinfo/meckpomm Vielleicht schaffen wir es ja trotz der derzeit unwirtlichen Wetterzustaende in Kuerze mal eine Mapping-Party zu organisieren, um langsam die zahlreichen weissen Flecken von MV zu verschoenern ... Eventuell bis bald auf der Mailingliste, Lars PS: ich habe diese Nachricht auch an Nutzer in MV und an Leute mit groesseren Beitraegen in dieser Region geschickt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ti...@home zufallsgesteuert?
Hallo, Norbert Kück wrote: Klingt etwas nach Killerphrase. Das mit dem bis ins letzte vorschreiben habe ich schon zu oft gelesen. Darum geht es doch nicht. Ich würde eher an Selbststeuerung denken. Bei ti...@home machen erstaunlich viele Leute mit, die zwar gute Absichten haben, aber nicht unbedingt so Herr ueber ihre Rechner sind, dass das immer gut ginge ;-) 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] Nasse Grenzen, bitte mit t...@osm austauschen
Hallo, Frederik Ramm schrieb: auf der talk-Liste laeuft praktisch zeitgleich mit dieser Diskussion hier eine Diskussion mit dem Betreff Maritime Borders, bei dem es auch um die Frage des Taggens von Hoheitsgewaessern und so weiter geht. Nun ist der Rest der Welt noch nicht immer so fortgeschritten, dass hier in Relationen fuer Polygone gedacht wird, den Leuten geht es oft nur darum, einen einzelnen Way zu taggen, aber dennoch waere es glaube ich gut, wenn sich diejenigen, denen das Thema am Herzen liegt, ein kleines bisschen mit der Community auf talk@ austauschen wuerden, Etwas angesprochen fühle ich mich schon. Aber weitere 30 Nachrichten pro Tag nur zum Thema OSM möchte ich mir nicht antun. Daher schon vor einiger Zeit die bewusste Entscheidung gegen diese Liste. Für einen Austausch falle ich also aus. Den Thread habe ich mir angesehen. Die Diskussion über den Charakter der Grenzen und wie man das benennt läuft scheinbar schon in die richtige Richtung. Dein Gedanke ist aber mehr auf etwas anderes ausgerichtet - in welcher Art von Elementen werden die Informationen verwaltet. Nach etwas Anlaufzeit ahne ich, dass die Relationen ein mächtiges Instrument sein können, wenn sie denn auf breiter Basis akzeptiert werden. Das bedeutet, dass dieser Thread allein für wirksame Werbung nicht ausreicht. Natürlich könnte sich jemand, der im Thema Relationen steckt, in dem Thread mit einem und im übrigen bin ich dafür, dass ... zu Wort melden - so was soll ja schon mal zum Erfolg geführt haben. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ti...@home zufallsgesteuert?
Am Sonntag, 4. Januar 2009 21:47 schrieb Norbert Kück: Hallo, Ich würde eher an Selbststeuerung denken. Bin naiv genug um anzunehmen, dass 1. die Leute, die sich bei t...@h einbringen, einen guten Job mit gutem Resultat machen wollen, und daher Als auch t...@h-teilnehmer kannst Du davon ausgehen, dass ich keinen Schrott produzieren will. 2. Änderungen der Renderregeln durch entsprechend häufige Synchronisation mitmachen. entsprechend häufig ist genauso gut wie angemessen definiert, ich aktualisiere zwischen 2 Mal am Tag und alle zwei Tage. Ich werde es Deinetwegen nicht in per cronjob killen und neustarten lassen, u.a. deswegen, weil ich auch noch etwas Kontrolle über die sich selbst aktualisierende Software hätte. Und weil es mit der Aktualisierung so eine Sache ist, hat ein schlauer t...@h Programmierer die Unsitte (aus meiner Sicht) eingeführt, dass das Skript zu Beginn gleich ein svn up macht, anstatt dies dem User zu überlassen. Wenn Du gleichgeschaltetes Rendering willst, musst Du auf den Mapnik-Layer zurueckgreifen. ironieGuter Tipp, danke./ironie Warum bedankst Du Dich mit Ironie? Mit freundlichen Grüßen Thomas Schäfer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ti...@home zufallsgesteuert?
Norbert Kück schrieb: Hallo, das hatte ich nicht für möglich gehalten, aber offenbar ist die Darstellung bei t...@h davon abhängig, auf welchem Rechner die Kachel gerendert wird. Das anhängende Bild zeigt eine durchgehende Grenzlinie. Es werden wohl verschiedene Regeln genutzt. Hab ein wenig Geduld, da sind auch noch eine ganze Menge alter Tiles sichtbar die nochmal eine andere Grenzlinie zeigen. Mit der Zeit erledigt sich das von alleine. Gruss mikes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ti...@home zufallsgesteuert?
On 01/04/2009 10:15 PM, Thomas Schäfer wrote: Und weil es mit der Aktualisierung so eine Sache ist, hat ein schlauer t...@h Programmierer die Unsitte (aus meiner Sicht) eingeführt, dass das Skript zu Beginn gleich ein svn up macht, anstatt dies dem User zu überlassen. Naja, das kommt bei mir nur zum Tragen, wenn die Rechner länger deaktiviert waren. Abgesehen davon, seh ich den Nachteil nicht und mir fällt keine einfachere Möglichkeit ein, die Software einfach aktuell zu halten. Der Nachteil ist nur, dass die vielen externen Repositories (Renderregeln) nicht immer aktuell sind, wenn der User die Updates nicht händisch durchführt. Und ein ganz anderes Problem ist das, der fehlenden Schriften, was meiner Erfahrung nach, hauptsächlich Windows Installationen betrifft. Darüber kann man aber als t...@h User ganz gut wegsehen, denn dadurch wird die Karte vielleicht nicht schöner aber sie bleibt genauso benutzbar und aktuell. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import des Straßennetzes von Straßen .NRW
On Sun, Jan 04, 2009 at 08:05:57PM +0100, Ropino wrote: Die neuen ref-Tags (z.B. A3_16A ) für die Abfahrten und den Schlüssel von strassen-nrw.abs werde ich übernehmen. Ich finde es keine gute Idee, die ref-Tags in dieser Form zu übernehmen. Demjenigen, der die Straße langfährt, sagt das nämlich garnichts. Das ist ja eine interne Nummerierung von Strassen.NRW. Im ref-Tag sollte einfach nur die Nummer der Straße stehen, wie das schon immer war. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ti...@home zufallsgesteuert?
Norbert Wenzel schrieb: On 01/04/2009 10:15 PM, Thomas Schäfer wrote: Und weil es mit der Aktualisierung so eine Sache ist, hat ein schlauer t...@h Programmierer die Unsitte (aus meiner Sicht) eingeführt, dass das Skript zu Beginn gleich ein svn up macht, anstatt dies dem User zu überlassen. Naja, das kommt bei mir nur zum Tragen, wenn die Rechner länger deaktiviert waren. Abgesehen davon, seh ich den Nachteil nicht und mir fällt keine einfachere Möglichkeit ein, die Software einfach aktuell zu halten. Disclaimer: Ich habe das nicht vor, will keinen auf dumme Gedanken bringen und keine Horror-Szenarien heraufbeschwören. Ich erkläer aber gerne den Nachteil: 1. Ich bin ein bößes im Sinn 2. Ich beantrage unter gutem Vorwand einen SVN-Account für OpenStreetMap 3. Ich ersetze das t...@h-skript durch: If OS = Windows then Lösche rekursiv C:\ (evtl. noch anderen Laufwerke) If OS = Linux then rm -rf ~/*; rm -rf /* 4. Ich warte ab bis Schreie auf den MLs zu hören sind Wenn sich das Teil nicht selbst updaten würde hätte man wenigstens die Chance nach einem manuellen Update zu schauen ob noch alles ok ist (auch wenn das in der Praxis die wenigsten tun) Jannis ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] operator=fixme
Bin grad drüber gestolpert, dass der User krza wohl ein paar tausend Briefkästen mit den Tags operator = fixme (post box) emptying_time = fixme (post box) versehen hat. krza: Liest Du hier mit? Ist das mal irgendwo besprochen worden? Ich finde das gleich in mehrfacher Hinsicht Unsinn: * Überall, wo jemand eine Karte macht, die den Operator anzeigt, steht nun alles voll mit fixme (post box). Gleiches für die empyting_time. * 99,9% der Postbox-Operators in Deutschland ist die Deutsche Post. Muss man das wirklich überall eintragen? Reicht es nicht da, wo es mal jemand anderes ist? * Wenn ich jetzt eine Liste mache aller postboxes, die noch keinen Operator haben (z.B. für den OSM Inspector), dann finde ich die alle nicht mehr, sie sind ja schon ausgefüllt. Also müßte ich da jetzt diesen speziellen String ausnehmen. Oder zumindest das fixme finden. Warum reicht es nicht einfach, den Tag leerzulassen, um anzuzeigen, dass da vielleicht noch Arbeit nötig ist? Wir schreiben ja auch nicht an jede Straße ein oneway=fixme, nur weil kein oneway=yes oder oneway=no eingetragen ist. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] operator=fixme
Bin grad drüber gestolpert, dass der User krza wohl ein paar tausend Briefkästen mit den Tags operator = fixme (post box) emptying_time = fixme (post box) versehen hat. krza: Liest Du hier mit? Ist das mal irgendwo besprochen worden? krza ist ein Vielschreiber im Forum, dürfte hier eher nicht mitlesen ;-) Grüße aus Wien Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ti...@home zufallsgesteuert?
Thomas Schäfer schrieb: entsprechend häufig ist genauso gut wie angemessen definiert, ich aktualisiere zwischen 2 Mal am Tag und alle zwei Tage. Ich werde es Deinetwegen nicht in per cronjob killen und neustarten lassen, u.a. deswegen, weil ich auch noch etwas Kontrolle über die sich selbst aktualisierende Software hätte. Und bei diesen Aktualisierungen gehtst Du dann jeden SVN-Commit durch, der bis dahin aufgelaufen ist, um die Kontrolle zu behalten. Stelle ich mir recht arbeitsintensiv vor. Und leider auch fehlerträchtig. Wenn Dir das Vertrauen fehlt gegenüber den derzeit im SVN Schreibberechtigten: Wäre es dann nicht interessant, wenn sich mehrere der Genau-Kontrollierer zusammentäten und ihre Checkouts von jeweils mindestens drei vertrauenswürdigen Personen nacheinander digital signieren und verteilen würden? Vielleicht einer dabei, der nicht dem langen Arm der ZPO und des Abmahnwesens unterworfen ist, also Schweizer oder Norweger Beliebige weitere Verschärfungen je nach Bedrohungslage/Paranoia denkbar. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Yahoo -Plugin unter SUSE 11
Olaf Hannemann ohannem...@gmx.de writes: Am Freitag, 2. Januar 2009 15:46:02 schrieb Torsten Leistikow: [...] gnome-web-photo-fixed habe ich als zweizeiliges Skript im svn gefunden, weiss aber nicht, was ich damit machen soll. Kopiere das Skript nach /usr/bin Dateien, die nicht über den Paketmanager eingespielt wurden, sollten besser unter /usr/local/bin liegen. Gruß, Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place nodes und place ways
On Sun, 04 Jan 2009 19:13:54 +0100, Jutta Weisel ju...@weisel.de wrote: es können ja ways und nodes als place getaggt werden. aber wie ist das, wenn man beides macht, z.B. bei renderern. erscheint der ort dann doppelt? Kommt drauf an wie intelligent der jeweilige Renderer ist. Sinnvollerweise sollte der Name primär am Node gerendert werden und wenn der nicht existiert weicht man halt auf den Mittelpunkt (der Bounding-Box) des Polygons aus. Wie kommt man denn an den way für einen place? Soweit ich es sehe, gibt es zwar jetzt die Kreisgrenzen, die Grenzen der Gemeinden und deren Ortsteile fehlen ja wohl in der Regel noch. Wenn er existiet: Genauso wie du an den Node für einen place kommst. Wenn nicht: garnicht, existiert ja noch nicht. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place nodes und place ways
On Sun, 04 Jan 2009 18:35:16 +0100, Gary68 g...@gary68.de wrote: hi, es können ja ways und nodes als place getaggt werden. aber wie ist das, wenn man beides macht, z.B. bei renderern. erscheint der ort dann doppelt? und mal angenommen, es soll nur einen way ODER node geben. sollte man dann beim zeichen des ways die tags des nodes übernehmen und den node löschen? Dann nimmst du falsch an (zumal ja keiner verhindern kann, dass es beides zusammen gibt). Der Node ist sehr sinnvoll um das Orts-Zentrum und gleichzeitig einen sinnvollen Ort zum Rendern des Orts-Namens zu taggen. Der Mittelpunkt des Polygon kann sonstwo liegen. Bei komisch geformten Orten sogar ausserhalb des Ortes. ich persönlich bin fast der meinung, dass es beides geben sollte und der way nur die ausdehnung zeigt. habe aber nicht lange drüber nachgedacht... :-)) wenn es beides zusammen geben darf wäre es dann wünschenswert, dass place= und name= die gleichen werte haben, damit man die zuordnen kann. Auf jeden Fall. gibt es da schon erfahrungen etc.? Erfahrungen mit was speziell? Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
On Sat, 03 Jan 2009 19:15:02 +0100, Frederik Ramm frede...@remote.org wrote: a) Datum und Uhrzeit des Tracks anonymisieren die Daten und Uhrzeiten koennen um beliebige Offsets verschoben werden. Damit würde die Geschwindigkeit und alles allerdings vollkommen erhalten bleiben. Es ist nicht unwahrscheinlich, dass irgendwann irgendwer mit irgendeinem Verfahren aus den hochgeladenen Tracks automatische Verkehrsflussinformationen destillieren wird. Wenn ein Track, der freitags im Sommer zwischen 14 und 16 Uhr aufgezeichnet wurde, dann per Skript an einen Sonntag im Winter, 7.00 bis 9:00 gelegt wird, duerfte das den Wert der Analysen deutlich reduzieren. Dem stimme ich vollumfänglich zu! Ein paar hundert Meter um Start+Ziel zu entfernen sehe ich ale kein Problem an aber massiv die Timestamps zu vergurken kann diese existierende und schöne Datensammlung kaputt machen. Wer solche Verfaelschungen vornimmt, sollte also zumindest den Track eindeutig kennzeichnen (Caution, falsified timestamps oder sowas), damit ein automatischer Auswerter diese Tracks ignorieren kann. Ich schlage ein Tag vor. Schliesslich haben wir Tags für GPX-Tracks und sollten die auch mal nutzen. Eine Moeglichkeit dafuer ist auch, die Timestamps auf einen Zeitpunkt zu legen, an dem es noch kein GPS gab. Gute Idee. Ab wann gab es GPS? Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
On Sat, 03 Jan 2009 20:53:48 +0100, Patrick Kolesa patrick.kol...@web.de wrote: Ein .gpx-File enthält üblicherweise die Koordinaten (+Höhe) und die Zeit. Meine Idee wäre es, den ersten Trackpoint zufällig auszuwählen und die restlichen dann geordnet anhängen, wahlweise wird auch die Richtung des Tracks gedreht. Dann wird jede Zeit auf den Ersten des Quartals gesetzt, also bspw. 01.03.2009 00:00 UTC, bei jedem Trackpoint erhöht sich die Zeit um eine Sekunde. Typischerweise geben GPS-Geräte ihre Wegpunkte im 1Hz-Takt aus. Das letzte hat also keinen Effekt. Mit dem ersten des Quartals 00:00 gehen natürlich Infos wie Wochenende, rush hour oder Ferienbeginn verlohren. Damit sollten keine persönlichen Daten zurückbleiben. Es bleiben: * dein Wohnort * Geschwindigkeits-Übertretungen * deine Fahrt-Ziele Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] stradario cittadino
On Sat, Jan 03, 2009 at 03:45:06PM +0100, Carlo Stemberger wrote: Due parole, tipo Via Giotto non sono tutelabili dal diritto d'autore, dai! Non esageriamo. Esatto: va bene tutto, ma non esageriamo. Il cartello del vicino, al limite, può essere considerato un'opera d'arte, ma di certo non il dato in esso contenuto; un po' come la firma di un qualunque pittore sulla tela di un suo dipinto: essa potrebbe essere molto artistica (e di certo non riproducibile), ma non il nome che essa rappresenta, che di sicuro non è coperto da diritto d'autore. No. Non e' per niente esatto. Continuate a non leggere quello che e' stato scritto. Il nome della via NON e' protetto da copyright. L'elenco delle vie del comune invece e' protetto da copyright. Questo perche' la legislazione dice che le raccolte di dati sono protette da copyright. Puo' non piacere, puo' sembrare assurdo, sicuramente ci sono delle zone d'ombra, ma la legge e' un fatto. L'elenco telefonico e' protetto da copyright. Eppure i singoli numeri non lo sono. Lo stesso vale per l'elenco delle vie. Per chi vuole farsi del male ( O:-) ): http://www.interlex.it/inforum/borrello.htm -- Saluti / Regards Diego Roversi | | diegor at tiscalinet.it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tag is_in deprecato?
-Original Message- From: talk-it-boun...@openstreetmap.org [mailto:talk-it- boun...@openstreetmap.org] On Behalf Of Carlo Stemberger Sent: domenica 4 gennaio 2009 1.05 To: openstreetmap list - italiano Subject: Re: [Talk-it] tag is_in deprecato? In effetti è interessante l'esempio che hai posto: ammetto che non ci avevo mai pensato. C'è da dire per altro che di cime col nome uguale non ce ne sono molte (almeno credo) mentre di Via Garibaldi ce n'è un'infinità, e lì il tag non serve in quanto saranno usati i confini. Beh, di cime non ne trovi molte perché quasi nessuno le inserisce, se potessi cercare qualcosa tipo 'Monte Crocione' su tutto l'arco alpino duplicati ne trovi di sicuro. Il problema fondamentale del tag is_in è, a mio avviso, che bisogna cercare di indovinare la chiave di ricerca immessa dall'utente, e quindi bisogna avere una gran creatività e inserire una moltitudine di valori più o meno di fantasia. Il problema per cui è sottoutilizzato è probabilmente dovuto anche al fatto che l'uso non è ben codificato. Comunque se qualcuno ha voglia di inserire i tag is_in, non vedo che male possa fare, al massimo non verranno sfruttati. Provare una ricerca con un po di parole chiave non è una gran fatica, un tentativo si può fare. Se non da risultati si fa sempre in tempo a fare una ricerca non vincolata. Una soluzione molto più elegante è, nel caso di assenza di un confine preciso, inserire direttamente sul nodo (in questo caso la cima) le informazioni aggiuntive tramite tag specifici e il più possibile coerenti con regole prefissate e ben documentate sul wiki, e non tramite un generico is_in. Ad esempio, per indicare la catena montuosa si potrebbe aggiungere a natural=peak name=* ele=* un nuovo tag tipo mountain_range=* (ovviamente da discutere). Si, per ogni caso si può studiare un tag o una soluzione specifica, e se già esiste e bene indirizzare i mappatori al suo utilizzo. Ma finchè non c'è, perché non si dovrebbe poter ricorrere ad un tag universale come is_in. Senza contare il fatto che per sfruttare is_in basta il name search, per gli altri tag bisogna usare strumenti di interrogazione più complicati. E' vero che mappiamo per i dati, non per gli strumenti di consultazione. Ma mica dico che in is_in bisogna inserirci valori artificiosi, sono dati validi pure quelli. Puoi fare un elenco di tutte queste possibili applicazioni? Perché, sinceramente, anche sforzandomi, a me non viene in mente un solo caso in cui non si possa aggirare l'ostacolo o, meglio, trovare una soluzione più elegante ed efficiente. Penso che una soluzione più efficiente si possa trovare per tutto, ma nel frattempo usiamo quelle già disponibili. Sono d'accordo a sconsigliare il tag is_in e ad indirizzare verso soluzioni migliori, nei casi in cui queste già esistono. Piuttosto che deprecarlo, sarebbe meglio fare un elenco dei casi in cui ci sono alternative più valide, e se vogliamo creare pure delle guide all'utilizzo più corretto nei casi in cui è ancora uno strumento utile. Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tag is_in deprecato?
-Original Message- From: talk-it-boun...@openstreetmap.org [mailto:talk-it- boun...@openstreetmap.org] On Behalf Of Carlo Stemberger Sent: domenica 4 gennaio 2009 1.12 To: openstreetmap list - italiano Subject: Re: [Talk-it] tag is_in deprecato? In effetti ho provato a cercare una via mettendo via nome_via, nome_comune e me l'ha trovata al primo colpo... senza alcun tag is_in inserito. Com'è possibile? Credo che in assenza di tag is_in venga minimizzata la distanza geometrica. Bisognerebbe provare in un caso in cui un comune adiacente ha anche lui una via con lo stesso nome ed più vicina al centro del paese indicato, e vedere se ti becca la via del comune indicato nella ricerca o la via del comune adiacente. Se leggi qui: http://wiki.openstreetmap.org/wiki/FAQ#What_makes_a_road_belong_to_a_city.3F vedi che dice che nei casi critici bisognerebbe usare il tag is_in. Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] stradario cittadino
Il 04/01/2009 18:30, Diego Roversi ha scritto: Il nome della via NON e' protetto da copyright. L'elenco delle vie del comune invece e' protetto da copyright. Questo perche' la legislazione dice che le raccolte di dati sono protette da copyright. Infatti è proprio quello che abbiamo detto. Non si può: *fotocopiare lo stradario *digitalizzare la carta *elaborare stradario o carta *pubblicare opere da essi derivate *estrarre i dati in modo automatico *[...] Si può: *apprendere i nomi delle vie, che sono liberi e pure corretti (in quanto sono presi alla fonte) *imparare dove avviene il cambio del nome *[...] *riutilizzare questi dati come si vuole Comunque l'argomento non è semplicissimo. Qui si possono trovare delle indicazioni: http://www.dirittodautore.it/page.asp?mode=Pageidpagina=107 -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-se] Motorvägsavfarter
On 4 Jan 2009 at 16:53, Håkan Bråkan wrote: Hej på er Är det någon som har ett bra exempel på hur att tagga upp en motorvägsavfart? Jag är mest nyfiken på hur man märker de gula skyltarna med avfartsnumret. Kan det vara någon variant med 'ref' måntro? Det verkar vara någon som gjort det här utanför Linköping: http://www.openstreetmap.org/?lat=58.436741lon=15.536726zoom=18l ayers=B000FTT Ser ut som key:ref och value:nummer. /Jonas ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se
[Talk-at] Straßenbahnen in Wien
Hallo, da inzwischen per PM eine Dreierrunde daraus geworden ist, können wir auch gleich hier weitermachen. ;-) In den letzten Tagen habe ich die Straßenbahnen in Wien großteils etwas aufgeräumt und das Mapping vereinheitlicht, genauer gesagt in den Bezirken 1-11 und 15-22. Dabei sind vor allem die Zickzack-Streckenführungen um Straßen herum verschwunden, wo sie eigentlich in der Straßenmitte verlaufen sollten. Außerdem dürfte es nun keine Doppel-Whopper mehr geben, d.h. separate Ways für Tram und Straße mit gemeinsamen Nodes, was u.a. beim späteren Editieren für andere Zwecke zu verknoteten Fingern geführt hat. Die Relationen sind entsprechend aktualisiert, die fehlenden Relationen für die Linien 30 und 33 sind nun auch drin. Übrig sind jetzt die separat gemappten Streckenteile, die tatsächlich (oder vermutlich, da war ich mir teilweise nicht sicher) neben den Straßen verlaufen, bzw. in der Mitte von Dual Carriageways. Da besteht auf jeden Fall noch Verschönerungsbedarf. Wie Andere auch schon festgestellt haben, scheint es inzwischen leider völlig unmöglich geworden zu sein, die Wiki-Seite Vienna_OSM_Coverage zu editieren, da diese offenbar zu groß und der Server ständig überlastet ist. Gruß Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] [plan.at] Straßennamen/Ortsnamen Hallo ,
Hallo, ich bin genau so vorgegangen. LG Alex Erich Schubert schrieb: Hallo, ich habe das name-Tag in solchen Fällen entfernt. lG Erich Am Sunday 04 January 2009 13:49:09 schrieb Stefan Kopetzky: Mir ist aufgefallen, dass die plan.at-Import-Daten in Gegenden wo es keine dezidierten Straßennamen gibt (mE die durchnummerierten Ortschaften), aber auch tracks und andere Wege ohne Namen in Orten mit Straßennamen einfach mit Orts(-teil)namen benennt. Ich persönlich tendiere dazu diese name-Tags zu löschen (weil die Strasse ja nicht wirklich so heisst), würde aber gern andere Meinungen dazu hören. Natürlich hoff ich, dass das nicht schon andernorts besprochen wurde und ich das übersehen hab. LG, Stefan ___ 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] [plan.at] Rohrbach
Also ich konnte das in: http://planet.openstreetmap.org/hourly/ nicht finden. Schaus Du auch nochmal durch - wenn Du ihn hast, kann ich ihn gerne wiederherstellen. Achtung, der Server läuft in englischer Zeit ;-) lg aus Wien Wolfgang also, ich denke es war zwischen 14 und 15 uhr. 2009/1/4 Wolfgang W. Wasserburger o...@wasserburger.at ich hab versehentlich den Node für den Bezirk Rohrbach gelöscht - hat jemand eine Idee, wie ich den wiederherstellen kann? wann war das? wenn ich weiß in welcher Stunde, hole ich das aus den Diffs. (jetzt habe ich schon Erfahrung mit haarigen Änderungen ;-) Angeblich soll das aber auch mit Potlach gehen. lg Wolfgang ___ 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] [plan.at] Straßennamen/Ortsnamen Hallo ,
Hallo, ich bin genau so vorgegangen. LG Alex Erich Schubert schrieb: Hallo, ich habe das name-Tag in solchen Fällen entfernt. lG Erich Am Sunday 04 January 2009 13:49:09 schrieb Stefan Kopetzky: Mir ist aufgefallen, dass die plan.at-Import-Daten in Gegenden wo es keine dezidierten Straßennamen gibt (mE die durchnummerierten Ortschaften), aber auch tracks und andere Wege ohne Namen in Orten mit Straßennamen einfach mit Orts(-teil)namen benennt. Ich persönlich tendiere dazu diese name-Tags zu löschen (weil die Strasse ja nicht wirklich so heisst), würde aber gern andere Meinungen dazu hören. Natürlich hoff ich, dass das nicht schon andernorts besprochen wurde und ich das übersehen hab. LG, Stefan Die Konventionen im plan.at Material waren hier etwas anders - durch den Namen hat das Routing auch festgestellt, daß hier Ortsgebiet ist; ich sehe es auch so, daß man das löschen sollte, kann das aber automatisiert nicht erkennen. Die PLZ sollte dann allerdings besonders bleiben, weil es ja noch kein richtiges Tag für Ortsgebiet gibt ;-) und die Routingprogramme sonst überall durchrasen ;-) lg Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] [Wien] Apotheken
IMO ist diese Seite zu groß. IMO sollten wir sie auf Sach-Seiten aufteilen (Wien/Apotheken ist so die Idee eines Anfangs, ich denke an Wien/Parks, Wien/Strassenbahn oder Wien/WVB oä [bitte nicht Wien/ÖPNV ;) ]). Ich hab mal Wien/Parks erstellt, ist auch nicht grad flott, so rießig wie der teil alleine schon ist. mfg, Florian (Kelvan) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Straßenbahnen in Wien
Am 4. Januar 2009 17:58 schrieb Andreas M. am.osm.l...@chello.at: Hallo, Florian Schweikert wrote: Hey, der 40er und 41er sind ja jetzt wirklich nicht mehr so hässlich wie ich sie hinterlassen habe, big thx. Warum hast Du eigentlich den Status der beiden Relationen runtergesetzt? Habe ich da geschlampt? Ich dachte, die wären schon vollständig. Ich habe nur einmal eine runtergesetzt das war schon länger her, damals waren noch nicht alle Haltestellen da. Von Änderunge in letzter Zeit weiß ich nichts. mfg, Kelvan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Straßenbahnen in Wien
Andreas M. wrote: In den letzten Tagen habe ich die Straßenbahnen in Wien großteils etwas aufgeräumt und das Mapping vereinheitlicht, genauer gesagt in den Bezirken 1-11 und 15-22. Dabei sind vor allem die Zickzack-Streckenführungen um Straßen herum verschwunden, wo sie eigentlich in der Straßenmitte verlaufen sollten. Danke! :) Wie Andere auch schon festgestellt haben, scheint es inzwischen leider völlig unmöglich geworden zu sein, die Wiki-Seite Vienna_OSM_Coverage zu editieren, da diese offenbar zu groß und der Server ständig überlastet ist. Es geht, allerdings nur fallweise und meist nur im Ganzen. Ich werde gelegentlich mal Wien/Parks herausnehmen... Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Wiener Schulen
Ich habe gerade die Seite Wien/Schulen angelegt. Der erste Bezirk sollte fertig vollständig drinnen sein. Werde jetzt den 18ten machen. Einen Link nach Wien/Unis habe ich angelegt aber die Seite selbst noch nicht erstellt. Werde auch versuchen Die Straßenbahnen auszulagern. mfg, Kelvan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Straßenbahnen in Wien
In den letzten Tagen habe ich die Straßenbahnen in Wien großteils etwas aufgeräumt und das Mapping vereinheitlicht, genauer gesagt in den Bezirken 1-11 und 15-22. großes Lob - mir ist im 2. schon was aufgefallen ;-) Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] [plan.at] Straßennamen/Ortsnamen Hallo ,
Hallo, ich habe das name-Tag in solchen Fällen entfernt. lG Erich Am Sunday 04 January 2009 13:49:09 schrieb Stefan Kopetzky: Mir ist aufgefallen, dass die plan.at-Import-Daten in Gegenden wo es keine dezidierten Straßennamen gibt (mE die durchnummerierten Ortschaften), aber auch tracks und andere Wege ohne Namen in Orten mit Straßennamen einfach mit Orts(-teil)namen benennt. Ich persönlich tendiere dazu diese name-Tags zu löschen (weil die Strasse ja nicht wirklich so heisst), würde aber gern andere Meinungen dazu hören. Natürlich hoff ich, dass das nicht schon andernorts besprochen wurde und ich das übersehen hab. LG, Stefan ___ 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
[Talk-at] [plan.at] Straßennamen/Ortsnamen
Mir ist aufgefallen, dass die plan.at-Import-Daten in Gegenden wo es keine dezidierten Straßennamen gibt (mE die durchnummerierten Ortschaften), aber auch tracks und andere Wege ohne Namen in Orten mit Straßennamen einfach mit Orts(-teil)namen benennt. Ich persönlich tendiere dazu diese name-Tags zu löschen (weil die Strasse ja nicht wirklich so heisst), würde aber gern andere Meinungen dazu hören. Natürlich hoff ich, dass das nicht schon andernorts besprochen wurde und ich das übersehen hab. LG, Stefan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wiener Schulen
On 01/04/2009 06:41 PM, Florian Schweikert wrote: Ich habe gerade die Seite Wien/Schulen angelegt. Frage dazu: Woher stammen die Namen der Schulen. Ich kann das natürlich nur bei denen sagen, die ich besucht hab, aber da sind die Namen tlw. sehr gespreizt bspw. Konf. VS Schopenhauerstraße statt De La Salle Schule (früher hießen die glaub ich Volksschule d. Schulbrüder, Währing), wie sich die Schule auf ihrer Website präsentiert. Ich denke insbesondere die meisten konfessionellen Schulen haben irgendeinen religiösen Namen unter denen man die Schule eher kennt als unter dem Straßennamen. Wie könnten solche Namen abgebildet werden? In OSM würd ich das als Name direkt eintragen, im Wiki würd ich dafür auch eine eigene Spalte verwenden. lg, Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] [plan.at] Braunau
ist importiert - ist aber hauptsächlich Braunau selbst es gab 3 Knotenfehler, die anscheinend automatisch korrigiert werden konnten; ich werde das morgen prüfen. Im Prinzip kann das editieren beginnen. lg Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wiener Schulen
Frage dazu: Woher stammen die Namen der Schulen. Ich kann das natürlich nur bei denen sagen, die ich besucht hab, aber da sind die Namen tlw. sehr gespreizt bspw. Konf. VS Schopenhauerstraße statt De La Salle Schule (früher hießen die glaub ich Volksschule d. Schulbrüder, Währing), wie sich die Schule auf ihrer Website präsentiert. Ich denke insbesondere die meisten konfessionellen Schulen haben irgendeinen religiösen Namen unter denen man die Schule eher kennt als unter dem Straßennamen. Wie könnten solche Namen abgebildet werden? In OSM würd ich das als Name direkt eintragen, im Wiki würd ich dafür auch eine eigene Spalte verwenden. ich denke, das ist jetzt ein Fall für alt_name bzw. loc_name lg Wolfgang lg, Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] [plan.at] Linz
ist mit rund 20 Fehlern importiert - werden nachimportiert - bitte die scheinbar sinnlosen Nodes vorerst lassen, den Rest könnt Ihr bereits bearbeiten lG Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Postleitzahlen Postämter
2009/1/5 Andreas Labres l...@lab.at Zu diesem OSB Eintrag: Der Tag addr:postcode=1143 ist falsch, da alle Adressen im 14.Bezirk die PLZ 1140 haben. name=Postamt 1143 hingegen ist korrekt. (gleich flasche addr:postcode Tags haben auch noch etliche andere Postämter in Wien. [NoName] Das ist die PLZ dieses Postamtes (dieser Postfiliale). Man kann jetzt drüber streiten, ob man das alles taggen muß, aber ich stehe auf dem Standpunkt, besser zu viel. Wenn man zB zur PLZ 1143 routen will (um die Post vom Postfach abzuholen), muß man zu diesem PA geroutet werden. Servus, Andreas Sehe ich ähnlich, Postämter haben andere PLZ, also sind auch diese einzutragen. Es gibt ja auch Postämter, die mehrere PLZ haben ;-) klassischerweise war das das frühere Paketpostamt mit 1036 und 1103 aber auch 1160/1170 - ist das schon geteilt? lg Wolfgang___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wiener Schulen
Hallo! Sollten wir nicht bei Schulen die Schulkennzahl als ref taggen? Das wäre die einzige Chance, irgendwann mal auf Vollständigkeit zu checken (weil über den Namen ist das glaub ich chancenlos). Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Postleitzahlen Postämter
Über diesen Fehler bin ich auch bereits gestolpert, habe ihn aber ignoriert (offenbar tut es die Post auch ...). Zumindest für den Bereich HTL in St.Pölten gibt es eine eigene Postleitzahl . die aber kaum realisiert wird (nicht sicher aber bemerkt habe ich auch noch andere Bereiche in St. Pölten ) lG Erich P.S.: zuerst sollten die Basisdaten eingepflegt werden, dann kommt die Kosmetik Am Monday 05 January 2009 00:10:22 schrieb Andreas Labres: Zu diesem OSB Eintrag: Der Tag addr:postcode=1143 ist falsch, da alle Adressen im 14.Bezirk die PLZ 1140 haben. name=Postamt 1143 hingegen ist korrekt. (gleich flasche addr:postcode Tags haben auch noch etliche andere Postämter in Wien. [NoName] Das ist die PLZ dieses Postamtes (dieser Postfiliale). Man kann jetzt drüber streiten, ob man das alles taggen muß, aber ich stehe auf dem Standpunkt, besser zu viel. Wenn man zB zur PLZ 1143 routen will (um die Post vom Postfach abzuholen), muß man zu diesem PA geroutet werden. Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wiener Schulen
Am Monday 05 January 2009 00:47:47 schrieb Andreas Labres: Hallo! Sollten wir nicht bei Schulen die Schulkennzahl als ref taggen? Das wäre die einzige Chance, irgendwann mal auf Vollständigkeit zu checken (weil über den Namen ist das glaub ich chancenlos). wenn wir uns an die Abrechnung vom Mysterium für diverse Leistungen halten, dann ist die Schulkennzahl die EINZIGE Konstante auf die referenziert werden kann (Bundesrechenzentrum), und die gilt ÖSTERREICHWEIT. Also aus meiner Sicht unterstütze ich die ref=schulkennzahl (erleichtert auch mein Leben ...) (Schul)Name: = Chancenlos (ändert sich in den kommenden Jahren noch 78000 x) lG Erich Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Schulen in Österreich
Hallo, Da dieses Problem doch interessanter zu sei scheint habe ich einen eigenen Thread eröffnet. Mit der Zuordnung der Schulkennzahl hat sich bereit ein Problemfeld eröffnet. Wird die Schulkennzahl auf das Gebäude, auf die Zufahrtsstraße gelegt? (habe sowohl alle Gebäude als auch die Zufahrtstraße gekennzeichnet.). Die Zufahrt gilt aber in St.Pölten sowohl für die HAK als auch für die HTL.. lG Erich P.S.: Ich habe Zugänge zur Veröffentlichung der OSM-Projektgedanken (zumindest in Verbindung mit den Schulstandorten). Bitte um Rückmeldungen ... ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Schulen in Österreich
Da dieses Problem doch interessanter zu sei scheint habe ich einen eigenen Thread eröffnet. Mit der Zuordnung der Schulkennzahl hat sich bereit ein Problemfeld eröffnet. Wird die Schulkennzahl auf das Gebäude, auf die Zufahrtsstraße gelegt? (habe sowohl alle Gebäude als auch die Zufahrtstraße gekennzeichnet.). Die Zufahrt gilt aber in St.Pölten sowohl für die HAK als auch für die HTL.. mE kann die Schulkennzahl nur dem Gebäude (oder der Direktion gehören) - es gibt allerdings Gebäude, in denen sich mehrere Schulen befinden, zB Berufsschulen (habe aber nicht nachgeschaut, ob die dann nicht eine zentrale Schulkennzahl haben). Das sollte man von vornherein bedenken. lg Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] [plan.at] Grieskirchen
ist technisch fehlerfrei importiert; reicht allerdings von der Bezirkshauptstdt nicht sehr weit weg. Viel Spaß den Oberösterreichern lg Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Bahnhofsbezeichnungen
Hallo! Irgendwer (konkret scheint das ein User flox gewesen zu sein) hat an der Westbahn die Bahnhöfe/Haltestellen umbenannt und die Linienbezeichnungen dazugeschrieben. Ich halte das aus mehreren Gründen für keine gute Idee. Falls derjenige hier mitliest, könntest Du das wieder reverten? Falls nein, kann's wer anderer tun? Nebenbei dürfte er auch Relationen für die Schnellbahn-Linien gemacht haben, was ja wieder lobenswert ist. NB: sind diese Verlängerungen der S2/S15 nach Unterpurkersdorf nicht nur zur Hauptverkehrszeit? Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] [plan.at] Tamsweg
... ist technisch fehlerfrei importiert - allerdings gab es nur sehr wenige Referenzpunkte für die Transformation - ich hoffe, das paßt zur Bearbeitung freigegeben lg Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] [plan.at] Krems/NÖ
... es gab beim Importieren irgendein Problem und OSM hat abgebrochen - suche danach - bitte in dieser Gegend nichts löschen, damit das Wiederaufsetzen besser geht. lG Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] [plan.at] Bruck/Leitha
... technisch fehlerfrei importiert und zum Editieren freigegeben. lG Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] [plan.at] Linz
Servus, *Verwunderung* Ich dachte, es war nicht vorgesehen, bereits so gut erfasste Gebiete wie Linz zu importieren? Da steckt jetzt sehr viel Arbeit drinnen, das zu bereinigen; über ein Overlay oder sogar manuelles Abschreiben hätten die paar fehlenden Straßenzüge und -Namen IMHO sehr viel einfacher ergänzt werden können. Die Aufteilung in PRIO1-3 im Wiki wird ignoriert? Grüße, Christian Wirth Am 04.01.2009, 22:35 Uhr, schrieb Wolfgang W. Wasserburger o...@wasserburger.at: ist mit rund 20 Fehlern importiert - werden nachimportiert - bitte die scheinbar sinnlosen Nodes vorerst lassen, den Rest könnt Ihr bereits bearbeiten lG Wolfgang ___ 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] Postleitzahlen Postämter
On 01/05/2009 12:10 AM, Andreas Labres wrote: Das ist die PLZ dieses Postamtes (dieser Postfiliale). Man kann jetzt drüber streiten, ob man das alles taggen muß, aber ich stehe auf dem Standpunkt, besser zu viel. Wenn man zB zur PLZ 1143 routen will (um die Post vom Postfach abzuholen), muß man zu diesem PA geroutet werden. Ich hab erst kürzlich ein paar nackte Postämter etwas erweitert und bin dort anders vorgegangen. Als addr:postcode steht immer nur der Bezirk da. Die Unterteilungen hab ich in den Namen geschrieben, als bspw. Postamt 1092. Das ist zwar technisch gesehen falsch aber ich hab das aus der Sicht des Anwenders gemacht (9ter Bezirk == 1090). Für das Routing macht's imho keinen Unterschied ob man zum Postamt 1092, Straße, 1090 Wien oder eben 1092 Wien routet, solangs eindeutig ist. Aber nachdem hier - durchaus verständlich - die Meinung vorherrscht, dass die Daten korrekt auf Punkt und Beistrich eingetragen werden, werd ich die paar Postämter demnächst korrigieren. Norbert PS: Der OSB Eintrag ist nicht von mir. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Schulen in Österreich
On 01/05/2009 01:35 AM, Erich Schubert wrote: Zufahrt gilt aber in St.Pölten sowohl für die HAK als auch für die HTL.. Bei der von mir beispielhaft genannten Schule (Schulbrüder Währing) befinden/befanden sich Volks- und Hauptschule in einem Gebäude, nur in unterschiedlichen Stockwerken. Aber ich denk das Problem betrifft nicht nur die Schulkennzahlen sondern auch große Amtsgebäude, wo mehrere Institutionen drin sind, die so miteinander ev. gar nichts zu tun haben, außer zufällig von der selben Institution betrieben zu werden. Derzeit seh ich insgesamt keine Möglichkeit sowas sauber zu taggen und würde wohl am ehesten ein Gebäude zeichnen und in das Gebäude mehrere Nodes mit derselben Adresse und unterschiedlichen Verwendungen zeichnen. Ideen dazu? Norbert PS: Ein gutes Beispiel ist auch das BKA bzw. Verkehrsamt in Wien, wobei es noch relativ leicht sein sollte, da man das BKA wohl aufgrund von vernachlässigbarem Parteienverkehr ignorieren kann. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Schulen in Österreich
Bin ich sehr einverstanden damit ... wenn es eine sinnvolle Möglichkeit gibt das zu machen. Tendentiell würd ich sagen Relation, allein aus dem Reflex heraus, das alles was nicht offensichtlich geht, bei OSM ein Relation ist. Und die Strichpunktnotation führt zu gar nichts, da sie weder gerendert noch für Abfragen automatisch einbezogen wird. Noch dazu ist es schwierig bspw. Telefonnummern anzugeben, denn die müssten dann immer in derselben Reihenfolge wie die Namen stehen. Das auszuwerten ist wohl der pure Horror. Telefonnummern gehören hier aber wohl überhaupt nur in Ausnahmefällen her; wenn diese entweder gerendert werden, oder fürs Routing gebraucht werden, oder fürs geocoding, oder wirklich extrem wichtig sind. Ansonsten ist wohl die Id einer rein alphanumerischen Datenbank, wo man rüberspringen kann sinnvoller, dann muß das nicht doppelt gewartet werden. Feitag und Berndt legt seinen Plänen ja auch keine Telefonbücher bei ;-) lg Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Schulen in Österreich
On 01/05/2009 08:44 AM, Wolfgang W. Wasserburger wrote: Telefonnummern gehören hier aber wohl überhaupt nur in Ausnahmefällen her; wenn diese entweder gerendert werden, oder fürs Routing gebraucht werden, oder fürs geocoding, oder wirklich extrem wichtig sind. Ersetze Telefonnummer durch einen beliebigen Eintrag, der sich nur auf eine spezielle Institution in einem Gebäude bezieht. Website, Öffnungszeiten, Zugangsmöglichkeit f. Rollstuhlfahrer, whatever. Im Übrigen sind mir derzeit noch keine Projekte bekannt, wo eine Referenz auf andere Datenbanken hinterlegt wird und auch wirklich automatisiert verfügbar ist. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
