[talk-ph] Google Maps causes Invasion
Well not really, but it helped http://newsfeed.time.com/2010/11/05/21st-century-war-google-maps-error-leads-to-nicaraguan-invasion/ Jim ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[OSM-talk-be] Format of is_in tags in Belgium
List, Long story short: I've noticed that there are many, many is_in tags in Belgium which do not conform to the generally accepted OSM standard. (Note that I'm not debating here whether an is_in tag should or should not be used within OSM - I'm just interested in the is_in tags which are already there in the data). There are three main things which I've noticed, and I refer you to http://wiki.openstreetmap.org/wiki/Key:is_in for the currently 'accepted' standard. 1. Entities should be separated by semi-colons ;. There are many, many is_in tags with entities separated by commas ,. I'm not sure if this is something to do with automatic imports... 2. It is recommended that entities be written in ascending order of size. For example, the is_in tag for Ieper would be something along these lines: Ieper;West-Vlaanderen;Vlaanderen;Belgium;Europe. (Different [local] language versions of these names are perfectly acceptable. For example: Ieper;West-Flanders;West-Vlaanderen;Flanders;Vlaanderen;Belgium;Belgie;Belgique;Europe). 3. The is_in:country tag should have the name of the country, in English, in full. No abbreviations. I saw (and corrected) one example where the is_in:country tag had a value of BE. BE should go in the is_in:country_code tag. If have seen examples of the above 'problems' in both the flanders region and the walloon region, which is why I send this to the main mailing list - I thought at first that it might just be one person doing this in a local area, but it seems the practice is widespread. I'm not suggesting go all out and hunt them down: just, if you come across an is_in tag, check to see if it is up to standard! Cheers Tim ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Format of is_in tags in Belgium
Tim Francois wrote: 2. It is recommended that entities be written in ascending order of size. For example, the is_in tag for Ieper would be something along these lines: Ieper;West-Vlaanderen;Vlaanderen;Belgium;Europe. (Different [local] language versions of these names are perfectly acceptable. For example: Ieper;West-Flanders;West-Vlaanderen;Flanders;Vlaanderen;Belgium;Belgie;Bel gique;Europe). This originates from an old German import (I think from Geonames). Their import script couldn't handle the different translations. It was noted at the time, but they never cleaned it up. Anyway, for my part all the is_in tags may be deleted anyway. Once the boundaries are there, you can derive your is_in information from them. Greetings Ben ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Format of is_in tags in Belgium
hit send a bit too soon... Tim Francois wrote: 1. Entities should be separated by semi-colons ;. There are many, many is_in tags with entities separated by commas ,. I'm not sure if this is something to do with automatic imports... This has its origin also a long time ago. The first definition of the is_in key had comma-separated values. Only later it was replaced with a semicolon, to be consistent with other multi-value tags. But just no-one cares about the is_in tag anyway, so does it really matter? Ben ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] De Lijn data in Googl
http://tweakers.net/nieuws/70621/dienstregeling-de-lijn-vanaf-2011-in-google-maps.html Tja... Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Format of is_in tags in Belgium
On Fri, Nov 5, 2010 at 2:14 PM, Ben Laenen benlae...@gmail.com wrote: snip But just no-one cares about the is_in tag anyway, so does it really matter? I know that was a flippant comment, but it's not true - there are many projects which still use the is_in tags. As I said in my original message though, that's not my point: my point is, if it's in the OSM database, and if it's not being deleted, there's no harm in fixing it up if you come across one. Thanks for the info though - I had a suspicion that the is_in tags may have been imported and/or the wiki changed since the inception of the is_in tags! Tim ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] De Lijn data in Googl
Maarten Deen wrote: http://tweakers.net/nieuws/70621/dienstregeling-de-lijn-vanaf-2011-in-googl e-maps.html Tja... Wel grappig dat dezelfde problemen als bij ons opduiken: * wie is aansprakelijk voor verkeerde informatie * hoe visualiseer je de routes En dat eerste probleem zal ons nooit toelaten om deze data in OSM te krijgen. Het zou betekenen dat iemand (of iets als een OSM-BE vzw) een contract met hen zal moeten ondertekenen. Als die dan ooit eens aansprakelijk wordt gesteld voor niet up-to-date data... Maar ik ken niks over dit onderwerp. We kunnen enkel hopen dat Google zijn gewicht hier gaat tonen en weigert iets te ondertekenen. Iemand met contacten in die afdeling van Google om hen daarop te wijzen? :-) Ben ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] License Use Case
Hi, Xavier Loiseau wrote: Do the pictures distributed through the web site have to be licensed under the CC-BY-SA license ? Later, will the pictures distributed through the web site have to be licensed under the ODbL license ? I think the answer is no in both cases. However, you might have to share the database that contains your picture IDs keyed against locations in the ODbL case since it could be argued that that database is derived from OSM and publicly used in your service. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] New: A blackwhite base layer
2010/11/4 Tim Waters chippy2...@gmail.com: It's around this time of year that we start thinking about funny Christmas styled maps, with snowmen, and frosty trees... http://wiki.openstreetmap.org/wiki/OpenSantaMap :-) Last year there was a German Project within OSM collecting positions of places where they sell christmas trees, or special markets are held. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Fri, Nov 5, 2010 at 1:50 PM, Steven Johnson sejohns...@gmail.com wrote: +1 This is why I object to removing the TIGER tags in the US. Retaining the source and lineage of data (or, as it turns out NOT retaining) sometimes has real-world consequences. If you remove the TIGER tags, they are still in the history. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Fri, Nov 5, 2010 at 9:57 AM, Richard Mann richard.mann.westoxf...@gmail.com wrote: On Fri, Nov 5, 2010 at 1:50 PM, Steven Johnson sejohns...@gmail.com wrote: +1 This is why I object to removing the TIGER tags in the US. Retaining the source and lineage of data (or, as it turns out NOT retaining) sometimes has real-world consequences. AFAIK no one has ever advocated removing the TIGER tags other than tiger_reviewed = no. - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Fri, Nov 5, 2010 at 9:22 AM, Serge Wroclawski emac...@gmail.com wrote: AFAIK no one has ever advocated removing the TIGER tags other than tiger_reviewed = no. Actually... http://lists.openstreetmap.org/pipermail/talk-us/2010-July/003761.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Fri, Nov 5, 2010 at 11:03 AM, Toby Murray toby.mur...@gmail.com wrote: On Fri, Nov 5, 2010 at 9:22 AM, Serge Wroclawski emac...@gmail.com wrote: AFAIK no one has ever advocated removing the TIGER tags other than tiger_reviewed = no. Actually... http://lists.openstreetmap.org/pipermail/talk-us/2010-July/003761.html Epic trolls don't count. And I'd consider that vandalism. - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Announce search box with result suggestions
Hi all, The lack of auto-complete or search suggestions like you see in for example Google (maps) and the OSM wiki search box has been bugging me for a while. So I created a prototype based on the Nominatim API and the Google Closure JS framework. There's a lot of things it won't do yet, but it's a decent first step. Give it a try, I will put the source in SVN if you want to get your hands dirty with this. http://lima.schaaltreinen.nl/mvexel/nominatim/ Best, Martijn martijn van exel +++ m...@rtijn.org laziness - impatience - hubris http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] SotM 2011: September 9-11, 2011
The organizing committee for State of the Map (SotM) conference selected September 9-11, 2011 as the dates for the fifth annual international gathering. More information can be found at http://blog.osmfoundation.org/2010/11/05/state-of-the-map-2011-september-9-11-2011/ See you there! ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On 5 Nov 2010, at 8:09 , Serge Wroclawski wrote: On Fri, Nov 5, 2010 at 11:03 AM, Toby Murray toby.mur...@gmail.com wrote: On Fri, Nov 5, 2010 at 9:22 AM, Serge Wroclawski emac...@gmail.com wrote: AFAIK no one has ever advocated removing the TIGER tags other than tiger_reviewed = no. Actually... http://lists.openstreetmap.org/pipermail/talk-us/2010-July/003761.html Epic trolls don't count. he is not a troll and has never been. who are you to call someone a troll because you don't agree? And I'd consider that vandalism. I consider it improving osm by a human mapper according the spirit of the project instead a container full of imports with not much value. If a human surveys on ground or based on personal knowledge and image tracing it has 100 times more value than any imported data - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Fri, Nov 5, 2010 at 12:33 PM, Apollinaris Schoell ascho...@gmail.com wrote: On 5 Nov 2010, at 8:09 , Serge Wroclawski wrote: On Fri, Nov 5, 2010 at 11:03 AM, Toby Murray toby.mur...@gmail.com wrote: On Fri, Nov 5, 2010 at 9:22 AM, Serge Wroclawski emac...@gmail.com wrote: AFAIK no one has ever advocated removing the TIGER tags other than tiger_reviewed = no. Actually... http://lists.openstreetmap.org/pipermail/talk-us/2010-July/003761.html Epic trolls don't count. he is not a troll and has never been. who are you to call someone a troll because you don't agree? I'm someone who reads the lists and see that Anthony says things which are patently untrue, or uses a tone of fact when it's just speculation, or just takes up a contrary position when there's no issue. And I'd consider that vandalism. I consider it improving osm by a human mapper according the spirit of the project instead a container full of imports with not much value. If a human surveys on ground or based on personal knowledge and image tracing it has 100 times more value than any imported data We're not talking about human surveyed data- that is already addressed by tiger_reviewed- we're talking about disassociating the original feature from an import from its current incarnation. This doesn't improve anything, it just makes it harder to associate the data from the source. Also, in the case of image tracing, one is recommended to mention a source= tag. Not everyone does that all the time (I don't do it often, when I should), but the idea there is the same- to illustrate the data lineage. - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On 05/11/2010 16:54, Serge Wroclawski wrote: On Fri, Nov 5, 2010 at 12:33 PM, Apollinaris Schoellascho...@gmail.com wrote: I consider it improving osm by a human mapper according the spirit of the project instead a container full of imports with not much value. If a human surveys on ground or based on personal knowledge and image tracing it has 100 times more value than any imported data We're not talking about human surveyed data- that is already addressed by tiger_reviewed- we're talking about disassociating the original feature from an import from its current incarnation. This doesn't improve anything, it just makes it harder to associate the data from the source. Also, in the case of image tracing, one is recommended to mention a source= tag. Not everyone does that all the time (I don't do it often, when I should), but the idea there is the same- to illustrate the data lineage. Probably more useful (especially for imports) to tag the source on the changesets, instead of the objects. As the source is specific to those changes/import, and not the objects themselves, which may later be edited using data from a variety of other sources. The changeset tags can be retrieved from the history if necessary. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Troll talk (was Google fumbles again in latin america)
This list already already seen an extensive thread on the behavior of the individual in question. Isn't there a better use of our bandwidth (in terms of both bits and time) than re-hashing it? On 11/05/2010 09:54 AM, Serge Wroclawski wrote: On Fri, Nov 5, 2010 at 12:33 PM, Apollinaris Schoellascho...@gmail.com wrote: On 5 Nov 2010, at 8:09 , Serge Wroclawski wrote: On Fri, Nov 5, 2010 at 11:03 AM, Toby Murraytoby.mur...@gmail.com wrote: On Fri, Nov 5, 2010 at 9:22 AM, Serge Wroclawskiemac...@gmail.com wrote: AFAIK no one has ever advocated removing the TIGER tags other than tiger_reviewed = no. Actually... http://lists.openstreetmap.org/pipermail/talk-us/2010-July/003761.html Epic trolls don't count. he is not a troll and has never been. who are you to call someone a troll because you don't agree? I'm someone who reads the lists and see that Anthony says things which are patently untrue, or uses a tone of fact when it's just speculation, or just takes up a contrary position when there's no issue. And I'd consider that vandalism. I consider it improving osm by a human mapper according the spirit of the project instead a container full of imports with not much value. If a human surveys on ground or based on personal knowledge and image tracing it has 100 times more value than any imported data We're not talking about human surveyed data- that is already addressed by tiger_reviewed- we're talking about disassociating the original feature from an import from its current incarnation. This doesn't improve anything, it just makes it harder to associate the data from the source. Also, in the case of image tracing, one is recommended to mention a source= tag. Not everyone does that all the time (I don't do it often, when I should), but the idea there is the same- to illustrate the data lineage. - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Fri, Nov 5, 2010 at 12:54 PM, Serge Wroclawski emac...@gmail.com wrote: We're not talking about human surveyed data- that is already addressed by tiger_reviewed- we're talking about disassociating the original feature from an import from its current incarnation. That doesn't even make any sense grammatically, let alone semantically. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] State of the Map 2011 date announced
The SotM organizing committee has announced the date of SotM 2011, 09 through 11, September 2011. Denver, CO, USA It'll be wonderful. http://blog.osmfoundation.org/2010/11/05/state-of-the-map-2011-september-9-11-2011/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
hmm, sorry got the wrong name here, reading from pipermail Alan's name was highlighted and Anthony's wasn't :( have to agree on the trolling, and it jsut got confirmed Also, in the case of image tracing, one is recommended to mention a source= tag. Not everyone does that all the time (I don't do it often, when I should), but the idea there is the same- to illustrate the data lineage. with most data in PD and Yahoo and many other free images it doesn't matter so much in US. source is more important where copyright is a minefield - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Fri, Nov 5, 2010 at 9:57 AM, Richard Mann richard.mann.westoxf...@gmail.com wrote: On Fri, Nov 5, 2010 at 1:50 PM, Steven Johnson sejohns...@gmail.com wrote: +1 This is why I object to removing the TIGER tags in the US. Retaining the source and lineage of data (or, as it turns out NOT retaining) sometimes has real-world consequences. If you remove the TIGER tags, they are still in the history. Moreover, you shouldn't remove tiger_reviewed=no unless you have verified the feature *with a different non-TIGER source*. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
On Fri, Nov 5, 2010 at 1:55 PM, Apollinaris Schoell ascho...@gmail.com wrote: hmm, sorry got the wrong name here Oops. Sure screwed up your ad hominem reasoning. Hilarious. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] coastline in mapnik
I'm waiting for my last week's coastline changes to become visible on the main site's mapnik layer: http://www.openstreetmap.org/?lat=-0.7596lon=-47.049zoom=12layers=M I tried to avoid caching problems, and I triggered re-rendering of the affected tiles by tagging them as dirty ... Osmarender shows the coastline correctly. Does anybody know how to proceed? Thanks for your help, Ulf -- Ulf Mehlig ulf.meh...@gmx.net -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline in mapnik
On Fri, Nov 5, 2010 at 2:07 PM, Ulf Mehlig ulf.meh...@gmx.net wrote: I'm waiting for my last week's coastline changes to become visible on the main site's mapnik layer: http://www.openstreetmap.org/?lat=-0.7596lon=-47.049zoom=12layers=M I tried to avoid caching problems, and I triggered re-rendering of the affected tiles by tagging them as dirty ... Osmarender shows the coastline correctly. Does anybody know how to proceed? Hi Ulf, This question is asked fairly often and is very ably answered on the help site. In short, coastline rendering is a relatively expensive process which is run only a few times per month. Details here: http://help.openstreetmap.org/questions/276/why-do-the-changes-i-have-made-to-coastline-not-appear-on-the-map ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Announce search box with result suggestions
Am 05.11.2010 17:21, Martijn van Exel: Hi all, The lack of auto-complete or search suggestions like you see in for example Google (maps) and the OSM wiki search box has been bugging me for a while. So I created a prototype based on the Nominatim API and the Google Closure JS framework. There's a lot of things it won't do yet, but it's a decent first step. Nice. Works on Opera 10.63 - Now just make it Instant like http://www.michaelhart.me/labs/instant/maps/ ;) Claudius ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Wanted: a live-edit viewing thingalabong
I have a logfile of lat/lon coordinates alll over the world that I want to tail, feed to a webservice and view in a browser. I thought I could use some of the existing live-edit thingy. So far I've found http://matt.dev.openstreetmap.org/owl_viewer/ (aimed at local) and http://searchengineland.com/new-real-time-google-maps-edits-in-new-edits-viewer-13220 which is down at the moment. Is there something existing out there that I can steal and hook up to some trivial AJAX service that'll zoom around the map as new edits come in for some whoo factor? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Error on boundaries + issues with Abkhazia/South Ossetia/disputed territories
Sorry to bring back this old topic... On Fri, Sep 24, 2010 at 12:56, Lennard l...@xs4all.nl wrote: On 24-9-2010 11:38, Tiziano D'Angelo wrote: - The administrative boundary between some regions and autonomous republics of North Caucasus was marked as country border [3] while it should be merely an administrative one Not wanting to get into border disputes, but admin_level=2 _is_ the national level, and 3 is subnational. Found out that...the North Caucasus Republics borders within Russian Federation are correctly tagged with admin level=3 as they are a subnational entity (Federal District). But IMHO Mapnik shows them similarly to country borders, this could lead to misunderstandings if one doesn't look at the actual data...problem of the renderer??? On Fri, Sep 24, 2010 at 11:56, Kirill Bestoujev bestou...@gmail.com wrote: The question was discussed on the Russian osm-forum, we decided to leave the borders as they are now, not to start a war of edits with Georgian osmers, as Georgia does not recognize Abkhazia or South Osetia as independet countries. I think it would be wise to leave it as it is now not to create conflicts. Kirill 2010/9/24 Tiziano D'Angelo tiziano.dang...@gmail.com: - Depending on the points of view, the border Georgia / Abkhazia [4] now marked as an administrative can be marked as country border. For example, Kosovo is marked likewise (with a country border), although not recognized internationally by the majority of countries (36% of the total recognize it) and it isn't even listed on ISO-3166-1 / UN [5], as well as Abkhazia (4 UN member states recognize it). From a de facto point of view (and for some countries de jure) Abkhazia is a fully independent state from Georgia (I noticed it personally while there) and as far as the Georgians say, it is no longer under Georgia's influence or control and it will be like that also in the future. What would you say to a cartographic point of view? from a tourist point of view, for example, it is a separate entity from Georgia (you pass a border control, there is a visa...), so a tourist-oriented map would logically draw it as a separate country. Generally speaking about any kind of disputed terriories, is there any way to keep both POV tagging boundaries as Disputed / Recognized by Some states/something else? Then, if we want to develop OSM in this country, it goes without saying that if locals will see the boundaries as they are now (as part of Georgia region, unrealistic and not corresponding to reality), they will never agree to use OSM! ... while it would be reasonable to use OSM extensively, since for example Google has no map of Abkhazia, and instead there's something already on OSM. - what is the standard for naming of places? What has to be put in name, in int_name tags? Which is the scale of priority? local language I suppose... so capital of Abkhazia, Sukhum, should be tagged as name=Аҟəа (local abkhazian name) name:ru=Сухум name:ka= სოხუმი , int_name=Sukhum; Sukhumi ; etc... Is there a way to simultaneously display multiple names (like Google Maps showing the name in Cyrillic and transliterated Russian or English version)? About Abkhazia, after Kosovo, I discovered North Cyprus border (de facto) is tagged as admin_level=2, even though it is recognized by only one country in the world, as for the draft proposal that I saw in this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries So the same tagging scheme could apply to Abkhazia as well, I guess. Or as the iure status under Georgia would be autonomous republic, then level=3 Sorry to bring up again the issue, but my opinion is that all countries/territories in the same de facto situation shall be tagged likewise, so either admin_level = 2 for all or =4, or as compromise use admin_level=3 in these situations. I'm happy to see that the proposal for North Cyprus has been adopted. Moreover, here: http://wiki.openstreetmap.org/wiki/Cyprus / http://wiki.openstreetmap.org/wiki/Disputes#On_the_Ground_Rule I found more evidence that the scheme of naming should be the same as the mentioned cases, so Abkhazian name in the name tag (cause it is definitely the on ground version, and even official language for Georgia too in that de iure autonomous republic) + all the other languages naming with their respective tags. In this case Abkhazian is written in cyrillic, so the international better-known name is put into brackets next to the Abkhazian name for easier understanding by non-Abkhazians. In fact, this exact scheme has been applied by fellow mapper Ulrich Ludat in his edits this last month in Abkhazia. Ulrich really made a great job improving greatly Abkhazia map situation, maybe the issues weren't properly raised before because of the very little mapping activity in that place??? thanks for the attention Tiziano ___ talk
[OSM-talk-nl] Announce search box with result suggestions
Hi all, The lack of auto-complete or search suggestions like you see in for example Google (maps) and the OSM wiki search box has been bugging me for a while. So I created a prototype based on the Nominatim API and the Google Closure JS framework. There's a lot of things it won't do yet, but it's a decent first step. Give it a try, I will put the source in SVN if you want to get your hands dirty with this. http://lima.schaaltreinen.nl/mvexel/nominatim/ Best, Martijn martijn van exel +++ m...@rtijn.org laziness - impatience - hubris http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] OSM bijeenkomst bij Waypoint in Notter
Hallo allen, Zaterdag 13 november verzorg ik bij Waypoint in Notter voor haar klanten twee bijeenkomsten over OpenStreetMap. De belangstelling hiervoor is overweldigend. Binnen enkele uren na bekendmaking was de eerste sessie vol. De inderhaastte extra sessie in de morgen was vervolgens ook binnen 2 uur volgeboekt. Kortom: 2x50 personen (actieve GPS-gebruikers) die alles over OSM willen weten 100 potentiele nieuwe mappers. Waypoint gaat nu ook de bijeenkomst streamen voor diegenen die er ook bij hadden willen zijn. Daarnaast is er al afgesproken dat er in het (vroege) voorjaar nog eens enkele sessies gepland gaan worden. Toch wel even leuk om te melden dacht ik Gr, Henk H. Voor het geval dat: Waypoint is het bedrijf achter www.gps.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM bijeenkomst bij Waypoint in Notter
...en waar en wanneer vinden we die stream? Op 5 november 2010 17:36 heeft Henk Hoff toffeh...@gmail.com het volgende geschreven: Hallo allen, Zaterdag 13 november verzorg ik bij Waypoint in Notter voor haar klanten twee bijeenkomsten over OpenStreetMap. De belangstelling hiervoor is overweldigend. Binnen enkele uren na bekendmaking was de eerste sessie vol. De inderhaastte extra sessie in de morgen was vervolgens ook binnen 2 uur volgeboekt. Kortom: 2x50 personen (actieve GPS-gebruikers) die alles over OSM willen weten 100 potentiele nieuwe mappers. Waypoint gaat nu ook de bijeenkomst streamen voor diegenen die er ook bij hadden willen zijn. Daarnaast is er al afgesproken dat er in het (vroege) voorjaar nog eens enkele sessies gepland gaan worden. Toch wel even leuk om te melden dacht ik Gr, Henk H. Voor het geval dat: Waypoint is het bedrijf achter www.gps.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- Groeten, Peter ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM bijeenkomst bij Waypoint in Notter
Geweldig Henk. Veel plezier! Martijn Martijn van Exel +++ m...@rtijn.org Laziness – Impatience – Hubris http://schaaltreinen.nl | http://martijnvanexel.nl | http://oegeo.wordpress.com/ twitter: mvexel skype: mvexel flickr: rhodes On Nov 5, 2010, at 5:36 PM, Henk Hoff wrote: Hallo allen, Zaterdag 13 november verzorg ik bij Waypoint in Notter voor haar klanten twee bijeenkomsten over OpenStreetMap. De belangstelling hiervoor is overweldigend. Binnen enkele uren na bekendmaking was de eerste sessie vol. De inderhaastte extra sessie in de morgen was vervolgens ook binnen 2 uur volgeboekt. Kortom: 2x50 personen (actieve GPS-gebruikers) die alles over OSM willen weten 100 potentiele nieuwe mappers. Waypoint gaat nu ook de bijeenkomst streamen voor diegenen die er ook bij hadden willen zijn. Daarnaast is er al afgesproken dat er in het (vroege) voorjaar nog eens enkele sessies gepland gaan worden. Toch wel even leuk om te melden dacht ik Gr, Henk H. Voor het geval dat: Waypoint is het bedrijf achter www.gps.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM bijeenkomst bij Waypoint in Notter
Op 05-11-10 17:40, Peter schreef: ...en waar en wanneer vinden we die stream? www.gps.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Project of the Week / Month
On Fri, 2010-11-05 at 12:33 +1100, Andrew Harvey wrote: Like putting a way down the middle of each lane and then tieing that back to the road, or like just adding a lane:n:feature = value to the existing road way? Then you could do something like lane:0:restriction = rightturnonly. The problem with lane:n:feature, is say youre approaching traffic lights and you have a right-turn light with a long slip lane and a short left turn lane to avoid the lights, how do you tag this? When you go from lanes=2 to lanes=3, how does a renderer know which side the extra lane is on? If you have a 3-into-2 merge, how do you indicate which lane merges easily? Sometimes you might have a single slip-lane which joins a 2-lane road and becomes 3-lane. Another possibility for this tag, is an extra lane for pick-up/set-down at transport hubs or pull-in bus-stop lane, which doesnt have a barrier to the main way. In which case the lane might have psv tag or something. These are the sort of situations I think were being referred to as not having a standard tagging method yet. David ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Reversing the Mercator Effect....
Stephen Von Worley has some fun reversing the distortions of the Mercator projection, which exaggerates the size of things at the poles in order to achieve consistent compass bearings. He imagines what would happen if Greenland was on the equator and Africa in the Arctic, and goes on to do the same thing with Alaska and Texas and with the U.K. and Cuba. Freaky. http://www.datapointed.net/2010/11/africa-greenland-mercator-map-distortion/ ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Hi ant, Am 03.11.2010, 20:51 Uhr, schrieb ant antof...@gmail.com: [...] Karten mit Layern ansprechender gestalten [...] gut, aber ein echter Graustufen-Style müsste schon mehr sein als eine Graustufenkonvertierung des Originals: Es braucht stärkere Kontraste, [...] für Menschen, die keinen Farbdrucker besitzen, als auch für Farbenblinde. Deinen Wunsch sehe ich ein, jedoch war dies nicht Zweck des Base-Layers. Dieser war es, gerade kontrastarm zu sein, d.h. die in darüber liegenden Layern besser herauszustellen. Eine Karte nach deinem Wunsch ist bestimmt möglich, aber nur schwer automatisch hinzubekommen. Dazu bräuchte es mehr Wissen um die (verschiedenen möglichen) Farbschwächen. Viele Grüße Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was passiert bei splitten oder ändern ei nes node/way/relation mit der ID?
Am Donnerstag 04 November 2010, 18:58:34 schrieb Tom Müller: Ich möchte eigentlich nur wissen wie konsistent z.B. Abbiegebeziehungen sind. Die Sache ist doch eigentlich logisch: Relationen an sich sind konsistent. Du kannst keine Relation machen mit einem Member der nicht existiert. Das verhindert die API. Aber die Semantik von Relationen (wie die von jeglichem anderen OSM-Objekt) kann die API gar nicht prüfen. Woher soll die API denn wissen was du meinst? Jeder kann jeden beliebigen Typ von Relation benutzen und da an Objekten eintragen was er will. Nur weil im Wiki irgendwo eine Empfehlung steht, was denn nun eine Abbiegebeziehung sein soll, ist das kein Gesetz und es gibt sicherlich irgendwo Leute die ein anderes, ähnliches aber subjektiv besseres Schema nutzen. Der Grundsatz dass bei OSM jegliches Tagging und jegliche Semantik eine individuelle Einschätzung des Mappers bzw. ein Konsens mehrerer Mapper ist führt logischer Weise dazu, dass es in der API keinerlei Plausibilitätsprüfung gibt, die über das technisch notwendige hinausgeht (also dass man keine Objekte nutzt die es nicht gibt). Die Editoren, insbesondere JOSM, versuchen manche Dinge zu verstehen und schlagen ggf. Verbesserungen vor. Das alles auf einer eher generischen Ebene, also nicht auf Abbiegebeziehungen gemünzt sondern halt für eigentlich alle Relationen geeignet. Da auch JOSM den Mapper nur unterstützen und nicht einschränken will (und soll), wird die Veränderung nicht gemacht sondern vorgeschlagen. Klickt der Benutzer auf Nein, macht JOSM auch nichts. Wieso auch, der Benutzer hat das ja wissentlich und aktiv abgelehnt. Gruß, Bernd -- Vorstellungskraft ist wichtiger als Wissen. - Albert Einstein signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Anfahrtskizze erstellen
Am Donnerstag 04 November 2010, 22:52:06 schrieb Andreas Tille: Naja, muss ist ein starkes Wort, aber praktisch wär es schon, zumal wenn man weiß, daß dort in der Gegend noch einiges fehlt und dann ist die Live-Karte einfach aktueller. Bei einfachen Besuchern gibt es ab und an mal Verwirrungen wenn sie auf einer interaktiven Karte versehentlich das Mausrad benutzen oder da drauf klicken. Es kann daher (je nach erwartetem Publikum) ein großer Vorteil sein, eine statische Karte zu machen, die sich nicht unerwartet verhält wenn der Benutzer keine Efahrung mit solchen Karten hat. Bzgl. der Aktualität kannst du auch die entsprechenden OSM-Tiles als statische Bilder (die URL ändert sich ja nicht) einbinden und deine Markierungen per transparentem Bildchen drüber legen. Ist zwar vielleicht initial etwas mehr Aufwand, löst aber das Problem dass sich viele Leute in der Karte verzoomen und die dadurch wertlos wird. Gruß, Bernd -- Pessimismus wird nur von den Optimisten verbreitet. Die Pessimisten sparen ihn für schlechtere Zeiten auf. - Gabriel Laub signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele GPX-Tracks sinnvoll vereinen
Hallo, Am 04.11.2010 23:12, schrieb Peter Herison: Aus diesem Grund habe ich die Tracks alle aufgetrennt, so dass ich immer Stueckchen zwischen Kreuzungen habe. Nun stehe ich vor dem Problem sie moeglichst speichersparend moeglichst an einem Stueck wieder zusammen zu setzen. Zum Teil muessen die Stueckchen auch verdoppelt und in umgedrehter Reihenfolge wieder eingefuegt werden (Sackgassen). Das geht mit QLandkarteGT: http://qlandkarte.org/ Man kann Tracks aufteilen, umkehren und miteinander Verbinden. Das ganze kann mit einer OSM-Karte oder einer Garmin-Vektorkarte hinterlegt werden. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karten für Farbenblinde (Was: Re : Neu: Ein schwarz/weißer Base-Layer)
Hallo Kay, Eine Karte nach deinem Wunsch ist bestimmt möglich, aber nur schwer automatisch hinzubekommen. Dazu bräuchte es mehr Wissen um die (verschiedenen möglichen) Farbschwächen. Ich bin per Zufall vor ein paar Tagen über diese Seite hier gestolpert: http://gmazzocato.altervista.org/colorwheel/wheel.php Vielleicht hilft sie ja dem einen oder andren hier beim Erstellen seiner Karten.. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags für gesprengte Häuser?
Am 04.11.2010 10:52, schrieb Wolfgang: Wie tagt man Ansammlungen von Betonteilen, wenn z.B. 5-stöckige Plattenbauten gesprengt, aber seit 5 Jahren nicht abtransportiert wurden? Sind das Dünen aus Beton? Oder basted buildings? Oder doch nur Brownfields? Beispiel: http://www.addicks.net/gallery/osm/DSCF3173 (ehemalis baugleiches Gebäude direkt daneben: http://www.addicks.net/gallery/GeoCaching/DSCF3208 ) Ich würde brownfield nehmen. Vielleicht mit Zusatztag building=destroyed oder so. wurde es auf Haiti nicht als building=collapsed getaggt? http://taginfo.openstreetmap.de/keys/building building=ruins sehe ich da noch. Da fällt mir ein, dass ich eine abgebrannte Villa mal als collapsed getaggt habe. Wird allerdings als normales Gebäude gerendered. Würde mich nicht wundern wenn Mapnik sogar building=no rendered. Was bei 0,003% Anteil allerdings kaum auffällt. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 4. November 2010 22:26 schrieb qbert biker qbe...@gmx.de: Sobald die Bedeutung von width klar ist, könnte man enge Straßen in der Karte schmaler zeichnen. je nach Zoom. Die reale Breite hat naturgemäß in den meisten Zoomstufen nichts zu suchen, solange man daran interessiert ist, Straßen zu erkennen. Osmarender wertet width für Flüsse aus. das ist was ziemlich anderes und kartographisch üblich. Solange nicht klar ist, ob eine Straße im Gewerbegebiet mit 20m Gesamtbreite und 7m Fahrbahnbreite oder eine enge Altstadtstraße mit 7m Gesamtbreite und 4m Fahrbahnbreite das Tag width=7 erhält, kann man es nicht nutzen. ja, man sollte einfach mal ins Wiki schreiben, dass width die Fahrbahnbreite ohne Gehsteige enthalten sollte. das in den unteren Zoomstufen eine Alternative zu der heute gebäuchlichen Überhöhung der Breite. Gemeint ist die übliche nicht massstabsgerechte Darstellung der Breite, die je nach Zoomstufe deutlich breiter ist als in der Realität. ja, oder auch schmaler. In Z18 ist die OSM-Straße meist schmaler als die Realität. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 4. November 2010 22:14 schrieb Garry garr...@gmx.de: Am 04.11.2010 15:08, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 21:09 schrieb Carsten Moellercmindivid...@gmx.de: m.E. ist das semantischer Käse. Entweder ist ein Weg eine wichtige (allg.) Verbindung, dann kann er kein service sein, oder er ist eine Sackgasse, die nur zu einem bestimmten Ziel führt, und für alle anderen unwichtig ist, dann ist er ein service. Das ist m.E. gemeint mit service für Zufahrt. Ich verstehe nicht, warum man unbedingt service als Klasse vergeben muss für Wege, die ihrer Natur nach was komplett anderes sind als eine Parkplatzzufahrt oder Grundstücksauffahrt (weil es dahinter im Falle eines Fährhafens eben weitergeht). Man kann service auch als zweckgebundene Strasse betrachten die überwiegend (ich möchte nicht sagen ausschliesslich) eben einem speziellen Zweck dient, dabei aber durchaus auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. könnte man vielleicht (auch wenn ich dafür bisher keine Anhaltspunkte sehe), aber es würde die Lage m.E. nicht verbessern sondern deutlich verschlimmern und es würde nicht mehr klar sein, was man zu erwarten hat, wenn highway=service getaggt ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 4. November 2010 22:14 schrieb Garry garr...@gmx.de: Man kann service auch als zweckgebundene Strasse betrachten die... auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. Das übrigens glaube ich nicht. Du wirst m.E. keine Straße finden, die ein annähernd autobahnähnliches Verkehrsaufkommen hat, und die man (auch nicht nach Deiner Definition) als service bezeichnen kann. Freue mich schon, wenn Du doch ein Beispiel findest, aber ich bezweifle das sehr. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 5. November 2010 10:20 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: hier kannst Du die Zahlen der Autobahnen finden: http://www.bast.de/cln_007/nn_39112/DE/Statistik/Verkehrsdaten/Downloads/zaehlung-2005-BAB-strassen,templateId=raw,property=publicationFile.pdf/zaehlung-2005-BAB-strassen.pdf ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Anfahrtskizze erstellen
Bernd Wurst be...@bwurst.org wrote: Es kann daher (je nach erwartetem Publikum) ein großer Vorteil sein, eine statische Karte zu machen, die sich nicht unerwartet verhält wenn der Benutzer keine Efahrung mit solchen Karten hat. Die kann man sich ohne große Arbeit hier: http://dev.openstreetmap.de/staticmap/wizzard/ und hier: http://ojw.dev.openstreetmap.org/StaticMap/ zusammenklicken. Sven -- Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch. (Anselm Lingnau in de.comp.os.unix.discussion) /me ist gig...@ircnet, http://sven.gegg.us/ im WWW ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Am 4. November 2010 23:09 schrieb tshrub my-email-confirmat...@online.de: was setzt Ihr für Fels? scree ist ja für loses Gestein. Da war vor einem Jahr Mal jemand/ein Thread aus Tschechien oder so ... da zumindest sind wir bei scree geblieben. das würde ich nicht tun. Du würdest auf Deutsch ja auch nicht Schotterfeld schreiben, wenn es nackter massiver Fels ist, oder? landuse=steppe landuse=savanna sind m.E. beides keine Landnutzungen eher landcover oder Landschaftsarten (landscape?). Darin können ja durchaus auch Landnutzungen vorkommen. ich finde ja, landcover deckt begrifflich natural und landuse ab, verschluckt es sozusagen(?), hm, landuse sollte man in jedem Fall deutlich trennen und landcover oder natural. Landuse ist die Bodennutzung, evtl. Landnutzung jedenfalls die Nutzung. Ich weiss, dass das derzeit nicht ganz klar ist (im groben allerdings ist es schon so umgesetzt). Weitere Tags würde ich schon danach trennen und evtl. landuse etwas aufräumen (sind nur wenige Tags, die nicht passen). steppe oder savanna würde ich bei Nutzungshinweisen als landuse (ggf. mit Nutzungsart, z.B. animal=goat) und sonst natural taggen (ggf. mit Pflanze). Hm, bin gerade mal auf diese Wikipediaseite gestoßen: http://de.wikipedia.org/wiki/Landnutzung die interessanterweise diesen Absatz enthält: Die 13 Hauptklassen, die für alle EU-Länder den Rahmen bilden, sind: * Siedlungsflächen (incl. Verkehrsflächen) * Ackerflächen * Dauerkulturen * Grünland * Laub- und Mischwald * Nadelwald * Alpine Matten * Latschen, Krummholz * Felsflächen * Spärliche Vegetation * Gletscher * Feuchtflächen * Wasserflächen. zunächst wird der Eindruck erweckt, die packten auch ungenutzte Flächen in landuse-Klassen, bei näherem Hinsehen wird allerdings klar, dass es sich hier um CORINE Landcover, also Bodenbedeckung handelt, genauso wie beim LLCS der FAO (Welternährungsorganisation). Zu letzteren habe ich übrigens zufälligerweise auch persönliche Kontakte, sollten wir da Fragen haben. An andere Stelle beschreibt der Artikel, dass Industrieländer üblicherweise zw. 20 und 50 verschiedenen Landuse-Differenzierungen anwenden. Weitere Landcover Klassifikationsbeispiele finden sich z.B. bei GLOBCOVER http://ionia1.esrin.esa.int/docs/GLOBCOVER_Product_Specification_v2.pdf ab Seite 20. Ich kann die Aversionen gegen Landcover als Tag nicht verstehen. Das ist am besten zu erkennen im Ggs. zu landuse, und meistens auch eindeutig. Der Begriff ist allgemein üblich in den Geowissenschaften. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tongrube taggen
Moin, M∡rtin Koppenhoefer schrieb: Am 3. November 2010 14:37 schrieb Georg Feddern ne...@bavarianmallet.de: es scheint so, als sollte landuse=quarry mit resource=* allgemein für die oberflächliche Resourcenentnahme verwendet werden. Wikipedia:en sagt dazu: Open-pit mines that produce building materials and dimension stone are commonly referred to as quarries. People are unlikely to make a distinction between an open-pit mine and other types of open-cast mines,[citation needed] such as quarries, borrows, placers, and strip mines. das kommt aus dem Tagebau-Artikel: http://en.wikipedia.org/wiki/Open-pit_mining Eins der Probleme bei OSM ist gelegentlich, dass als Haupttag erstmal ein spezifischer Spezialfall eingeführt wird (z.B. village_green, arts_centre, etc.), und dann alles ähnliche auch damit versehen wird, weil es am ehesten passt. Ob das bei quarry auch der Fall ist, kann ich nicht beurteilen, aber es wäre m.E. nicht schlecht, wenn der Haupttag (landuse) was möglichst allgemeines bedeuten würde (Abbau von Mineralien), wo man Sandgrube, Kiesgrube, Tongrube (die sich jeweils nur in der Korngröße des abgebauten Materials unterscheiden) genauso wie Steinbrüche alles in einen Topf schmeissen kann, und die Details dann mit Subtags geklärt werden. ich habe es jetzt nochmals mehrfach überschlafen - und eben die deutsche Seite mit Erläuterungen an das englische Original angepasst. Wer jetzt daraufhin mit Steinen werfen will, wird mich schon irgendwie finden. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Am 05.11.2010 12:13, schrieb M∡rtin Koppenhoefer: Ich kann die Aversionen gegen Landcover als Tag nicht verstehen. Das ist am besten zu erkennen im Ggs. zu landuse, und meistens auch eindeutig. Der Begriff ist allgemein üblich in den Geowissenschaften. Mach ein Proposal (abwärtskompatibel zu landuse) und gut 'is. ;-) Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geschätekuddelmuddel und anderes
Hallo Ich habe hier eine Geschäft da ist drin: Bäcker, Post, Computer mehr oder wenig ein Raum, nicht allzugroß. Wie kennzeichne ich? Post wäre für mich das wichtigste, wenn ich aber Bäcker oder Computer dazu füge springt die Kennzeichnung um (OSM) was ähnliches: hier gegenüber ist son Fitnesscenter im gleichen Gebäude ist ne Schmiede/Metallbau. alles die gleiche Hausnummer Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von Orten
Am 29. Juni 2009 16:56 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Bin ich denn der einzige, der Ordnung im Wiki haben möchte? wiki/cartographie/DE:... aber nicht alles irgendwieherum klatschen. wenn wir hier schon alte Threads aufwärmen, bitte lieber cartography, sonst wird es eher schlimmer als besser mit der guten Ordnung. ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 4. November 2010 22:26 schrieb Martin Simon grenzde...@gmail.com: Am 4. November 2010 20:21 schrieb Johannes Huesing johan...@huesing.name: ... wäre ich durchaus versucht gewesen, die Betonanker der Spannseile und die Seile selbst zu mappen. Wie aber würde man Seile mit statischem Zweck eintragen, etwa auch bei Hängebrücken? Line hat sich glaube ich nur als Wert zum Schlüssel power eingebürgert. ich sehe unsere Datenmodell als ziemlich ungeeignet an, auch vom Maßstab, diese Details einzutragen, insbesondere die Seile. Bei Widerlagern und Auflagern sehe ich das evtl. schon anders und ich würde es schon begrüßen, wenn man mehr abgestimmte Details für Brücken hätte. Das wären allerdings erst mal so Dinge wie den Gesamtumriss der Brücke, womit man auch bei getrennter Fahrbahn z.B. angeben könnte, dass es doch nur _eine_ Brücke ist, einen abstimmten Weg für den Brückennamen, insb. sofern die Straße darüber einen anderen trägt, sowie einen Konstruktionstyp und ggf. Tags für Details wie Auflager (explizit und implizit also als Mengenangabe, könnte man alternativ auch mit Feldern angeben (i.d.R. eins weniger)) und Konstruktionstyp (z.B. Hängebrücke, Balkenbrücke, Bogenbrücke, Fachwerkbrücke etc. vermutlich mit Subtags, also bitte nicht als Haupttag sowas wie vorgespannte Stahlbetonplattenbalkenbrücke einführen). Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für deine Seile wohl building=yes. :-p building=rope wäre das analog. Im Bsp. Sony Center war das mit building=roof getaggt, nicht yes. Dieser Unterschied ist m.E. nicht unbedeutend. Im Ernst: ich denke um die Problematik der information dies ist *ein* Gebäude zu umgehen, die es auch immer gibt, wenn Mapper z.B. unterschiedlich hohe Gebäudeteile als separate (wenn auch verbundene) Polygone mit building=yes taggen, wäre es angebracht, Gebäude und Gebäude*teile* zu trennen - nennen wir es einmal buildingpart=*. ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff trennen, etc. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 5. November 2010 06:27 schrieb Johannes Huesing johan...@huesing.name: Wie man es auch nennt, für die Seile würde ich es nicht verwenden, da ich den Gebäudeteil nur für Knoten und geschlossene Wege definieren, Seile aber als offene Wege modellieren würde. Kannst Du das mal ausführen, wie Du Dir das in einem 2,5-D-Modell (abgesehen von den genauen Key/Values) vorstellst? Wenn man ein Linienmodell machen wollte, sollten die Stützen 2 verbundene Nodes jeweils übereinander haben, also einen vertikalen Way (da schonmal viel Spaß mit den gegenwärtigen Tools), so dass man an den oberen Node (hier der 2. Spaß) ein Seil anschließen kann. Alternativvorschlag: Umriss einzeichnen und ein externes 3D-Modell damit verlinken. Format müsste man klären, anbieten würde sich Blender (opensource), dxf / 3ds (weit verbreitet) es gibt aber natürlich noch Myaden anderer 3D-Formate (shape, stl, etc.). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Im Ernst: ich denke um die Problematik der information dies ist *ein* Gebäude zu umgehen, die es auch immer gibt, wenn Mapper z.B. unterschiedlich hohe Gebäudeteile als separate (wenn auch verbundene) Polygone mit building=yes taggen, wäre es angebracht, Gebäude und Gebäude*teile* zu trennen - nennen wir es einmal buildingpart=*. ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff trennen, etc. Das erinnert etwas an die site relation wo parkplaetze zu einkaufscentren gehoeren. Koennte doch auch an sowas adaptiert werden. Fuer Gebaeude ueber mehrere Etagen war site und level bisher hilfreich. Leider kuemmert sich keiner der großen renderer drum so das sachen die uebereinander sind auch so angezeigt werden. Im einkaufcenter der fastfood imbiss unter der pizzaria unter dem Restaurant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Am 5. November 2010 07:25 schrieb Kay Drangmeister k...@drangmeister.net: Am 03.11.2010, 20:51 Uhr, schrieb ant antof...@gmail.com: gut, aber ein echter Graustufen-Style müsste schon mehr sein als eine Graustufenkonvertierung des Originals: Es braucht stärkere Kontraste, [...] für Menschen, die keinen Farbdrucker besitzen, als auch für Farbenblinde. sehe ich auch so. Deinen Wunsch sehe ich ein, jedoch war dies nicht Zweck des Base-Layers. Dieser war es, gerade kontrastarm zu sein, d.h. die in darüber liegenden Layern besser herauszustellen. ich finde den extra Stil eine gute Übung, aber schneller wäre es vermutlich gegangen, einfach mit einer Bildbearbeitung per batch aus den bunten Tiles die Farbe rauszunehmen (desaturate o.Ä.). Eine Karte nach deinem Wunsch ist bestimmt möglich, aber nur schwer automatisch hinzubekommen. Dazu bräuchte es mehr Wissen um die (verschiedenen möglichen) Farbschwächen. es geht ja nicht primär um Farbschwächen, das ist schon richtig, aber in jedem Fall ist doch sinnvoll, die dargestellten Features auch unterscheiden zu können. So wie es jetzt ist, ist es jedenfalls Zufall, da manche Farben jetzt ähnlich aussehen, andere nicht, ohne dass das irgendjemand gewollt hätte, es ist einfach so. Wenn einen die Features nicht interessieren, oder nur grob (also z.B. alle Landuses gleich, oder Gruppen davon bilden), dann müsste man in jedem Fall manuell vorgehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Am 05.11.2010, 13:35 Uhr, schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: ich finde den extra Stil eine gute Übung, aber schneller wäre es vermutlich gegangen, einfach mit einer Bildbearbeitung per batch aus den bunten Tiles die Farbe rauszunehmen (desaturate o.Ä.). Naja, ich wollte ja zusätzlich einen mit noch reduzierter Information haben. Vielleicht (offizielle Frage an alle) sollte ich noch einen Layer generieren, der keine Straßen enthält? Evtl. möchte jemand die Straßen extra generieren und drüberlegen, z.B. streng nach width gerendert... Ich werde u.a. noch die Hausnummern aus dem reduzierten S/W-Layer rausnehmen (Widerspüche?) damit man die Möglichkeit hat, die Hausnummern als extra Layer drüberzurendern. Somit würde das Problem umgangen, dass die Hausnummern oft zu Gunsten von Icons oder anderen Texten unterdrückt werden. es geht ja nicht primär um Farbschwächen, das ist schon richtig, aber in jedem Fall ist doch sinnvoll, die dargestellten Features auch unterscheiden zu können. Eigentlich: nein! Alles was schwarz/weiß dargestellt ist sollte genau für die betroffene Karte *keine* Rolle spielen. Sie soll lediglich dazu dienen, dass man weiß wo man ist. Die gewünschte Information soll im Layer darüber angezeigt werden. Viele Grüße aus Paris, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Hallo M∡rtin, ... ... ich finde ja, landcover deckt begrifflich natural und landuse ab, verschluckt es sozusagen(?), hm, landuse sollte man in jedem Fall deutlich trennen und landcover oder natural. Landuse ist die Bodennutzung, evtl. Landnutzung jedenfalls die Nutzung. Boden-, Naturnutzung ... Ich weiss, dass das derzeit nicht ganz klar ist (im groben allerdings ist es schon so umgesetzt). Weitere Tags würde ich schon danach trennen und evtl. landuse etwas aufräumen (sind nur wenige Tags, die nicht passen). ja, da müsste man Mal ran Ebenso natural strukturieren! ... Hm, bin gerade mal auf diese Wikipediaseite gestoßen: http://de.wikipedia.org/wiki/Landnutzung interessant die interessanterweise diesen Absatz enthält: Die 13 Hauptklassen, die für alle EU-Länder den Rahmen bilden, sind: * Siedlungsflächen (incl. Verkehrsflächen) * Ackerflächen * Dauerkulturen * Grünland * Laub- und Mischwald * Nadelwald * Alpine Matten * Latschen, Krummholz * Felsflächen * Spärliche Vegetation * Gletscher * Feuchtflächen * Wasserflächen. ja, das ist der Landcover-/ Maschinen-Ansatz () der z.B. nicht zwischen natürlich und genutzt unterscheiden kann. Der dürfte genau genommen auch nicht mit Landnutzung übertitelt sein (z.B. zu Felsfläche). Das ist - spez. in solch einem großen OSM-Rahmen - fehlerträchtig. Landcover (CLC) gibt es länger als OSM (?) und den Begriff hätte man gleich am Anfang einführen können. Aber man hat einen Unterschied zwischen natural und landuse gewählt und das ist m.E. auch nicht verkehrt und - reichhaltiger. Hier wäre der Begriff natural zu diskutieren: ... natürliche Elemente, wie z.B. Landschaften oder geologische Gegebenheiten, ... natural features, mostly in terms of habitats and geological features ... die deutsche Übersetzung stimmt schon nicht: von landscape ist im Englischen nicht die Rede (möchte nicht wissen, wie es in anderen Sprachen aussieht). Zum Anderen ist (sehr) interessant, _was_ die Nutzer als natural taggen; siehe Diskussionen um natural=wood und landuse=forest. natural ist m.E. schon ein wertvoller Tag. ... An andere Stelle beschreibt der Artikel, dass Industrieländer üblicherweise zw. 20 und 50 verschiedenen Landuse-Differenzierungen anwenden. das ist schön. Dann Mal los, suchen ... :) Weitere Landcover Klassifikationsbeispiele finden sich z.B. bei GLOBCOVER http://ionia1.esrin.esa.int/docs/GLOBCOVER_Product_Specification_v2.pdf ab Seite 20. grobes Dokument (läd schlecht ... ). http://wdc.dlr.de/data_products/SURFACE/LCC/diplomarbeit_u_gessner_2005.pdf Seite 24 http://www.eea.europa.eu/publications/COR0-part1/at_download/file http://www.umweltbundesamt.at/fileadmin/site/umweltthemen/raumplanung/1_flaechennutzung/corine/CORINE_Nomenklatur.pdf http://www.corine.dfd.dlr.de/media/download/nutzerseminar19_keil_et_all.pdf ... das sind natürlich nur europäische Klassen. Ich kann die Aversionen gegen Landcover als Tag nicht verstehen. Das ist am besten zu erkennen im Ggs. zu landuse, und meistens auch eindeutig. Der Begriff ist allgemein üblich in den Geowissenschaften. landcover deckt doch die Begriffe landuse natural ab - bzw. umgekehrt(?!?). landcover bringt OSM und die user auf ein Maschinenniveau, ist ein Verlust an Genauigkeit/Info/Wertigkeit. landcover ist der plumpe tag einer Maschine und nicht Sache von OSM. Wir sind weder optische Geräte noch Rechner. Landcover (CLC) ist faszinierend, der Begriff bringt OSM aber keinen Mehrwert. Mit ergänzenden Tags ist landuse natural m.E. ausreichend und - schöner. Wofür (bloß) sollte ich landcover nehmen? Wo würden denn landuse oder natural nicht ausreichen? ... viele Grüße, t. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Am 5. November 2010 13:35 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 5. November 2010 07:25 schrieb Kay Drangmeister k...@drangmeister.net: Am 03.11.2010, 20:51 Uhr, schrieb ant antof...@gmail.com: gut, aber ein echter Graustufen-Style müsste schon mehr sein als eine Graustufenkonvertierung des Originals: Es braucht stärkere Kontraste, [...] für Menschen, die keinen Farbdrucker besitzen, als auch für Farbenblinde. sehe ich auch so. hier gibt es noch eine Karte in Graustufen: http://osmwms.itc-halle.de/ Vielleicht gefällt Euch die besser. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele GPX-Tracks sinnvoll vereinen
Am 4. November 2010 23:12 schrieb Peter Herison pheri...@web.de: Hat jemand eine Idee wie ich das am sinnvollsten mache? AFAIK kann GPS-Babel die Tracks vereinfachen, indem es die Anzahl der Punkte in Abhängigkeit von einem gegebenen Toleranz-Abstand reduziert. Damit könntest Du evtl. den Gesamttrack so reduzieren, dass er die maximale Punktanzahl einhält. Wie Du die Tracks zusammensetzen kannst (ob z.B. GPS-Babel das auch kann), weiss ich nicht, notfalls kannst Du das ja auch manuell mit jedem Texteditor machen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags für gesprengte Häuser?
Wird allerdings als normales Gebäude gerendered. Würde mich nicht wundern wenn Mapnik sogar building=no rendered. Was bei 0,003% Anteil allerdings kaum auffällt. ;-) Das war mal so, ist aber gefixt: (select way,building,leisure,railway,amenity,aeroway from prefix;_polygon where (building is not null and building != 'no') Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tongrube taggen
Am 5. November 2010 12:19 schrieb Georg Feddern ne...@bavarianmallet.de: ich habe es jetzt nochmals mehrfach überschlafen - und eben die deutsche Seite mit Erläuterungen an das englische Original angepasst. Ich habe das jetzt nochmal komplett umgestellt, weil einfach zu viele Fehler drin waren. Zunächst mal hat das mit Torfgruben nichts zu tun. Torf ist nicht mineralisch sondern organisch. Evtl. sind auch Kiesgruben damit nicht zu taggen, da bin ich mir allerdings nicht sicher (Schotter gehört dazu). Man sollte nochmal auf der englischen Liste nachfragen (habe ich gemacht). Die Diskussion hier betraf den Abbau von mineralischen Stoffen in allen Korngrößen, also von Stein über Schotter, Sand zu Ton. Ob Ton wirklich noch inbegriffen ist, weiss ich nicht genau, Schluff dito. Auch ist die Übersetzung von quarry nicht Tagebau. Tagebau ist eines der Kriterien (neben mineralisch), und heisst im englischen open cast. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 5. November 2010 13:32 schrieb Fabian sh...@nurfuerspam.de: Das erinnert etwas an die site relation wo parkplaetze zu einkaufscentren gehoeren. Ich bin gegen site für Gebäudeteile. Mehrere Gebäudeteile= ein Gebäude, (potentiell) mehrere Gebäude = eine site. Was man m.E. eher machen könnte wäre einen neuen Typ Relation, der systematisch gruppiert, z.B.: type=group group_type=site / building / river / legal_entity / ... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Am 5. November 2010 13:49 schrieb tshrub my-email-confirmat...@online.de: ich finde ja, landcover deckt begrifflich natural und landuse ab, verschluckt es sozusagen(?), hm, landuse sollte man in jedem Fall deutlich trennen und landcover oder natural. Landuse ist die Bodennutzung, evtl. Landnutzung jedenfalls die Nutzung. Boden-, Naturnutzung ... ja, aber Nutzung. Ebenso natural strukturieren! natural ist eine bunte Mischung, da sind auch Bäume, Höhleneingänge (übrigens eines der ältesten natural tags von 2007), Strände, Gipfel (2007), Buchten, Klippen (Juni 2006), Küstenlinien, einzelne Steine (block), Quellen (2007) drin. Alles kein landcover. Es stimmt einfach nicht, dass landcover in OSM natural und landuse ist. Es ist alles unstrukturiert in dem Bereich. Hm, bin gerade mal auf diese Wikipediaseite gestoßen: http://de.wikipedia.org/wiki/Landnutzung interessant geht so, ist z.T. ziemlich unfundiert zusammengewürfelt, so ähnlich wie unser Wiki ;-), m.E. deutlich unter dem Standard des durchschnittl. Wikipedia-Artikels. ja, das ist der Landcover-/ Maschinen-Ansatz () der z.B. nicht zwischen natürlich und genutzt unterscheiden kann. Der dürfte genau genommen auch nicht mit Landnutzung übertitelt sein (z.B. zu Felsfläche). Das ist - spez. in solch einem großen OSM-Rahmen - fehlerträchtig. ja, ich habe da schon ein paar Hinweise ergänzt, müssen aber wohl erst noch geprüft (und abgelehnt?) werden... Landcover (CLC) gibt es länger als OSM (?) und den Begriff hätte man gleich am Anfang einführen können. Aber man hat einen Unterschied zwischen natural und landuse gewählt und das ist m.E. auch nicht verkehrt und - reichhaltiger. man hat da nichts gewählt, irgendjemand hat mal ein paar der natürlichen Bodenbedeckungen in natural einsortiert, aber soweit ich das recherchiert habe nicht am Anfang des natural tags sondern später. Hier wäre der Begriff natural zu diskutieren: ... natürliche Elemente, wie z.B. Landschaften oder geologische Gegebenheiten, und geographische Punkte wie Bucht, Klippe, Gipfel, ... ... An andere Stelle beschreibt der Artikel, dass Industrieländer üblicherweise zw. 20 und 50 verschiedenen Landuse-Differenzierungen anwenden. das ist schön. Dann Mal los, suchen ... :) wozu? Wir machen das besser ;-). Klar, man kann sich mal ansehen, was die so haben, aber komplett wegwerfen wird man unser Schema ja kaum, und wenn man nur alle Unterarten der orchards zusammenzählt kommt man vermutlich schon auf über 50 ;-) landcover deckt doch die Begriffe landuse natural ab - bzw. umgekehrt(?!?). nein, m.E. nicht. Ein paar Tags sind in natural drin, noch weniger in landuse. Das ist nicht enthalten sondern großteils orthogonal, insb. zu landuse. landcover bringt OSM und die user auf ein Maschinenniveau, ist ein Verlust an Genauigkeit/Info/Wertigkeit. es soll ja zusätzlich getaggt werden, nicht stattdessen. Wofür (bloß) sollte ich landcover nehmen? für eine Ansammlung von Bäumen, die kein Wald ist? Für sand am Strand? Für Fels am Strand? Für Wälder wo keine Bäume wachsen (landuse=forest, landcover=scrubs), für Grassflächen, die keine Wiesen sind, für Wüsten (natural=desert), um die Bodenbedeckung zu klären, etc. Für Micromapping in der Stadt ist es natürlich auch geeignet. Es tauchen immer wieder solche Fälle auf. z.T. geht es mir auch um ein semantisches Geraderücken und um Klarheit für kommende Werte. Wir haben bisher rein Europa zentrierte Tags für Bodenfeatures. Schon jetzt ist es teilweise chaotisch. landuse sollte m.E. die Bodennutzung beschreiben, landcover die Bodenbedeckung, und natural bleibt für die geografischen features. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Am 05.11.2010 16:17, schrieb M∡rtin Koppenhoefer: landuse sollte m.E. die Bodennutzung beschreiben, landcover die Bodenbedeckung, und natural bleibt für die geografischen features. Sehe ich grundsätzlich auch so. Aber warum ein neues (?) Tag landcover einführen, wenn es das etablierte surface auch tut? Die Bedeutung ist m.E. die gleiche und es verhindert, dass es wieder mehrere Tags für die gleiche Eigenschaft gibt. Gruß, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschätekuddelmuddel und anderes
Am 05.11.2010 13:00, schrieb Steffen Heinz: Hallo Ich habe hier eine Geschäft da ist drin: Bäcker, Post, Computer mehr oder wenig ein Raum, nicht allzugroß. ich hab ne Lösung gefunden im Netz und hoffe das das recht ist: einen Rahmen ziehen, diesen mit der Hausnummer versehen und alles reinpacken was unter dieser Hausnummer angeboten wird, was getan wird. Hat ne ganze Weile gedauert bis ich die Lösung endlich hatte - es ist halt die Kunst die richtigen Wörter zum Suchen zu haben Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Original-Nachricht Datum: Fri, 5 Nov 2010 10:08:48 +0100 Von: M∡rtin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen? ja, man sollte einfach mal ins Wiki schreiben, dass width die Fahrbahnbreite ohne Gehsteige enthalten sollte. Im Wiki dämmert viel Information vor sich hin, ohne von der Mehrheit beachtet zu werden. Tags ohne Sichtbarkeit auf der Karte haben wenig Chancen überhaupt wahrgenommen zu werden. Ausserdem wurde ja das Wiki von höherer Stelle als reines Vorschlagswesen eingestuft ;) ja, oder auch schmaler. In Z18 ist die OSM-Straße meist schmaler als die Realität. Stimmt, Fällt z.B. hier unangenehm auf: http://www.openstreetmap.org/?lat=52.08868lon=8.69753zoom=17layers=B000FTF In dieser Zoomstufe wird die vorhandene Fläche nicht effektiv zur Darstellung der Fahrbahneinzelheiten genutzt. Möglich ist z.B. diese Darstellung (noch ausbaufähig): http://img214.imageshack.us/img214/2618/bosmcrossing2.png Dass es GoogleCo (noch) nicht hinbekommen, so aufgelöst darzustellen, da auch z.B. GDF hier alles andere als optimal ist, ist eine andere Sache. Aber OSM will doch in jeder Beziehung anders und vor allem besser sein als das ewige Vorbild. Gruesse Hubert -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
so einen aehnlichen vorschlag gabs schonmal in der diskussion wollte es aber lieber jemandem mit besserem verstaendnis der engl sprache ueberlassen. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site M∡rtin Koppenhoefer wrote: Am 5. November 2010 13:32 schrieb Fabian sh...@nurfuerspam.de: Das erinnert etwas an die site relation wo parkplaetze zu einkaufscentren gehoeren. Ich bin gegen site für Gebäudeteile. Mehrere Gebäudeteile= ein Gebäude, (potentiell) mehrere Gebäude = eine site. Was man m.E. eher machen könnte wäre einen neuen Typ Relation, der systematisch gruppiert, z.B.: type=group group_type=site / building / river / legal_entity / ... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenverzeichnis aufgeräumt
Hi, ich habe mir gerade [2]angesehen. Was bedeutet denn am Anfang der Seite der Hinweisblaken mit This page has been suggested for clean-up. Please Discuss. ?? Gruß hike39 Am 04.11.2010 10:57, schrieb Jan Tappenbeck: hi ! da die Seite mit den Straßenverzeichnissen [1] extrem lang wurde habe ich diese nach den Bundesländern einmal aufgeteilt. Nun wäre es noch nice to have die Anfragen an die Kommunen [2] aufzuteilen - vielleicht können sich die betroffenen dem einmal annehmen. Gruß Jan :-) [1] http://wiki.openstreetmap.org/wiki/Stra%C3%9Fenverzeichnis [2] http://wiki.openstreetmap.org/wiki/Stra%C3%9Fenverzeichnis#Anfragen.2C_die_an_Kommunen_gestellt_wurden ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frage bezüglich Landes-, Stadt- und Stadteilgrenzen
Hallo, sehe ich es richtig, dass ein boundary=administrative admin_level=9 nur _in_ einem boundary=administrative admin_level=8 liegen kann? Und ein boundary=administrative admin_level=8 dementsprechend auch nur _in_ einem z.B. boundary=administrative admin_level=4? Oder ist das ein Trugschluß? Danke Tom ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 05.11.2010 13:22, schrieb M∡rtin Koppenhoefer: ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff trennen, etc. Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch mit Komzpa (Entwickler von Kothic) abgestimmt. Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen Proposal-Prozess einzubringen, aber hier passt das vielleicht rein, und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich willkommen. Gruß Peter [1] http://wiki.openstreetmap.org/wiki/User:Jongleur/MultiLevel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Hallo M∡rtin, ... ... ... natural ist eine bunte Mischung, da sind auch Bäume, Höhleneingänge (übrigens eines der ältesten natural tags von 2007), Strände, Gipfel (2007), Buchten, Klippen (Juni 2006), Küstenlinien, einzelne Steine (block), Quellen (2007) drin. Alles kein landcover. Es stimmt einfach nicht, dass landcover in OSM natural und landuse ist. das cover kann sich doch aus der Flächengröße ergeben? beim Rendern kann man zu kleine Flächen als Bäumchen darstellen, wenn jemand Unterschied sehen will? ... ... Wofür (bloß) sollte ich landcover nehmen? für eine Ansammlung von Bäumen, die kein Wald ist? landuse=forest die _Größe_ (Fläche) macht den Wald ... bei landcover auch nicht anders. Für sand am Strand? natural=beach (meist naturdominiert, ausser einigen künstlich erhaltenen für Touris) Für Fels am Strand? natural=rock? Für Wälder wo keine Bäume wachsen (landuse=forest, landcover=scrubs), Niederwald ist landuse=scrub oder natural=scrub (natürliche Extremstandorte) für Grassflächen, die keine Wiesen sind, hatten wir oben in einem Thread, ich denk, das war landuse=grassland und landuse=meadow für die Wiese für Wüsten (natural=desert), ja um die Bodenbedeckung zu klären, etc. Für Micromapping in der Stadt ist es natürlich auch geeignet. na ja. da denkt ich wieder wenigern an _land_cover - das wäre übertrieben ;) surface oder material wäre da naheliegender - in Verbindung mit einem Elterntag. ... landuse sollte m.E. die Bodennutzung beschreiben, landcover die Bodenbedeckung, und natural bleibt für die geografischen features. landuse = Bodennutzung (meadow, field, forest, residential, ...) landcover = Bodenbedeckung (gras, vegetables, trees, garden, ...) natural = geografische features (bog, ?, conifers, Rosengarten, ...) wäre irgendwie machbar, aber überzeugt mich noch nicht richtig. Es geht ja um das Strukturieren der Userdeutungen/Begriffsbildung. Und da muss man wohl - bei dem breiten Spektrum an usern, die mit den Objekten manchmal nichts weiter zu tun haben - mal ein paar Worte (mehr) in den Pool werfen ... (auch der Unterhaltung wege) und sehen, was hängen bleibt. mal sehen, wie es landcover ergeht. ... viele Grüße, t. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele GPX-Tracks sinnvoll vereinen
Am 05.11.2010 06:44, schrieb Christian Knorr: Am Donnerstag 04 November 2010, um 23:12:29 schrieb Peter Herison: moeglichst an einem Stueck wieder zusammen zu setzen. Da fällt mir jetzt JOSM ein. Das kann doch osm nach gpx exportieren. Musst halt nur vorher Ballast abwerfen - ich weiß ja nicht wie groß das Gelände ist. Zum Teil muessen die Stueckchen auch verdoppelt und in umgedrehter Reihenfolge wieder eingefuegt werden (Sackgassen). Wofür das? Brauchst Du das zum navigieren? Wenn ich Tracks aneinander haenge, deren Ende und Anfang nicht dicht beieinader liegen zeichnet das GPS60 eine lange Gerade dazwischen. Das Ganze ist, wie geschrieben, nur als Orientierung gedacht, um sich im Gelaende besser orientieren zu koennen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele GPX-Tracks sinnvoll vereinen
Moin moin Danke fuer die Tipps, aber ich suche weniger einen Editor, sondern ein Programm, das mir die optimale Reihenfolge fuer die Stueckchen raussucht, und zusaetzlich noch so intelligent ist, bei Sackgassen den Weg zureuck mit einzuberechnen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
M∡rtin Koppenhoefer dieterdre...@gmail.com [Fri, Nov 05, 2010 at 01:29:51PM CET]: Am 5. November 2010 06:27 schrieb Johannes Huesing johan...@huesing.name: Wie man es auch nennt, für die Seile würde ich es nicht verwenden, da ich den Gebäudeteil nur für Knoten und geschlossene Wege definieren, Seile aber als offene Wege modellieren würde. Kannst Du das mal ausführen, wie Du Dir das in einem 2,5-D-Modell (abgesehen von den genauen Key/Values) vorstellst? So weit habe ich nicht gedacht. Die x- und y-Koordinaten der Seile sind unabhängig von ihren Höhen interessant, weil man bei drohendem Eisfall nicht drunter langgehen sollte. (Dann ist allerdings auch das gesamte Gelände für Zutritt verboten.) Aber ok, wenn man schon mal dabei ist: Wenn man ein Linienmodell machen wollte, sollten die Stützen 2 verbundene Nodes jeweils übereinander haben, Ja, mit passenden height-Tags. also einen vertikalen Way (da schonmal viel Spaß mit den gegenwärtigen Tools), Nur wenn man den Mast in senkrechter Richtung modellieren möchte. Da wäre ich aber zufrieden, wenn ein Node mit Tags man_made=tower, tower:type=communication, height=360 den Mast modellierte. Auf dieselbe Koordinate würden dann die Anknüpfungspunkte mit entsprechendem height als einzigem Tag stehen. Bei so etwas wie dem Sonnensegel am Potsdamer Platz könnte ich mir auch vorstellen, einzelne Ecken mit einem height-Tag zu versehen. Mit den gegenwärtigen Tools ist das machbar, macht aber keinen großen Spaß. Ich habe mal aus einer Laune heraus das Atomium eingezeichnet, war aber dann nicht sehr stolz auf das Ergebnis. Aber solche Gebäude gibt es ja auch nur ein paar Mal. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
M∡rtin Koppenhoefer dieterdre...@gmail.com [Fri, Nov 05, 2010 at 01:22:20PM CET]: [...] ich sehe unsere Datenmodell als ziemlich ungeeignet an, auch vom Maßstab, diese Details einzutragen, insbesondere die Seile. Bei Widerlagern und Auflagern sehe ich das evtl. schon anders und ich würde es schon begrüßen, wenn man mehr abgestimmte Details für Brücken hätte. Du bist da ja Experte, ich musste irgendwann mal lernen, dass in bestimmten Plänen Brücken durch ihre Widerlager angegeben sind. Das wären allerdings erst mal so Dinge wie den Gesamtumriss der Brücke, womit man auch bei getrennter Fahrbahn z.B. angeben könnte, dass es doch nur _eine_ Brücke ist, einen abstimmten Weg für den Brückennamen, insb. sofern die Straße darüber einen anderen trägt, sowie einen Konstruktionstyp und ggf. Tags für Details wie Auflager Da finde ich ja immer den Wert yes verschwendet und gebe auch so etwas an wie bridge=pontoon. (explizit und implizit also als Mengenangabe, könnte man alternativ auch mit Feldern angeben (i.d.R. eins weniger)) und Konstruktionstyp (z.B. Hängebrücke, Balkenbrücke, Bogenbrücke, Fachwerkbrücke etc. vermutlich mit Subtags, also bitte nicht als Haupttag sowas wie vorgespannte Stahlbetonplattenbalkenbrücke einführen). Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für deine Seile wohl building=yes. :-p building=rope wäre das analog. Ein Seil als Bauwerk anzusehen finde ich fast noch abartiger als eine Treppe als Spezialform einer Landstraße zu taggen. Im Bsp. Sony Center war das mit building=roof getaggt, nicht yes. Dieser Unterschied ist m.E. nicht unbedeutend. Eben drum, yes sollte man nehmen, wenn man es nicht spezifischer haben möchte. (Eigentlich wäre highway=yes in der Hinsicht klarer als highway=road.) ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff trennen, etc. So wie hier? http://www.openstreetmap.org/browse/way/56007564/ -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 04.11.2010 22:37, schrieb Chris66: Am 04.11.2010 22:14, schrieb Garry: Man kann service auch als zweckgebundene Strasse betrachten die überwiegend (ich möchte nicht sagen ausschliesslich) eben einem speziellen Zweck dient, dabei aber durchaus auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. Genau. Siehe Zu- und Abfahrten zu Autobahnraststätten, die meist auch als service getaggt sind. Bin zwar kein Routerprogrammierer, aber einen Check ob eine service-Road mit einer route=ferry verbunden ist (um sie für's Routing intern höher zu stufen) stelle ich mir nicht schwierig vor. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Chris, und das ist eben der Irrglaube vieler. Das ist genau der Grund, welcher die Router tötet. Dies ist mit einem LookAhead verbunden, der, solange die Datenmenge klein ist, z.B. Städte oder max. Bundesländer, noch einigermaßen performant zu berechnen ist. Im Länder- oder Kontinent-Rahmen ist die Rechenzeit dann unerträglich. Dann kommen Heuristiken ins Spiel. Zu bedenken ist hierbei auch die Tatsache, dass nach einer Ferry ein Service, dann noch ein Service, vielleicht noch ein Service und dann erst ein highway=höher folgt. Um das zu greifen, lohnt es sich kaum noch irgendwas zu betrachten, sondern stattdessen gleich alle Services mit einzubeziehen oder eben auszublenden. Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am Freitag, 5. November 2010, 10:08:48 schrieb M∡rtin Koppenhoefer: Osmarender wertet width für Flüsse aus. das ist was ziemlich anderes und kartographisch üblich. Es würde mich stark wundern, wenn das eine allgemeine Aussage ist. Das hängt doch vom Sinn und Zweck der jeweiligen Karte ab. Straßen sind i.d.R. so wichtig, daß man die immer sehen will und die Breite damit abhängig vom Maßstab überzeichnen muß. Spezialkarten für Gewässer sollten dasselbe für diese tun, oder? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage bezüglich Landes-, Stadt- und Stadteilgrenzen
On Fri, Nov 05, 2010 at 06:27:23PM +0100, Tom Müller wrote: Hallo, sehe ich es richtig, dass ein boundary=administrative admin_level=9 nur _in_ einem boundary=administrative admin_level=8 liegen kann? Und ein boundary=administrative admin_level=8 dementsprechend auch nur _in_ einem z.B. boundary=administrative admin_level=4? Oder ist das ein Trugschluß? Noe - das passt so - Die administrativen grenzen sind immer Absteigend. Es kann sein das sie Deckungsgleich sind - aber dann sollten die nur einmal existieren. Also z.b. das thema Kreisfreie Stadt - Waere ja quasi admin_level 6 und admin_level 8 - Wobei nur ersteres existieren sollte. Typischerweise sollten sogar immer mehrere admin_level a-1 innerhalb eines admin_level a sein ... Flo -- Florian Lohoff f...@zz.de Professionell gesehen bin ich zu haben signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Hallo Jan, Am 05.11.2010 21:04, schrieb Jan Tappenbeck: Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Wat nu? Netbook oder Tablet? Ubuntu Netbook Edition? JAVA Embedded? Das Thema interessiert mich, da ich auch mit dem Gedanken spiele mir was kleines anzuschaffen. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Hallo, Am Freitag 05 November 2010 21:04:24 schrieb Jan Tappenbeck: Hi ! wie intensiver ML-Leser sicherlich mitbekommen haben bin ich seit dem Sommer Netbook-Anwender u.a. für JOSM. Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Was mich aber seit längerem stört ist die Tatsache das einige Dialoge und teilweise auch einige Funktionen nicht gerade Netbook tauglich sind. Es wäre aus meiner Sicht ein Anfang wenn einige Dinge ergonomischer wären - als Beispiel die Überdimensionalität des Einstellungsdialog den man immer nur mit Mühe und Not geschlossen bekommt. Nun wollte ich mal hören, ob es zwischenzeitlich weitere Anwender gibt die über dieses Problem zu kämpfen haben. Josm ist auf Netbooks nicht benutzbar. Die Menüs sind längenmäßig einfach Overkill. Das ist hier auch schon mal geschrieben worden. Ich verwende hier osm2go. Das muss allerdings für Linux-Systeme allerdings im Source runtergeladen und übersetzt werden. Ist aber ganz einfach. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 05.11.2010 10:20, schrieb M∡rtin Koppenhoefer: Am 4. November 2010 22:14 schrieb Garrygarr...@gmx.de: Man kann service auch als zweckgebundene Strasse betrachten die... auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. Das übrigens glaube ich nicht. Du wirst m.E. keine Straße finden, die ein annähernd autobahnähnliches Verkehrsaufkommen hat, und die man (auch nicht nach Deiner Definition) als service bezeichnen kann. Freue mich schon, wenn Du doch ein Beispiel findest, aber ich bezweifle das sehr. Dann stell Dich z.B. mal in der Hochsaison morgens an die Parkplatzzufahrt zum Europpark. 4Millionen Besucher/Saison machen überschlagen (200Besuchstage,4Personnen/Fahrzeug) im Schnitt 5000PKW/Tag die aber grösstenteils morgens innerhalb 2h anfahren und abends im gleichen Zeitrahmen abfahren. Bei vielen grossen Messen ergibt sich ein ähnliches Bild, wenn auch an weniger Tagen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Hallo Johannes, Hallo Martin, Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen des Funkmastes, sondern um dieses allgemeine Konzept für gestückelte Gebäude, das ich mal in den Raum stellen wollte. (wie wär's mit man_made=cable, cable=suspension als Mitglied in einer Building-Relation zusammen mit dem Mast und den Widerlagern?) Am 5. November 2010 13:22 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für deine Seile wohl building=yes. :-p building=rope wäre das analog. Im Bsp. Sony Center war das mit building=roof getaggt, nicht yes. Dieser Unterschied ist m.E. nicht unbedeutend. OK, habe ich unterschlagen. ;-) Ja, nicht unbedeutend, nur tritt es leider damit immer noch als eigenständiges Gebäude auf. ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff trennen, etc. Ja, schön illustriert werden diese Möglichkeiten ja bereits z.B. bei www.osm-3d.org . Beispiele für Gebäude, die unterschiedliche Stockwerkszahlen haben und bei denen ich damit unzufrieden bin, daß sie derzeit nach dem 'alten' Schema als Sammlung einzelner Gebäude getaggt sind, befinden sich z.B. auf diesem Campus (das Hauptgebäude mit Mensa und das Gebäude der Fakultät 06 im Norden): http://osm.org/go/0...@ggdra-?layers=o Vielleicht kriegen wir da etwas auf die Beine gestellt, das durchdacht ist und Akzeptanz unter den Mappern und Renderern finden kann... :) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 05.11.2010 21:43, schrieb Wolfgang: Hallo, Am Freitag 05 November 2010 21:04:24 schrieb Jan Tappenbeck: Hi ! wie intensiver ML-Leser sicherlich mitbekommen haben bin ich seit dem Sommer Netbook-Anwender u.a. für JOSM. Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Was mich aber seit längerem stört ist die Tatsache das einige Dialoge und teilweise auch einige Funktionen nicht gerade Netbook tauglich sind. Es wäre aus meiner Sicht ein Anfang wenn einige Dinge ergonomischer wären - als Beispiel die Überdimensionalität des Einstellungsdialog den man immer nur mit Mühe und Not geschlossen bekommt. Nun wollte ich mal hören, ob es zwischenzeitlich weitere Anwender gibt die über dieses Problem zu kämpfen haben. Josm ist auf Netbooks nicht benutzbar. Die Menüs sind längenmäßig einfach Overkill. Das ist hier auch schon mal geschrieben worden. Ich verwende hier osm2go. Das muss allerdings für Linux-Systeme allerdings im Source runtergeladen und übersetzt werden. Ist aber ganz einfach. Gruß, Wolfgang das werde ich dann auch nochmal ausprobieren - wenn fragen sind weiß ich ja schon wenn ich fragen muss. hast dich geoutet. gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 05.11.2010 21:24, schrieb René Falk: Hallo Jan, Am 05.11.2010 21:04, schrieb Jan Tappenbeck: Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Wat nu? Netbook oder Tablet? Ubuntu Netbook Edition? JAVA Embedded? Das Thema interessiert mich, da ich auch mit dem Gedanken spiele mir was kleines anzuschaffen. Grüße René hi ! habe ein ASUS T100MT - wenn ich die Bezeichnung richtig in Erinnerung habe. Das mit der Auswahl von Punkten über Stifte ist noch etwas schwierig und ungenau. Mit der Maus ist das besser. Bitte vergesse das nicht. Gibt auch eine Wiki-Seite dazu und ein Anfang für ein spezielles PlugIn. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Garry schrieb: Am 05.11.2010 10:17, schrieb M∡rtin Koppenhoefer: Man kann service auch als zweckgebundene Strasse betrachten die überwiegend (ich möchte nicht sagen ausschliesslich) eben einem speziellen Zweck dient, dabei aber durchaus auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. könnte man vielleicht (auch wenn ich dafür bisher keine Anhaltspunkte sehe), aber es würde die Lage m.E. nicht verbessern sondern deutlich verschlimmern und es würde nicht mehr klar sein, was man zu erwarten hat, wenn highway=service getaggt ist. Sollte nur eine Beschreibung bzw. Auslegungsvariante von service sein, für den Router taugt das so alleine nicht, also entweder Zusatztag oder gleich einen highway-tag für solche Zufahrten auf weiterführende Verkehrsmittel. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Zusatztag wäre - denke ich - eine gute Kompromisslösung und zudem auch angenehm pragmatisch. Die Services würden so unberührt bleiben und einfach nur noch einmal näher beschrieben werden. Dafür braucht man noch nicht einmal vor Ort zu sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 05.11.2010 21:43, schrieb Wolfgang: Josm ist auf Netbooks nicht benutzbar. Doch, ich benutze JOSM seit zwei Jahren auf einem eeePC. Einziges Problem: einige Preset-Menüs sind nicht erreichbar - ungünstig bei Vorführungen für OSM-Einsteiger, aber beim normalen Editieren braucht man das nicht unbedingt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 05.11.2010 21:43, schrieb Wolfgang: Hallo, Am Freitag 05 November 2010 21:04:24 schrieb Jan Tappenbeck: Hi ! wie intensiver ML-Leser sicherlich mitbekommen haben bin ich seit dem Sommer Netbook-Anwender u.a. für JOSM. Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Was mich aber seit längerem stört ist die Tatsache das einige Dialoge und teilweise auch einige Funktionen nicht gerade Netbook tauglich sind. Es wäre aus meiner Sicht ein Anfang wenn einige Dinge ergonomischer wären - als Beispiel die Überdimensionalität des Einstellungsdialog den man immer nur mit Mühe und Not geschlossen bekommt. Nun wollte ich mal hören, ob es zwischenzeitlich weitere Anwender gibt die über dieses Problem zu kämpfen haben. Josm ist auf Netbooks nicht benutzbar. Die Menüs sind längenmäßig einfach Overkill. Das ist hier auch schon mal geschrieben worden. Ich kenne zwei Leute die mit JOSM auf dem Netbook anscheinend ganz gut klarkommen. Klar, mit Einschränkungen muß man dabei leben. Es sollten halt die Leute mit Netbooks und dessen spezifischen Problemen, *spezifische* Problembeschreibungen im JOSM trac hinterlegen Menu xy ist auf einem Display mit 800*600 Pixeln zu lang - dann können die JOSM Entwickler schauen, ob da was zu machen ist. Nur rummosern das geht nicht hilft nicht wirklich weiter. Gruß, ULFL P.S: Das Hauptkriterium beim Kauf meines Netbooks war für mich die Displayauflösung von 1024*768 Pixeln. Ich wußte warum ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Martin Simon grenzde...@gmail.com [Fri, Nov 05, 2010 at 09:57:52PM CET]: Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen des Funkmastes, sondern um dieses allgemeine Konzept für gestückelte Gebäude, das ich mal in den Raum stellen wollte. Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso, aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Marktflächen/Parkplätze
Hallo, in Hamburg gibt es viele Marktfächen, die zu Nicht-Marktzeiten als Parkflächen genutzt werden. amenity=markingplace;parking ? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 05.11.2010 22:24, schrieb Ulf Möller: Am 05.11.2010 21:43, schrieb Wolfgang: Josm ist auf Netbooks nicht benutzbar. Doch, ich benutze JOSM seit zwei Jahren auf einem eeePC. Einziges Problem: einige Preset-Menüs sind nicht erreichbar Ich hab da in letzter Zeit die Menus auch in diesem Hinblick etwas umgebaut, sollte aktuell bei 800*600 kein Problem mehr sein. ungünstig bei Vorführungen für OSM-Einsteiger, aber beim normalen Editieren braucht man das nicht unbedingt. Was soll das denn bedeuten ;-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Hallo, Am Freitag 05 November 2010 22:24:45 schrieb Ulf Möller: Am 05.11.2010 21:43, schrieb Wolfgang: Josm ist auf Netbooks nicht benutzbar. Doch, ich benutze JOSM seit zwei Jahren auf einem eeePC. Einziges Problem: einige Preset-Menüs sind nicht erreichbar - ungünstig bei Vorführungen für OSM-Einsteiger, aber beim normalen Editieren braucht man das nicht unbedingt. Unbenutzbar ist außerdem das Menü Werkzeuge. Das Menü Einstellungen ist verschiebbar, wenn die ALT-Taste festgehalten wird. Die Abhilfe wäre so einfach: Ein Scrollbar an den Menüs Werkzeuge und Vorlagen. Meine Abhilfe osm2go. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 4. November 2010 20:39 schrieb Garry garr...@gmx.de: Davon abgesehen waren die Freunde der Flughäfen in OSM schon sehr früh sehr fleissig und haben die Landebahnen schon vor Jahren vielfach auch mit Rollwegen eingetragen so dass es diesbezüglich kaum noch etwas zu mappen gibt. Einer war sogar so fleißig, Landebahnen zu taggen, die nur in seinem Kopf existieren - nämlich solche auf Modellfluggeländen, die schlicht eine Rasenfläche ohne Markierung und jeglichen linearen Charakter... ...denn es wird ja bereits so schön gerendert... Zum eigentlichen Thema: Wenn eine wichtige Verkehrsverbindung über ein Fährterminal und eine Fähre führt, sollten die dort eingeschlossenen Wege selbstverständlich die Klassen beibehalten, unabhänging von Geschwindigkeit (das berücksichtigen selbst simple Router schon separat) und Breite. Auch Ortsdurchfahrten von Bundesstraßen (immer überregionale Verbindungen) werden heutzutage aus Gründen der Sichertheit und des Komforts für Fußgänger und Radfahrer schmaler (breitere Bürgersteige) und langsamer ausgebildet, als es möglich wäre und früher praktiziert wurde, wenn die beengten Platzverhältnisse dazu Anlass geben. Die paar dm und km/h weniger ärgern vielleicht den Autofahrer, ändern aber nichts an der Verbindungsfunktion. Daher gehen wir dort auch nicht auf secondary, tertiary oder residential herunter. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 5. November 2010 22:29 schrieb Johannes Huesing johan...@huesing.name: Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso, aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein. [x] check! ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 5. November 2010 18:36 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch mit Komzpa (Entwickler von Kothic) abgestimmt. Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen Proposal-Prozess einzubringen, aber hier passt das vielleicht rein, und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich willkommen. Hallo Peter! Das Schema war mir noch gar nicht über den Weg gelaufen. Vielleicht kann man die Vorteile aus allen Ansätzen kombinieren. :-) Du schneidest dabei deine Gebäude horizontal, ich hatte eher eine vertikale Unterteilung im Sinn (bei deinem Beispiel(von links nach rechts): A: [7 Stockwerke], B: [5 Stockwerke, beginnend mit dem 3.], A: [7 Stockwerke]). Damit könnte man alles in einem Abwasch erledigen und sowohl solche Durchlässe als auch unterschiedliche Dachhöhen darstellen. Hat das horizontale schneiden einen Vorteil dem gegenüber, den ich übersehe? Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 05.11.2010 23:01, schrieb Martin Simon: Am 5. November 2010 18:36 schrieb Peter Wendorffwendo...@uni-paderborn.de: Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch mit Komzpa (Entwickler von Kothic) abgestimmt. Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen Proposal-Prozess einzubringen, aber hier passt das vielleicht rein, und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich willkommen. Hallo Peter! Das Schema war mir noch gar nicht über den Weg gelaufen. Vielleicht kann man die Vorteile aus allen Ansätzen kombinieren. :-) Dass Dir das noch nicht über den Weg gelaufen ist, hab ich mir gedacht; bisher hab ich es auch noch praktisch nicht beworben, und (außer in meiner Bachelorarbeit als Randnotiz) nirgendwo verlinkt. Im Grunde genommen ist das im momentanen Zustand ein Abfallprodukt von wie mappe ich ;) Ich plane aber, in den nächsten Wochen/Monaten daran weiterzubasteln und es auch in einen normalen Proposal-Prozess einzubringen. Auch in der Hinsicht sind mir Kommentare und Verweise zu anderen Schemata natürlich willkommen. Du schneidest dabei deine Gebäude horizontal, ich hatte eher eine vertikale Unterteilung im Sinn (bei deinem Beispiel(von links nach rechts): A: [7 Stockwerke], B: [5 Stockwerke, beginnend mit dem 3.], A: [7 Stockwerke]). Damit könnte man alles in einem Abwasch erledigen und sowohl solche Durchlässe als auch unterschiedliche Dachhöhen darstellen. Hat das horizontale schneiden einen Vorteil dem gegenüber, den ich übersehe? Bei den Universitätsgebäuden in Paderborn hat das horizontale Schneiden vor allem praktisch einen Vorteil; die Alternative hab ich gar nicht als solche gesehen gehabt zu dem Zeitpunkt. Hab jetzt ernsthaft etwas über die Frage nachdenken müssen ;) Ich denke aber, es gibt einen Vorteil: Schneidet man vertikal in einzelne Säulen, geht der Zusammenhang der Etage verloren. Beim horizontalen Schneiden beschreibt ein Polygon immer noch die Außenwand dieses Stockwerks, was insbesondere zusätzlich das mapping von Innenwänden später erlauben würde. Betrachtet man ein Gebäude, das z.B. eine Brücke bildet, dann ist die senkrechte Wand mittendrin eben nur da, wo auf einer Seite davon nichts mehr ist - das beschreibt mein Ansatz. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 05.11.2010 22:29, schrieb Johannes Huesing: Martin Simongrenzde...@gmail.com [Fri, Nov 05, 2010 at 09:57:52PM CET]: Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen des Funkmastes, sondern um dieses allgemeine Konzept für gestückelte Gebäude, das ich mal in den Raum stellen wollte. Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso, aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein. (ok) Anforderung erfüllt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OT: Haartracht mappen (was: Gebäud e-Mapping)
aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein. Wenn Ihr letztere taggen wollt, dann macht Ihr aber bitte einen eigenen Thread auf -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
ulf.lamp...@googlemail.com (Ulf Lamping) am 05.11.10: P.S: Das Hauptkriterium beim Kauf meines Netbooks war für mich die Displayauflösung von 1024*768 Pixeln. Ich wußte warum ;-) Meine Kaufkriterien waren Bezahlbakeit, lange Akkulaufzeit und Fotorucksacktauglichkeit. Alles zusammen gab es nicht mit 1024*768 oder größer. Wähle drei aus vier. Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Mapping Party Comune Venezia
2010/10/31 Gianluca De Rossi bigshot4e...@gmail.com: Se qualcuno è disponibile (considerando che dovremmo avere addirittura la disponibilità per eventuali rimborsi spese di viaggio/trasporto) faccia un fischio :) Io ci sono. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it