[Talk-kosovo] more serbian naming nonsense
I check the first ones, you will have to look at them! http://www.openstreetmap.org/browse/node/299447753 Podujevo is in serbia! http://www.openstreetmap.org/browse/node/448559377 Стари Обилић! http://www.openstreetmap.org/browse/node/448561529 Брезовица http://www.openstreetmap.org/browse/node/448562567 is_in:country = Serbia http://www.openstreetmap.org/browse/node/448564335 namehttp://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US= Беревци, http://www.openstreetmap.org/browse/node/448564582 http://www.openstreetmap.org/browse/node/448564772 http://www.openstreetmap.org/browse/node/448568586 http://www.openstreetmap.org/browse/node/448569223 http://www.openstreetmap.org/browse/node/448569266 http://www.openstreetmap.org/browse/node/448571580 http://www.openstreetmap.org/browse/node/448572280 http://www.openstreetmap.org/browse/node/448575605 http://www.openstreetmap.org/browse/node/448706637 http://www.openstreetmap.org/browse/node/448708202 http://www.openstreetmap.org/browse/node/448708566 http://www.openstreetmap.org/browse/node/448710265 http://www.openstreetmap.org/browse/node/448710692 http://www.openstreetmap.org/browse/node/448712433 http://www.openstreetmap.org/browse/node/448719365 http://www.openstreetmap.org/browse/node/448719534 http://www.openstreetmap.org/browse/node/448721514 http://www.openstreetmap.org/browse/node/448721772 http://www.openstreetmap.org/browse/node/448722877 http://www.openstreetmap.org/browse/node/448723843 http://www.openstreetmap.org/browse/node/448726159 http://www.openstreetmap.org/browse/node/448726177 http://www.openstreetmap.org/browse/node/448726882 http://www.openstreetmap.org/browse/node/448727750 http://www.openstreetmap.org/browse/node/448732500 http://www.openstreetmap.org/browse/node/448734572 http://www.openstreetmap.org/browse/node/453332043 http://www.openstreetmap.org/browse/node/453332998 http://www.openstreetmap.org/browse/node/45924 http://www.openstreetmap.org/browse/node/453334206 http://www.openstreetmap.org/browse/node/453334651 http://www.openstreetmap.org/browse/node/453335625 http://www.openstreetmap.org/browse/node/453335670 http://www.openstreetmap.org/browse/node/453337969 http://www.openstreetmap.org/browse/node/453341146 http://www.openstreetmap.org/browse/node/453341218 http://www.openstreetmap.org/browse/node/453341258 http://www.openstreetmap.org/browse/node/612158829 is_inhttp://wiki.openstreetmap.org/wiki/Key:is%20in?uselang=en-US= Serbia name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US = Дечани http://www.openstreetmap.org/browse/node/612169504 is_in:country = Serbia name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US = Манастир Високи Дечани http://www.openstreetmap.org/browse/node/623922742 is_in:country = Serbia name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US = Драгаш http://www.openstreetmap.org/browse/node/675614961 is_in:country = Serbia name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US = општина http://www.openstreetmap.org/browse/node/1245049126 namehttp://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US= Обилић http://www.openstreetmap.org/browse/node/1613271652 namehttp://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US= Железничка станица Приштина http://www.openstreetmap.org/browse/node/1640485042 is_inhttp://wiki.openstreetmap.org/wiki/Key:is%20in?uselang=en-US= Serbia name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US = КОСОВСКА МИТРОВИЦА -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ Talk-kosovo mailing list Talk-kosovo@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-kosovo
Re: [talk-ph] Fwd: [OSM-dev] New version of MapOSMatic, a city map rendering service
I finally tried the new mapsomatic and its great! Printing the whole Marikina in A0 made me very happy seeing my contributions. :) Quezon City printed in A4 multi-page format is 154 pages! On Wed, Apr 18, 2012 at 6:49 PM, Eugene Alvin Villar sea...@gmail.com wrote: A better MapOSMatic has been released! You can use this online service to create poster/paper/book maps of your favorite areas. :-) -- Forwarded message -- From: Thomas Petazzoni thomas.petazz...@enix.org Date: Wed, Apr 18, 2012 at 3:58 PM Subject: [OSM-dev] New version of MapOSMatic, a city map rendering service To: d...@openstreetmap.org Cc: cont...@maposmatic.org Hello, In September 2009, we launched MapOSMatic (http://www.maposmatic.org), a free web service that allows to render city maps on-demand based on OpenStreetMap data. Those city maps, divided into squares, are associated with a street index, making the process of locating a street on the map easier. We are proud to announce today the launch of a new version of MapOSMatic, which is the result of significant development efforts. Amongst the new features: * The rendering of poster maps is now done on large standard paper formats (A3, A2, A1, etc.), automatically chosen depending on the geographical size of the city, instead of arbitrarily-sized papers that were hard to print. The end result is close to commercial folded maps; * The ability to render multi-page maps, where the map and street index are split into several pages, for easier printing on regular paper formats (A5, A4, US Letter). Those multi-page maps are similar to commercial city booklets; * The availability of several rendering styles. For now, we provide the standard OpenStreetMap.org style, several styles provided by MapQuest, and a custom style more suitable for printing. In the future, we expect to extend those styles, or even to let users provide their own styles. Do not hesitate to contact us about custom styles; * Improvements in the selection of cities: in the previous versions, we were limited to OpenStreetMap areas of a certain administrative level; * And many, many other smaller features and improvements: quality of the renderings, better user interface to render maps, last OSM database update date printed on the map, etc. MapOSMatic is completely free software, distributed under the terms of the Affero General Public License v3. The project is available through Git repositories, has a mailing-list and an IRC channel. For details, see our About page (http://www.maposmatic.org/about), our wiki (http://wiki.maposmatic.org) and the Savannah project page (http://savannah.nongnu.org/projects/maposmatic/). In addition to the launch of this new version, we are also starting a donation campaign. The project is completely developed and maintained by volunteers, but we need funding to cover hardware costs and transportations costs to organize the developer meetings during which MapOSMatic improvements are implemented (see our blog at http://news.maposmatic.org). If you appreciate MapOSMatic, do not hesitate to help us by donating with PayPal on http://www.maposmatic.org/donate. Best regards, Thomas Petazzoni -- Thomas Petazzoni http://thomas.enix.org MapOSMatic http://www.maposmatic.org Logiciels Libres à Toulouse http://www.toulibre.org Embedded Linux http://www.free-electrons.com ___ dev mailing list d...@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Non- Motorized Transport Forum and Mapping Workshop - 21st of April, 2012
Anybody, apart from Rally. Maning and Eugene joining this event? On Tue, Apr 17, 2012 at 4:59 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi guys, I'll just give a short background regarding this event. Early this year, OSMPH was invited to help out with the crowd-sourced mapping aspects of the New Mobility Project (“Catalyzing New Mobility in Cities: The Case of Metro Manila”), which is spearheaded by the Ateneo School of Government through their Innovations at the Base of the Pyramid in Southeast Asia (iBoP Asia) initiative. They had a project launch last January 31 and February 1 where the target area to be used as an example was North Triangle in Quezon City. Rally attended that event and we were all pleasantly surprised to see OSM used as the map. You can check the write-up of that event from Smart here: http://www.um-smart.org/blog/2012/02/08/smart-e-news-february-2012/ Some photos from that event showing OSM maps are the following: http://www.um-smart.org/blog/wp-content/uploads/2012/02/12-2-7_Manila-Mapping6.jpg http://www.um-smart.org/blog/wp-content/uploads/2012/02/12-2-7_Manila-Mapping5.jpg http://www.um-smart.org/blog/wp-content/uploads/2012/02/12-2-7_Manila-Mapping.jpg The project had another event on March 13 and the target area was the Ortigas CBD. So this April 21 event is just another one in a series of events for the New Mobility Project (NeMo). This time the target is non-motorized transport (i.e., cycling) and the groups invited are cycling advocates like the Firefly Brigade. I hope many of you can come. :) Eugene On Mon, Apr 16, 2012 at 6:31 PM, maning sambale emmanuel.samb...@gmail.com wrote: Corrected link to invitation: https://docs.google.com/open?id=0B-2WZQ1DwK_xdnhYQTljWVJfLTQ On Mon, Apr 16, 2012 at 6:24 PM, maning sambale emmanuel.samb...@gmail.com wrote: Dear everyone, We are invited to facilitate a mapping workshop for non-motorized transport. The goal of this workshop is to help various organization get started with OSM in mappping non-motorized transport facilities in Metro Manila such as: - Cycling lanes, routes, parking, and related facilities - Bike shops and service centers - Points where cyclists gather on weekends 10 slots are reserved for any OSMer who can assist the group. Invitation letter and other details here: https://docs.google.com/open?id=16Rf4JkTxB1eETc0kfurlG0W6y66f4XD2o21mpOvOMxEbNtS1NGFUq_Y2DCwS Maning, Rally and Eugene will lead the workshop but any extra hands is most welcome. If you are interested, please inform us. We may need to meet in the morning to discuss distribution of tasks. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- cheers, maning -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Non- Motorized Transport Forum and Mapping Workshop - 21st of April, 2012
Guys, I can join. Is it too late to confirm? Wayne Manuel On Fri, Apr 20, 2012 at 7:36 PM, maning sambale emmanuel.samb...@gmail.comwrote: Anybody, apart from Rally. Maning and Eugene joining this event? On Tue, Apr 17, 2012 at 4:59 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi guys, I'll just give a short background regarding this event. Early this year, OSMPH was invited to help out with the crowd-sourced mapping aspects of the New Mobility Project (“Catalyzing New Mobility in Cities: The Case of Metro Manila”), which is spearheaded by the Ateneo School of Government through their Innovations at the Base of the Pyramid in Southeast Asia (iBoP Asia) initiative. They had a project launch last January 31 and February 1 where the target area to be used as an example was North Triangle in Quezon City. Rally attended that event and we were all pleasantly surprised to see OSM used as the map. You can check the write-up of that event from Smart here: http://www.um-smart.org/blog/2012/02/08/smart-e-news-february-2012/ Some photos from that event showing OSM maps are the following: http://www.um-smart.org/blog/wp-content/uploads/2012/02/12-2-7_Manila-Mapping6.jpg http://www.um-smart.org/blog/wp-content/uploads/2012/02/12-2-7_Manila-Mapping5.jpg http://www.um-smart.org/blog/wp-content/uploads/2012/02/12-2-7_Manila-Mapping.jpg The project had another event on March 13 and the target area was the Ortigas CBD. So this April 21 event is just another one in a series of events for the New Mobility Project (NeMo). This time the target is non-motorized transport (i.e., cycling) and the groups invited are cycling advocates like the Firefly Brigade. I hope many of you can come. :) Eugene On Mon, Apr 16, 2012 at 6:31 PM, maning sambale emmanuel.samb...@gmail.com wrote: Corrected link to invitation: https://docs.google.com/open?id=0B-2WZQ1DwK_xdnhYQTljWVJfLTQ On Mon, Apr 16, 2012 at 6:24 PM, maning sambale emmanuel.samb...@gmail.com wrote: Dear everyone, We are invited to facilitate a mapping workshop for non-motorized transport. The goal of this workshop is to help various organization get started with OSM in mappping non-motorized transport facilities in Metro Manila such as: - Cycling lanes, routes, parking, and related facilities - Bike shops and service centers - Points where cyclists gather on weekends 10 slots are reserved for any OSMer who can assist the group. Invitation letter and other details here: https://docs.google.com/open?id=16Rf4JkTxB1eETc0kfurlG0W6y66f4XD2o21mpOvOMxEbNtS1NGFUq_Y2DCwS Maning, Rally and Eugene will lead the workshop but any extra hands is most welcome. If you are interested, please inform us. We may need to meet in the morning to discuss distribution of tasks. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- cheers, maning -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-legal-talk] [Talk-dk] åben offentlig licens og OSM, part 2
On 15-08-2011 16:47, Michael Collinson wrote: Hi Emil, Is this an example of it?: http://www.kk.dk/Borger/ByOgTrafik/CyklernesBy/~/media/687F3451AA5A49E38361F81E7E58C3FA.ashx Yes, this is the same license, thanks for looking at it! It appears to be clearly compatible with the OSM project, whether our data is released under CC-BY-SA or under the new ODbL license. Clause 4 of our new contributor terms allows you to obey this section: Det er et krav, at licenstager - angiver kilden til materialet, og – hvor det er muligt – linker til denne licens. Hvis licensgiver har specificeret en kildeangivelse, skal licenstager anvende denne specificerede kildeangivelse. Hvis det ikke er praktisk muligt at angive kilden til materialet, skal licenstager oplyse følgende: ”Indeholder materiale, som er licenseret under den åbne offentlige licens” If you want to import any data released under this license, please make sure that you add an entry to http://wiki.openstreetmap.org/wiki/Attribution. in Danish or English, or both. Please note 1) I am not a lawyer, and 2) I ran it through Google translate which is usually very good with official documents but may have not given me the precise meaning. Hi, I wonder about these two requirements in the license[1], and whether or not they could present a problem: - - sikrer, at udnyttelsen af materialet sker på en måde, som ikke kan give indtryk af at have officiel status eller at være støttet eller godkendt af licensgiver. - sikrer, at udnyttelsen af materialet ikke vildleder eller giver et misvisende billede af materialet eller materialets kilde. - Translation (by Google, very slightly tweaked by me): - - Ensure that the utilization of the material occurs in a manner that does not give the impression of having official status or to be endorsed or approved by the licensor. - Ensure that the utilization of the material does not mislead or give a misleading picture of the material or material source. - [1] http://digitaliser.dk/resource/600558/artefact/Den+%c3%a5bne+offentlige+licens.pdf -- Jonas Häggqvist rasher(at)rasher(dot)dk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-dk] åben offentlig licens og OSM, part 2
On 20/04/2012 13:23, Jonas Häggqvist wrote: [preamble cut] Hi, I wonder about these two requirements in the license[1], and whether or not they could present a problem: - - sikrer, at udnyttelsen af materialet sker på en måde, som ikke kan give indtryk af at have officiel status eller at være støttet eller godkendt af licensgiver. - sikrer, at udnyttelsen af materialet ikke vildleder eller giver et misvisende billede af materialet eller materialets kilde. - Translation (by Google, very slightly tweaked by me): - - Ensure that the utilization of the material occurs in a manner that does not give the impression of having official status or to be endorsed or approved by the licensor. - Ensure that the utilization of the material does not mislead or give a misleading picture of the material or material source. - [1] http://digitaliser.dk/resource/600558/artefact/Den+%c3%a5bne+offentlige+licens.pdf I believe that both can be can be met in our attribution of the licensor on http://wiki.openstreetmap.org/wiki/Attribution OpenStreetMap's utilization of this material does not imply any official status nor endorsement or approval by . You can find out more about and this material at http:\\xsite.dk A short description may also help as would be a link to a wiki project page describing the data and how we are using it. I think the current attribution we give the UK Ordnance Survey would satisfy both requirements: http://wiki.openstreetmap.org/wiki/Attribution#UK:_Ordnance_Survey_.28OpenData.E2.84.A2.29 I think this is a really nice license and hope it is more widely adopted by governmental agencies. Mike ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] handheld gps unit
What do you want to use it for? What's your budget? What features do you need? Any special requirements? etc Steve On Thu, Apr 19, 2012 at 10:20 PM, kenneth gonsalves law...@thenilgiris.com wrote: hi, what are recommendations for a handheld reasonably priced gps unit? -- regards Kenneth Gonsalves ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Open Knowledge Festival and Open Geodata stream
Hi Folks, I posted earlier about Open Knowledge Festival in Helsinki in September 2012. First some background information: We are delighted to announce that this years http://okfestival.org/open-government-data-camp/ Open Government Data Camp and http://okfestival.org/open-knowledge-conference Open Knowledge Conference are joining to form a week-long celebration: the Open Knowledge Festival!¨ The 2012 theme of OKFestival is Open Knowledge in Action, looking at the value that can be generated by opening up knowledge, the ecosystems of organisations that can benefit from such sharing, and the impacts that transparency can have in our societies. What kinds of new professions, ideas and community initiatives can emerge within our governments, markets, networks and neighbourhoods as a result of these engagements? More information: http://okfestival.org/ I just posted proposal for Open Geodata Stream: Open Geodata stream will coverage two area: open geodata sources and tools to store, manipulate, visualize and sharing geographic information. Both areas will include topics for newbies and also GIS professionals. Open geodata sources will cover opening geodata and crowdsourced geodata. National Land Survey of Finland will told experiences about their topographic information data opening. We will invite also other European mapping agencies to participate and present to this event. OpenStreetMap is biggest crowdsources geodata source. Stream will include lectures and panel discussions, but also field exercise how to collect OpenStreetMap with GPS devices. Open Geodata needs also tools (ie computer software) to store, manipulate, visualize and share geographic information and maps. This part of the stream will include hands-on-exercises with commercial and open source software tools to work with open geodata. If you like to join organization team of Open Geodata Steam, please send email to me. If you like to present, you can send your proposal to http://okfestival.org/call-for-proposals/. Deadline for presentation is 1st of June, 2012. And if anybody from the Board of OSM Foundation is interested to participate, Finnish OSM and Open data activists will appreciate deeply. Regards, Pekka -- Pekka Sarkola Gispo Oy mailto:pekka.sark...@gispo.fi pekka.sark...@gispo.fi - GSM +358 40 725 2042 http://www.gispo.fi www.gispo.fi http://www.paikkatieto.com www.paikkatieto.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Transcription and 'internationalization' in place names
I picked up a message from another mailing list (http://groups.google.com/group/bikemapde/topics), which maybe someone following this thread can follow up: The site Bikemap.de recently switched to OSM. In their mailing list I picked up this complaint from a user in Taiwan: I am very disappointed with the new maps currently being used by Bikemap. I live in Taiwan and these new maps not only omit important data, such as road names and numbers, but the place names are in the Hanyu Pinyin form of romanization and do not match the common signage used in Taiwan. This adds one extra layer of complexity and difficulty for most users. I hope Bikemaps can consider these problems and revert to using a mapping software that can be more accurate and reflect the local names as they are actually spelled. Volker -- Volker SCHMIDT 35127 Padova Italy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Transcription and internationalization in place names
Am 16.04.2012 22:17, Miloš Komarčević: Hi all, On Mon, Apr 16, 2012 at 11:01 AM, Daniel Kastldan...@georepublic.de wrote: name:ja_rm is probably what will not be rendered usually, but this would be the name written for example on street signs as name in latin characters. name:ja_kana is what was mentioned in a previous email, because it helps Japanese people to know the reading of a name. It's also useful for geocoding. I would also like to take this opportunity to draw your attention to the lack of unification on how 'romanized' language tags are used and constructed for languages not usually written in Latin script. 'ja_rm' and 'zh_pinyin' are some examples We strongly believe OSM should get behind and use BCP 47 as recommended by W3C, Unicode, ECMA, etc.: http://en.wikipedia.org/wiki/IETF_language_tag and are already committed to retagging all our data in Serbia to 'sr' and 'sr-Latn'. +1 Would be great to get the tagging guidelines accordingly. Claudius ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] handheld gps unit
Do you know how this compares to the newer touch screen Garmin devices
(Dakota, Oregan, Montana)? I know that upon release the GPS performance
(read Accuracy) of the touch devices was below the Vista HCx.
Wondering if they could fix that via firmware upgrades or even
improvements to the hardware.
I really liked my Vista HCx, because of the very fast time to fix, the
high accuracy and the fact that it actually had a scrollable map
(something the Geko is lacking). But then the usability with that small
joystick was just... bad when using the map.
Claudius
Am 19.04.2012 14:40, Thomas Davie:
I'm very pleased with my Garmin eTrex Vista HCx.
Bob
if (*ra4 != 0xffc78948) { return false; }
On 19 Apr 2012, at 13:20, kenneth gonsalves wrote:
hi,
what are recommendations for a handheld reasonably priced gps unit?
--
regards
Kenneth Gonsalves
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[Talk-br] remapping brasilia
Ola pessoal, We've noticed that several labels and many streets look like they may be lost to the license change: http://cleanmap.poole.ch/?zoom=12lat=-15.82927lon=-47.90864layers=00B We have some local knowledge and will be able to name places like and trace roads from Bing - cruzeiro velho - cruzeiro novo - asa sul - eixo rodovíario sul - ceilandia Does anyone know if there are any remapping efforts already underway here? Who should we talk to about this? Ian Villeda vill...@mapbox.com https://twitter.com/#!/ian_villeda___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] remapping brasilia
Olá pessoal! Em tradução livre do texto Ian: Devido a mudança da licença, alguns lugares de Brasília ficarão sem ruas / sem nomenclatura. Existe algum esforço de remapeamento destas áreas? Existe alguém coordenando o trabalho? Abraços On Fri, Apr 20, 2012 at 12:18 PM, Ian Villeda vill...@mapbox.com wrote: Ola pessoal, We've noticed that several labels and many streets look like they may be lost to the license change: http://cleanmap.poole.ch/?zoom=12lat=-15.82927lon=-47.90864layers=00B We have some local knowledge and will be able to name places like and trace roads from Bing - cruzeiro velho - cruzeiro novo - asa sul - eixo rodovíario sul - ceilandia Does anyone know if there are any remapping efforts already underway here? Who should we talk to about this? Ian Villeda vill...@mapbox.com https://twitter.com/#!/ian_villeda ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- George R. C. Silva Desenvolvimento em GIS http://geoprocessamento.net http://blog.geoprocessamento.net ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] remapping brasilia
I don't know if there is someone remapping but if I can be of any assistance, let me know. How can this remapping be done? I mean, corrections can be made in the map or a new work in the field are required? Em 20 de abril de 2012 12:18, Ian Villeda vill...@mapbox.com escreveu: Ola pessoal, We've noticed that several labels and many streets look like they may be lost to the license change: http://cleanmap.poole.ch/?zoom=12lat=-15.82927lon=-47.90864layers=00B We have some local knowledge and will be able to name places like and trace roads from Bing - cruzeiro velho - cruzeiro novo - asa sul - eixo rodovíario sul - ceilandia Does anyone know if there are any remapping efforts already underway here? Who should we talk to about this? Ian Villeda vill...@mapbox.com https://twitter.com/#!/ian_villeda ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] remapping brasilia
Hello Tulio, These corrections, AFAIK, can be done directly in the map (using bing maps overlay aerials). Olá Túlio, Pelo que sei, estas correções podem ser feitas diretamente sobre o mapa (utilizando as imagens do bing). On Fri, Apr 20, 2012 at 1:43 PM, Tulio Macedo tulio...@gmail.com wrote: I don't know if there is someone remapping but if I can be of any assistance, let me know. How can this remapping be done? I mean, corrections can be made in the map or a new work in the field are required? Em 20 de abril de 2012 12:18, Ian Villeda vill...@mapbox.com escreveu: Ola pessoal, We've noticed that several labels and many streets look like they may be lost to the license change: http://cleanmap.poole.ch/?zoom=12lat=-15.82927lon=-47.90864layers=00B We have some local knowledge and will be able to name places like and trace roads from Bing - cruzeiro velho - cruzeiro novo - asa sul - eixo rodovíario sul - ceilandia Does anyone know if there are any remapping efforts already underway here? Who should we talk to about this? Ian Villeda vill...@mapbox.com https://twitter.com/#!/ian_villeda ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- George R. C. Silva Desenvolvimento em GIS http://geoprocessamento.net http://blog.geoprocessamento.net ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] remapping brasilia
Thanks, I sign in the service and I already labeled some places and streets. Em 20 de abril de 2012 13:48, George Silva georger.si...@gmail.comescreveu: Hello Tulio, These corrections, AFAIK, can be done directly in the map (using bing maps overlay aerials). Olá Túlio, Pelo que sei, estas correções podem ser feitas diretamente sobre o mapa (utilizando as imagens do bing). On Fri, Apr 20, 2012 at 1:43 PM, Tulio Macedo tulio...@gmail.com wrote: I don't know if there is someone remapping but if I can be of any assistance, let me know. How can this remapping be done? I mean, corrections can be made in the map or a new work in the field are required? Em 20 de abril de 2012 12:18, Ian Villeda vill...@mapbox.com escreveu: Ola pessoal, We've noticed that several labels and many streets look like they may be lost to the license change: http://cleanmap.poole.ch/?zoom=12lat=-15.82927lon=-47.90864layers=00B We have some local knowledge and will be able to name places like and trace roads from Bing - cruzeiro velho - cruzeiro novo - asa sul - eixo rodovíario sul - ceilandia Does anyone know if there are any remapping efforts already underway here? Who should we talk to about this? Ian Villeda vill...@mapbox.com https://twitter.com/#!/ian_villeda ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- George R. C. Silva Desenvolvimento em GIS http://geoprocessamento.net http://blog.geoprocessamento.net ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Straßenbegleitende Radwege
Bernhard Weiskopf bweisk...@gmx.de writes: Für mich klingt die Beschreibung, z. B. zum Zeichen 237 (Radweg), eindeutig: Radfahrer dürfen nicht die Fahrbahn, sondern müssen den Radweg benutzen (Radwegbenutzungspflicht). (Quelle: StVO 2010-12-01) In http://www.bmvbs.de/cae/servlet/contentblob/33640/publicationFile/31567/strassenverkehrs-ordnung-stand-Dezember-2010.pdf kann ich den Text so nicht finden. Ich lese dort: 5. Sonderwege Zeichen 237 ... Die Zeichen bedeuten: a) Radfahrer, Reiter und Fußgänger müssen die für sie bestimmten Sonderwe- ge benutzen. Andere Verkehrsteilnehmer dürfen sie nicht benutzen; ... Wo hast du deine Variante her? -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Hi, On Fri, Apr 20, 2012 at 07:47:02AM +0200, Ronnie Soak wrote: Oehm, wenn ich noch mal nachhaken duerfte: Im obigen Beispiel mit Fischmarkt, Erfurt war es osm.org, das mit Coburg einige hundert km daneben lag und osm.de, der sich nur im Nachbarkreis vertan hat. Die Daten vorher waren von Dezember. Damals gab es auch den Ilm-Kreis noch als place=region: http://www.openstreetmap.org/browse/node/240085076/history Da er inzwischen von BBO gelöscht wurde, ist jetzt eben Coburg der nächste. Um soetwas zu 'debuggen' ist übrigens die Nominatim-Seite selber recht nützlich: http://nominatim.openstreetmap.org/ Wenn du dort nach 'Fischmarkt, Erfurt' suchst, erhältst du bei den Suchresultaten jeweils einen Link zu den Details. Für den Fischmarkt zum Beispiel: http://nominatim.openstreetmap.org/details.php?place_id=116887509 Unter 'Address' kannst du sehen, welche OSM-Objekte Nominatim berücksichtigt hat, um die Adresse zu erstellen. Die ausgegrauten sind Kandidaten, die er gefunden, aber verworfen hat und die schwarzen diejenigen, die tatsächlich in der Adresse angezeigt werden. Und dort findest du bei Coborg einen Link zu dem schuldigen Place-Node. Das ist mit einem aktuellen Test uebrigens noch genauso (aber das kann auch an irgend welchem Caching liegen). Einfach mal die Seite neu laden (Ctrl+R), dann sollte es gehen. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Hallo, sollte Nominatim nicht erkennen: Erfurt ist admin_level=6, also kreisfrei? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 20. April 2012 08:46 schrieb Karl Eichwalder k...@gnu.franken.de: Bernhard Weiskopf bweisk...@gmx.de writes: Für mich klingt die Beschreibung, z. B. zum Zeichen 237 (Radweg), eindeutig: Radfahrer dürfen nicht die Fahrbahn, sondern müssen den Radweg benutzen (Radwegbenutzungspflicht). (Quelle: StVO 2010-12-01) In http://www.bmvbs.de/cae/servlet/contentblob/33640/publicationFile/31567/strassenverkehrs-ordnung-stand-Dezember-2010.pdf kann ich den Text so nicht finden. Ich lese dort: 5. Sonderwege Zeichen 237 ... Die Zeichen bedeuten: a) Radfahrer, Reiter und Fußgänger müssen die für sie bestimmten Sonderwe- ge benutzen. Andere Verkehrsteilnehmer dürfen sie nicht benutzen; ... Wo hast du deine Variante her? Das steht so in der Anlage 2 zur StVO Lfd. Nr. 16, Abschnitt 5. Sonderwege, Zeichen 237 (Stand 1.9.2009), zuletzt geändert durch Art. 1 VO v. 5.8.2009 (BGBl. I S. 2631) Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On Fri, Apr 20, 2012 at 09:03:52AM +0200, aighes wrote: Hallo, sollte Nominatim nicht erkennen: Erfurt ist admin_level=6, also kreisfrei? Wie gesagt, normalerweise nimmt Nominatim an, dass zu admin_level=6 ein place=county gehört. place=region wird eine Stufe höher angesiedelt, admin_level=5. Deshalb kommt beides in die Adresse: Erfurt als Kreis und Coburg quasi als Regierungsbezirk (nicht, dass wir sowas in Thüringen hätten, aber das weiss Nominatim nun mal nicht). Man könnte natürlich für Deutschland eine Ausnahme einbauen, aber erstens sind place=region als Kreis eher am Aussterben und zweitens relativ inkonsitent verwendet. Es gibt Kreise mit place=county in der DB: http://www.openstreetmap.org/browse/node/240033539 und place=region-Nodes, die keine Kreise sind: http://www.openstreetmap.org/browse/node/310541181 http://www.openstreetmap.org/browse/node/240092615 http://www.openstreetmap.org/browse/node/161555825 http://www.openstreetmap.org/browse/node/428230346 Ausnahmen würden also nur zu anderen Fehlern führen. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 19.04.2012 17:59, schrieb Sven Geggus: Jimmy_K jimm...@gmx.at wrote: Meine Suche stammt von openstreetmap.org, aber auch openstreetmap.de liefert bei mir keinen Aldi. Ich habe gerade nochmals nachgetestet. Bei der Suche über openstreetmap.de erhalte ich bei dem Suchmuster elbufer, bad schandau: Ergebnis der Adresssuche: 1. Am Elbufer, ALDI Markt, Ostrau, Bad Schandau, Sächsische Schweiz-Osterzgebirge, Direktionsbezirk Dresden, Sachsen, 01814, Bundesrepublik Deutschland (Landmasse) 2. Am Elbufer, ALDI Markt, Postelwitz, Bad Schandau, Sächsische Schweiz-Osterzgebirge, Direktionsbezirk Dresden, Sachsen, 01814, Bundesrepublik Deutschland (Landmasse) bei nominatim.openstreetmap.org: Am Elbufer, Ostrau, Bad Schandau, Sächsische Schweiz-Osterzgebirge, Direktionsbezirk Dresden, Sachsen, 01814, Bundesrepublik Deutschland (Landmasse) Am Elbufer, Postelwitz, Bad Schandau, Sächsische Schweiz-Osterzgebirge, Direktionsbezirk Dresden, Sachsen, 01814, Bundesrepublik Deutschland (Landmasse) Elbufer 97, 97, Kirschleite, Ostrau, Bad Schandau, Sächsische Schweiz-Osterzgebirge, Direktionsbezirk Dresden, Sachsen, 01814, Bundesrepublik Deutschland (Landmasse) (Chalet) 97, Am Elbufer, Ostrau, Bad Schandau, Sächsische Schweiz-Osterzgebirge, Direktionsbezirk Dresden, Sachsen, 01814, Bundesrepublik Deutschland (Landmasse) (House) bei www.openstreetmap.org das Ergebnis von nomatim, allerdings wird das Chalet als Almhütte bezeichnet, obwohl es mit tourism=chalet getagt ist. hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] mal wieder eine Tag-Frage
Hi ! bei uns gibt es einen Anbieter von Monteurszimmern im größeren Stil. Wie taggen ?? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On Fri, Apr 20, 2012 at 09:53:58AM +0200, hike39 wrote: Am 19.04.2012 17:59, schrieb Sven Geggus: Jimmy_K jimm...@gmx.at wrote: Meine Suche stammt von openstreetmap.org, aber auch openstreetmap.de liefert bei mir keinen Aldi. Ich habe gerade nochmals nachgetestet. Bei der Suche über openstreetmap.de erhalte ich bei dem Suchmuster elbufer, bad schandau: Mit Ctrl-R (oder Ctrl-F5) ein Neuladen der Seite erzwingen. bei www.openstreetmap.org das Ergebnis von nomatim, allerdings wird das Chalet als Almhütte bezeichnet, obwohl es mit tourism=chalet getagt ist. Das haben die Übersetzer der Hauptseite so eingetragen. Wer die Übersetzungen verbessern will, kann sich im TranslateWiki anmelden und dort beitragen: http://translatewiki.net/wiki/Translating:OpenStreetMap Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS mit *gutem* Empfang? - Mainnav
Hallo Manuel, Ich benutze den wasserdichten Fahrradtacho von Mainnav: http://wiki.openstreetmap.org/wiki/DE:Mainnav Per Bluetooth liefert er RMC, GGA, GSA, GSV :-) Empfang im Wald und zwischen Häusern http://wiki.openstreetmap.org/wiki/de:Genauigkeit_von_GPS-Daten Wichtig wäre mir, dass Bluetooth auch deaktivierbar ist Wird automatisch abgeschaltet. Wenn Du Geräte vergleichen willst: http://wiki.openstreetmap.org/wiki/de:Genauigkeit_von_GPS-Gerät_prüfen Viel Spass! Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 20.04.2012 10:08, schrieb Sarah Hoffmann: Mit Ctrl-R (oder Ctrl-F5) ein Neuladen der Seite erzwingen. Nun bin ich aber verblüfft. Ich habe bei meinen Tests, ich arbeite übrigens mit FF 11.0, mehrfach den Cache gelöscht gehabt. Dennoch kam immer der Eintrag mit ALDI. Nun habe ich den Browser neugestartet und siehe da ALDI ist verschwunden. STAUN! Das haben die Übersetzer der Hauptseite so eingetragen. Wer die Übersetzungen verbessern will, kann sich im TranslateWiki anmelden und dort beitragen: http://translatewiki.net/wiki/Translating:OpenStreetMap Werde mich da einmal einarbeiten. Aber ich habe auch im Wiki bei DE:Howto_Map_A nachgesehen, wie man Ferienwohnungen tagt. Dort ist für die Almhütte tourism=alpine_hut empfohlen. Aber dennoch eine andere Frage: Woher kommt eigentlich im dritten Treffer der Hinweis auf die Kirschleite. Das ist doch nur ein Fußpfad nördlich bzw Wege in der Nähe von bewusstem Objekt. hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Admin-Levels und Place-Nodes (war: Suche nach Elbufer, Bad Schandau)
Hallo Sarah! On 19.04.12 19:44, Sarah Hoffmann wrote: Man ist gerade dabei, dass Nominatim beizubringen. Sper! :)) Es gibt noch ein paar kleinere Bugs zu bereinigen, aber das Ganze wird mit dem Neuimport nach dem Lizenzwechsel live gehen. Dann werden also place-Nodes und boundary-Relationen zusammengefasst und auch admin_center und label-Roles in den Boundary-Relationen berücksichtigt, was hoffentlich einen grossen Teil der Addressfehler beseitigen sollte. Hört sich nach der perfekten Lösung an, vielen Dank! Gibt's diese Tabelle zu admin_level=X gehört place=Y irgendwo im Wiki? Das wäre glaub ich auch hilfreich, wenn alle die gleiche Sprache sprechen. So in etwa: admin_level=1 ... (? place=continent) ? Kontinent admin_level=2 ... place=countryStaat admin_level=4 ... place=state Bundesland admin_level=6 ... place=county DE: Kreis, AT: Pol. Bezirk admin_level=8 ... place=city/town/villageGemeinde*) admin_level=9 ... place=?? Stadtbezirk, Gemeindebezirk admin_level=10 ... place=suburbStadtteil (AT: Katastralgemeinde) darunter place=neighbourhood AT: Grätzel Wo dazwischen ist da place=region angedacht? *) in AT gäb's noch Marktgemeinden, die quasi einen Wichtigkeitsstatus zwischen place=town und place=village hätten. es gibt also drei Möglichkeiten, das zu bereinigen. Ihr könnt die Nodes löschen, in place=county umtaggen oder einfach bis nach dem Lizenzwechsel warten, wo dann die region-Nodes ohnehin ignoriert werden. Es macht wohl Sinn (modulo obigen Überlegungen), county zu nehmen. Ich bin verwirrt, du erwartest, dass gleich getaggte place-Nodes unterschiedlich behandelt werden? s.o., irgendwie fehlt mir ein place=city_district o.ä. für den Stadtbezirk. Oder man nimmt place=suburb als Stadtbezirk und place=quarter als kleinteiligen Stadtteil (AT: Katastralgemeinde), wie Martin K. es denkt/vorschlägt. N.B.: Katastralgemeinde ist keine nur-städtische Ausprägung, jede Gemeinde ATs ist in ein oder mehrere Katastralgemeinden unterteilt. Nur in ländlichen Gegenden sind die Ortschaftsnamen meist die wichtigeren Namen. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On Fri, Apr 20, 2012 at 10:45:35AM +0200, hike39 wrote: Werde mich da einmal einarbeiten. Aber ich habe auch im Wiki bei DE:Howto_Map_A nachgesehen, wie man Ferienwohnungen tagt. Dort ist für die Almhütte tourism=alpine_hut empfohlen. Ja, die übersetzung Almhütte für chalet ist doch sehr irreführend. (Um nicht zu sagen, falsch.) Aber dennoch eine andere Frage: Woher kommt eigentlich im dritten Treffer der Hinweis auf die Kirschleite. Das ist doch nur ein Fußpfad nördlich bzw Wege in der Nähe von bewusstem Objekt. Das war der nächste highway=* zu dem Haus, vermutlich nur mit ein paar Metern unterschied, aber das reicht. Nominatim macht keinen unterschied ob Strasse oder Fusspfad. Wenn du das addr:street in Am Elbufer änderst, sollte er es der richtigen Strasse zuordnen. (Strassenname und addr:street müssen exakt übereinstimmen.) Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On 19.04.12 20:55, Jimmy_K wrote: Irgendwie verwirrt mich der Link gewaltig: admin_level=4: Bundesland http://de.wikipedia.org/wiki/Bundesland_%28%C3%96sterreich%29 NUTS2 was nun NUTS2 oder Bundesland (wäre NUTS3) admin_level=5: Region NUTS3 Regionen sind aber NUTS2 (Ost, Süd, West) oder NUTS4 (in etwa die Viertel NUTS-Levels in sind in AT anders als in DE. /0/ Warum, weiß ich nicht, ist aber auch nicht wirklich wichtig. NUTS1 und NUTS3 sind in AT inhaltsfreie Zusammenfassungen von Dingen. Die admin_levels sind Ernst zu nehmen (und auch ziemlich ähnlich zu DE) und so wie dokumentiert gemappt. /al /0/ http://de.wikipedia.org/wiki/NUTS#.C3.96sterreich ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mal wieder eine Tag-Frage
Sind das nicht einfach normale Pensionen? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mal wieder eine Tag-Frage
Am 20.04.2012 11:33, schrieb aighes: Sind das nicht einfach normale Pensionen? Henning und das ist bei Dir amenity=hotel ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straßenbegleitende Radwege
*Bernhard Weiskopf schrieb* * *Für mich klingt die Beschreibung, z. B. zum Zeichen 237 (Radweg), eindeutig: * *Radfahrer dürfen nicht die Fahrbahn, sondern müssen den Radweg benutzen * *(Radwegbenutzungspflicht). * *Radfahrer dürfen nicht übersetzte ich mit bicycle = no. * *Das muss der Mapper in der Tat dann genau beachten. Ich finde es sogar * *hilfreich, wenn mir der Routenplaner anzeigt, dass ich vom Radweg auf die * *Straße wechseln muss, um z. B. links abbiegen zu können. Wird die Route auf * *der Straße angezeigt und ich fahre ordnungsgemäß auf dem abgesetzten Radweg, * *kann ich nicht abbiegen. Du möchtest dich bitte über den Unterschied zwischen Straße, Fahrbahn und Radweg und die Schnittmengen dieser drei Begriffe informieren. Solange du das alles hier lustig durcheinander haust, fehlt der Diskussion eine wichtige Grundlage. Ludger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 20.04.2012 11:15, schrieb Andreas Labres: On 19.04.12 20:55, Jimmy_K wrote: Irgendwie verwirrt mich der Link gewaltig: admin_level=4: Bundesland http://de.wikipedia.org/wiki/Bundesland_%28%C3%96sterreich%29 NUTS2 was nun NUTS2 oder Bundesland (wäre NUTS3) admin_level=5: Region NUTS3 Regionen sind aber NUTS2 (Ost, Süd, West) oder NUTS4 (in etwa die Viertel NUTS-Levels in sind in AT anders als in DE. /0/ Warum, weiß ich nicht, ist aber auch nicht wirklich wichtig. NUTS1 und NUTS3 sind in AT inhaltsfreie Zusammenfassungen von Dingen. Die admin_levels sind Ernst zu nehmen (und auch ziemlich ähnlich zu DE) und so wie dokumentiert gemappt. /al /0/ http://de.wikipedia.org/wiki/NUTS#.C3.96sterreich ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Da bin ich wohl von einer falschen Quelle ausgegangen, oder habe sich flasch interprätiert. Wenn ich nämlich hier [1] die Liste Downloade kommt: Level...Description 1 ...Österreich 2 ... Ostösterreich 3 ...Burgenland Sollte wohl eher auf [2] schaun, da versteh ichs auch... [1] http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?TargetUrl=LST_NOM_DTLStrNom=NUTS_22StrLanguageCode=ENIntPcKey=28435787StrLayoutCode=HIERARCHIC [2] http://epp.eurostat.ec.europa.eu/cache/ITY_OFFPUB/KS-RA-11-011/EN/KS-RA-11-011-EN.PDF ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, Am Freitag, 20. April 2012 02:20:24 schrieb Christian Müller: Moin, ich mag in diesem Zusammenhang noch einmal kurz auf das Thema Flächennetzwerk zurückzukommen. Have a fun read.. Da hast du dir ja richtig Arbeit gemacht ;-) Am 19.04.2012 13:05, schrieb Wolfgang: -1 Das Multipolygon sollte rein Fläche bleiben, und Fläche sollte nur im Multipolygon erfasst werden. Wer was dazu sammeln will, kann das über eine site verbinden. Wieder das Thema Relationen verbiegen. Damit würdest Du z.B. sämtliche Parks als type=site Relationen erfassen, in denen Du dann die MP der Einzelflächen sammelst. Aber was ist überhaupt eine Einzelfläche? Ich glaube, an dieser Stelle missverstanden zu sein. Solange es nur um zusammengehörige Flächen gleichen Typs geht, reicht das Multipolygon völlig aus. Ich will nicht Multipolygone durch Sites ersetzen, sondern verhindern, dass - das Multipolygon mit Elementen verwässert wird, die mit der Fläche nichts zu tun haben (place etc) und - die Flächenberechnung / Darstellung im Multipolygon konzentrieren (wenn sie komplizierter ist als ein einfacher Umring) Betrachten wir beispielsweise einen Schlosspark bestehend aus mehreren Teichen, Rabatten, Wiesen, etc. die im Park verteilt sind - das Schloss selbst steht auf einem Sockel im Zentrum des Parks. 1. MP - Teiche 2. MP - Rabatten 3. MP - Wiesen 4. MP - Sockel 5. MP - Schloss 6. Schlosspark-Verwaltung Wenn du das Schloss (mit Sockel :-) ) als nicht zum Schlosspark zugehöriig betrachtest, brauchst du in der Tat ein Multipolygon für den Park mit inner = Schlosssockel. Die Seen, Wiesen etc würde ich als zum Schlosspark zugehörig ansehen und nicht aus der Parkfläche ausschließen wollen. Die Seen werden natürlich extra gemappt und erhalten wegen der Inseln ein Multipolygon, wobei ein Multipolygon für alle Seen reicht. Da die ganze Fläche außer dem Schloss zum Schlosspark gehört, ist für den Renderer auch klar, dass die Inseln ebenfalls leisure=park zu rendern sind. Verwaltungsmäßig gehören sie sowieso zum Schlosspark. Die Seefläche wird nicht als Loch im Park definiert, weil sie 1. zum Park gehört und 2. üblicherweise der Renderer damit klar kommt, die Wasserfläche hat insofern Vorrang. Für das Schloss würde mir eine einfaches Polygon mit building=castle/yes reichen. Beim Sockel kommt es drauf an, wie der aussieht. Das könnte ein building=sockel (?) sein. In dem Falle bekäme das Schloss dann den layer=1, denn es liegt ja tatsächlich auf dem Sockel. Jetzt haben wir ein Multipolygon für den Schlosspark, eins für die Seen, jeweils ein Polygon für den Sockel und das Schloss. Einzelheiten des Parks wie Rabatte etc erhalten einfache Polygone. Es ist eine reine Frage der Logig, dass sie, wenn gewünscht, über dem Park gerendert werden. Dass sie zum Park gehören, muss ggf. aus der Lage ermittelt werden. Wenn jemand eine Statistik aller Rosenbeete in den Schlossparks des Landes erstellen will, dann muss er eben abfragen, welche Beete sich räumlich in einem solchen Park befinden. Für die Verwaltung kommt eine Site hinzu, name = Staatliche Verwaltung der Beispielhaften Gärten, Schlösser und Seen, Members sind der Schlosspark, das Schloss und weitere Anlagen, die zu der Verwaltung gehören, sowie ggf. das Verwaltungsgebäude, das vermutlich in der Landeshauptstadt des Beispielhaften Freistaates steht. :-) [...] Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel, wenn es um die Berechnung der Fläche geht, die sich aus den Einzelflächen der Kinder und Kindeskinder (..) ergibt. Schließlich sind nur die outer/inner Mitglieder der Kinder und Kindeskinder (..) interessant, die tatsächlich einen Beitrag zu Außen- oder Innenringen des nestedMP liefern. Ab einer bestimmten Schachtelungstiefe wird die Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht werden, also alle Relationen, die dann tatsächlich way-members als Mitglieder haben und nicht selbst ein nestedMP sind. Je tiefer dieser Baum, desto höher die Wahrscheinlichkeit, dass es mehr irrelevante members als relevante gibt. So ganz kann ich deinen Ausführungen nicht folgen. Im Prinzip ist das Multipolygon überraschend einfach zu berechnen und gleichzeitig geschickt aufgebaut. Regel 1: Jeder Umring kann aus einer beliebigen Anzahl von Polygonen bestehen, dabei müssen Anfangs- und Endpunkte auf einander folgender Polygone identisch sein und der Umring als Ganzes ein geschlossenes Polygon ergeben Regel 2: Alle geschlossenen Polygone (Umringe), die innnerhalb eines geschlossenen Polygons liegen, bilden ein Loch in diesem, sie dürfen das äußere Polygon nicht berühren. Regel 3: Die Umringe werden geschachtelt und liegen in beliebiger Tiefe ineinander. Inner und Outer können, müssen aber nicht angegeben werden. Sie dienen der Übersicht des Mappers und können zur Fehlerkontrolle benutzt werden. Regel 4: Die
Re: [Talk-de] mal wieder eine Tag-Frage
http://wiki.openstreetmap.org/wiki/DE:Tag:tourism%3Dguest_house Spuckt das Wiki zu Pensionen aus ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Bernhard Weiskopf wrote: Ich wünsche mir Router, die die unterschiedlichen Wünsche der Radfahrer und Fußgänger berücksichtigen können, z. B. Gefährlichkeit, Oberflächenbeschaffenheit, Ampelfreiheit, Steigungen und vieles mehr. Bei Exakt. Und deshalb gehören die o.g. Fakten an den Weg. Daraus kann der Router dann entscheiden über welche Strecke er routet. Gefährlichkeit würde ich weglassen, weil die aus anderen Faktoren (Priorität der Straße, maxspeed, maxweight, width...) durch den Router zu berechnen ist. http://www.openrouteservice.org/ kann man immerhin aus fünf Vorgaben auswählen, wobei die Algorithmen zum Routen sehr komplex werden können und immer noch nicht die optimale Route auswählen. Ja, logisch, weil der Router nicht raten kann was für Dich optimal ist. :-) Ich denke man kann sowieso nicht erwarten dass ein Router die Detailkenntnisse eines Ortskundigen umsetzt. Hauptsache man kommt ohne größere Umwege und auf den persönlich favorisierten Straßentypen zum Ziel. Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 20.04.2012 11:10, schrieb Sarah Hoffmann: Ja, die übersetzung Almhütte für chalet ist doch sehr irreführend. (Um nicht zu sagen, falsch.) Da stimme ich Dir zu. Mal sehen, ob man dies noch ändern kann. Das war der nächste highway=* zu dem Haus, vermutlich nur mit ein paar Metern unterschied, aber das reicht. Nominatim macht keinen unterschied ob Strasse oder Fusspfad. Wenn du das addr:street in Am Elbufer änderst, sollte er es der richtigen Strasse zuordnen. (Strassenname und addr:street müssen exakt übereinstimmen.) Ich habe auch schon festgestellt, dass bei der Adresse das Am gefehlt hat. Habe es auch schon korrigiert. Müßte also demnächst auch richtig dargestellt werden. Vielen Dank schon 'mal für Deine Hilfe. Meine Bekannte wird erfreut sein, wenn sie ihr Haus und Ferienwohnung korrekt sieht. Dann haben wir schon wieder einen zufriedenen Anwender mehr. hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 12:04 schrieb Wolfgang wolfg...@ivkasogis.de: Park mit inner = Schlosssockel. Die Seen, Wiesen etc würde ich als zum Schlosspark zugehörig ansehen und nicht aus der Parkfläche ausschließen wollen. +1 Beim Sockel kommt es drauf an, wie der aussieht. +1. Wenn es sich dabei eher um eine Terrasse handelt (d.h. massiv und unten nicht begehbar), dann würde ich die Stützmauern (ggf., also den Umriss des Sockels) als barrier=retaining_wall mappen, und für die Fläche oben ein Multipolygon mit highway=pedestrian, area=yes Wenn es dagegen ein begehbarer Sockel ist (also z.B. der Schlosskeller da drin ist), dann würde ich es als Teil des Schloss-buildings sehen, und evtl. als getrennntes building erfassen (wegen unterschiedlicher Stockwerksanzahl). Oder building part. Für die Verwaltung kommt eine Site hinzu, name = Staatliche Verwaltung der Beispielhaften Gärten, Schlösser und Seen, würde ich eher in operator als in name taggen. Eine Verwaltung ist keine site m.E. Solange das nur ein ganz einfaches geschlossenes Polygon ist, würde ich immer das benutzen. Sobald aber kompliziertere Gebilde auftreten, die entweder Löcher haben oder/und durch mehrere zusammenhängende Abschnitte sinnvollerweise definiert sind, sollte nur das Multipolygon für die Fläche genutzt werden. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20.04.2012 03:14, schrieb Martin Koppenhoefer: Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als auch für die zukünftige Pflege bei Daten im Vergleich zu einer site-relation als bunte Mischung aller möglichen Elemente und Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche beschreibt. Bei umfriedeten Grundstücken kann man z.B. einen (im einfachsten Fall) way für Zaun/Mauer haben, der dann als outer einer Multipolygon-relation dient, die das Gesamtareal beschreibt. Alles Darinliegende (Schloßteich, Blumenrabatte, Mülltonnen und Hundekottütensp...) ist dann automatisch erstmal Bestandteil, sofern man es nicht explizit als inner way wieder ausschließt, eine Site braucht man dazu nicht. Ich würde in die site (falls man sie überhaupt benötigt für das, was man abbilden will) dann auch nicht unbedingt alle Einzelteile reintun, sondern dieses Gesamtobjekt. Für so was wie die Teiche in einem Schloßpark würde ich keine eigene site-Relation anlegen. Die von Dir beobachtete Verschachtelung, die Du gerne mit Relationen abbilden willst, ergibt sich bereits geometrisch aus den Daten, auch ohne jegliche Relation. Das sie implizit durch mehrfach als Ringelemente verwendete ways vorhanden ist, war mir klar - das ist aber dennoch nicht das gleiche. Ich habe das Beispiel mit den Kreisgrenzen gebracht - für eine komplett innenliegende Kreisgrenze innerhalb eines Landes ist der Flächenbezug zwar herstellbar, aber ohne explizite Sammelrelation nur mit rechnerischem Aufwand. Der Unterschied nochmal dargestellt anhand des Schlossparks: Sammelvariante: Eine Anfrage nach den Teichgeometrien innerhalb des Schlossparks ist durch lookup in die Relation zu lösen. Boundary-Only-Variante: (also nur die outers des Schlossparks) Man benutzt die Grenze des Schlossparks zum Verschneiden und sucht sich in den verbleibenden Daten die Teiche raus. Bezogen auf einen kleineren Park ist der Aufwand für beide Varianten sicher vernachlässigbar. Für ein größeres Gebiet ergeben sich mit der Sammelvariante aber Vorteile - da man nicht verschneiden muss. Einen gedachten expliziten MP-Baum zu crawlen und alle Teilflächen ohne geometrische Berechnung zu ermitteln, dürfte abhängig vom Anwendungsfall die bessere Variante sein - manche Anwendungsfälle werden durch ein solches Netzwerk evtl. praktisch erst möglich. Es gibt natürlich auch Probleme: z.B. könnten die Relationen schlecht gepflegt sein und man erwischt nicht alle Ergebnisse, die man mit einem Verschnitt erhalten hätte. Andererseits könnte ein Verschnitt sehr komplex werden - wenn das MP aus mehreren Einzelflächen besteht, also mehrere Verschnitte berücksichtigt werden müssen. Mir ging es darum, aufzuzeigen, dass egal wie man das Kind nennt - type=collection, type=site, type=multipolygon - im Endeffekt über den Flächenbezug gesprochen wird. Ich habe jetzt nicht nachgeschaut, aber ich schätze Du findest Sammelrelationen aller Kreisgrenzen pro Bundesland - sie bilden genau das ab, was auch ein nestedMP abbilden würde. Gleiches gilt für beliebige Sammelrelationen, die Flächen auf die ein oder andere Weise sammeln und taggen. Momentan lungern die alle mehr oder weniger zusammenhangslos in der DB - würde man sich auf ein paar Regeln für die Verschachtelung einigen, könnten die alle mittels nestedMP verlinkt bestehen. Was Du als schlichtes Polygon beschreibst, ist das, was übrig bleibt, wenn man die Flächenlinks (nachgeordnete MP-Mitglieder) innerhalb des gedachten 6. MP meiner letzten mail entfernt. Der Zusammenhang zu den Kindern ist dann nicht mehr explizit erkennbar, allenfalls implizit geometrisch. Der Komplexitätsgrad aller Relationen ist dann gleich, sie sind alle gewöhnliche Multipolygone. Erhält ein Datenverwerter (e.g. renderer) diese MP, überlappen die Flächen nun - entweder der Schlosspark wird als monotone Fläche opaque über die Einzelflächen gezeichnet, oder darunter. Für einfache Sachen (etwa buildings on top of landuses) kriegt ein Renderer das per Regel hin, ob das aber für jeden denkbaren Fall von (sinnvoller) Verschachtelung der Fall ist? Die Verschachtelung entsteht schon implizit durch gewöhnliche MP. Um es festzuhalten: Die Überlappung kann dadurch entstehen, dass je nach Sicht auf eine Einzelfläche, sie entweder ein Loch innerhalb einer anderen Fläche (sie wäre dann nur deren Grenze), sie selbst eine Gesamtfläche, sie eine Teilfläche von einer oder mehrerer größerer Flächen darstellt. Je nachdem, welches Thema ein Renderer hat, müssen nicht alle Sichten auf diese Einzelfläche dargestellt werden. Wären Flächenlinks innerhalb der Relation vorhanden, könnte ein Datenverwerter allerdings durch die schiere Anwesenheit von Flächenlink-Mitgliedern erkennen, ob mehr Detail vorhanden ist. Ohne die Geometrie zu berechnen, ließe sich entscheiden, welche Flächen dann beispielsweise nicht opaque bzw. nur mit Namen gerendert werden. Zugegeben, das
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 14:01 schrieb Christian Müller cmu...@gmx.de: Am 20.04.2012 03:14, schrieb Martin Koppenhoefer: Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als auch für die zukünftige Pflege bei Daten im Vergleich zu einer site-relation als bunte Mischung aller möglichen Elemente und Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche beschreibt. Das sie implizit durch mehrfach als Ringelemente verwendete ways vorhanden ist, war mir klar - das ist aber dennoch nicht das gleiche. +1 Sammelvariante: Eine Anfrage nach den Teichgeometrien innerhalb des Schlossparks ist durch lookup in die Relation zu lösen. Boundary-Only-Variante: (also nur die outers des Schlossparks) Man benutzt die Grenze des Schlossparks zum Verschneiden und sucht sich in den verbleibenden Daten die Teiche raus. genau, funktioniert immer, sofern die Grenzen aussen geschlossen ist, erfordert keine Relationen, und findet alle Elemente, nicht nur die, die ein Mapper eingetragen hat. Ausserdem sind Datenbanken mit Geofunktionen u.a. genau für Anfragen dieser Art optimiert. Bezogen auf einen kleineren Park ist der Aufwand für beide Varianten sicher vernachlässigbar. Für ein größeres Gebiet ergeben sich mit der Sammelvariante aber Vorteile - da man nicht verschneiden muss. da man einer händisch erstellten und von zig Mappern (davon die überwiegende Menge keine Experten, manche auch Anfänger oder Wenigmapper, manche arbeiten auch mit Tools ohne Unterstützung für alle Relationen, d.h. sie sehen evtl. nicht einmal in ihrem Editor, dass ein Objekt, das sie bearbeiten evtl. Teil einer site-Relation ist, oder sie halten nichts von Site-Relationen und fügen ein Objekt das sie erstellen absichtlich nicht dazu, etc.) weiterbearbeiteten Relation sowieso nicht wirklich trauen kann, würde ich selbst wenn es die Relation gibt mich lieber auf die geographischen Gegebenheiten verlassen, als auf die Relationenzugehörigkeit einer site-Relation. Es gibt natürlich auch Probleme: z.B. könnten die Relationen schlecht gepflegt sein und man erwischt nicht alle Ergebnisse, die man mit einem Verschnitt erhalten hätte. +1, s.o. Andererseits könnte ein Verschnitt sehr komplex werden - wenn das MP aus mehreren Einzelflächen besteht, also mehrere Verschnitte berücksichtigt werden müssen. dann werden die eben der Reihe nach abgearbeitet. Davon bekommst Du normalerweise gar nichts mit, die DB spuckt das Ergebnis aus und fertig. Mir ging es darum, aufzuzeigen, dass egal wie man das Kind nennt - type=collection, type=site, type=multipolygon - im Endeffekt über den Flächenbezug gesprochen wird. -1, multipolygon unterscheidet sich hier von site und collection dadurch, dass es nur eine Fläche definiert, während die anderen eine Gruppe definieren, die nicht notwendigerweise räumlichen Bezug haben muss. Z.B. könnte man einer site-Relation ein Ticket-Office zuordnen, das ausserhalb der site liegt. Eine collection (und auch eine site) kann alles enthalten, nodes, ways, Flächen, Relationen. Theoretisch müsste eine Relation überhaupt keine Geometrie haben und könnte trotzdem Sinn machen (weil sie als member in einer anderen Relation sitzt. So was haben wir bisher allerdings nicht oder kaum in der db, und ist auch mit unseren (Editier-)Mitteln eher schwer in Schuss zu halten). Ich habe jetzt nicht nachgeschaut, aber ich schätze Du findest Sammelrelationen aller Kreisgrenzen pro Bundesland - sie bilden genau das ab, was auch ein nestedMP abbilden würde. das hoffe ich nicht, wäre ja komplett überflüssiger Ballast, ich denke aber, dass es üblicherweise auch nicht so ist. Erhält ein Datenverwerter (e.g. renderer) diese MP, überlappen die Flächen nun - entweder der Schlosspark wird als monotone Fläche opaque über die Einzelflächen gezeichnet, oder darunter. Für einfache Sachen (etwa buildings on top of landuses) kriegt ein Renderer das per Regel hin, ob das aber für jeden denkbaren Fall von (sinnvoller) Verschachtelung der Fall ist? hast Du Dich schonmal mit den Render-Regeln von Mapnik auseinandergesetzt? Da spielt es bei den Flächen kaum eine Rolle, wie die getaggt sind, die sortiert er nach Größe (innerhalb desselben Layers, nicht alle Flächen sind in einem Layer). Es gibt aber auch überhaupt keinen Grund, Flächen grundsätzlich gefüllt darzustellen, manches macht als Grenze mehr Sinn. Wie gerendert wird, hat mit der Dateneingabe also dem Modell, wie die Welt in der DB abgebildet wird, nicht so viel zu tun. Je nachdem, welches Thema ein Renderer hat, müssen nicht alle Sichten auf diese Einzelfläche dargestellt werden. Wären Flächenlinks innerhalb der Relation vorhanden, könnte ein Datenverwerter allerdings durch die schiere Anwesenheit von Flächenlink-Mitgliedern erkennen, ob mehr Detail vorhanden ist. mehr Detail von was? Dein Vorschlag zielt darauf hinaus, alles was sowieso schon über räumliche Bezüge verbunden ist, nochmal mit site- und collection-Relationen zu
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo Wolfgang, Am 20.04.2012 12:04, schrieb Wolfgang: Ich glaube, an dieser Stelle missverstanden zu sein. Solange es nur um zusammengehörige Flächen gleichen Typs geht, reicht das Multipolygon völlig aus. Ich will nicht Multipolygone durch Sites ersetzen, sondern verhindern, dass - das Multipolygon mit Elementen verwässert wird, die mit der Fläche nichts zu tun haben (place etc) und - die Flächenberechnung / Darstellung im Multipolygon konzentrieren (wenn sie komplizierter ist als ein einfacher Umring) Weshalb verwässern? Anhand der inner/outer Rolle, die nur durch ways besetzt werden darf, ist doch klar, was zur Flächenberechnung herangezogen wird. Weshalb fürchtest Du die Aufnahme weiterer Elemente in anderen Rollen? Oder geht es Dir nur um die Größe, auf die ein MP dann u.U. anwachsen kann? Die Seefläche wird nicht als Loch im Park definiert, weil sie 1. zum Park gehört und 2. üblicherweise der Renderer damit klar kommt, die Wasserfläche hat insofern Vorrang. Die Zugehörigkeiten fasse ich genauso auf wie Du - damit sind wir bei der Überlappung der Flächen angekommen. Das Beispiel wird von den jetzigen Renderern sicher erwartungsgemäß priorisiert und richtig dargestellt. Spätestens wenn sich landuse=* und leisure=* MPs überlappen, kann ich mir aber nicht mehr vorstellen, wie eine Renderregel das sinnvoll priorisieren will - Nehmen wir an ein kleinerer Stadtpark überlappt auf den Rand einer großflächigeren Wiese. Es ist durch geographische Gegebenheit zu erkennen, dass die Überlappungsfläche je nach Sichtweise beiden MP zugeordnet werden kann, also erfasst ein OSMler das auch so - in klassischen Karten würde man vermutlich im Überlappungsgebiet schraffieren oder punkten. Da das ganze sehr theoretisch ist, lohnt eine Fortsetzung an dieser Stelle vermutlich erst mit einem echten Beispiel. Belassen wir es also dabei.. Wenn jemand eine Statistik aller Rosenbeete in den Schlossparks des Landes erstellen will, dann muss er eben abfragen, welche Beete sich räumlich in einem solchen Park befinden. - Etwas in der Richtung hatte ich im Hinterkopf. Für komplexe Statistiken ist der Rechenaufwand über die räumlichen Abfragen evtl. unnötig hoch und wenn es viele Anwender gibt, die unabhängig voneinander die gleichen Statistiken erstellen, verschwendet man Energie ;.-) Ist es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn Schachtelungszusammenhänge explizit in den Relationen wären? Klar können wir uns auch von diversen Rechenzentren abhängig machen, aber eine intelligente Lösung ist das nicht, klingt eher wie brute force.. Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel, wenn es um die Berechnung der Fläche geht, die sich aus den Einzelflächen der Kinder und Kindeskinder (..) ergibt. Schließlich sind nur die outer/inner Mitglieder der Kinder und Kindeskinder (..) interessant, die tatsächlich einen Beitrag zu Außen- oder Innenringen des nestedMP liefern. Ab einer bestimmten Schachtelungstiefe wird die Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht werden, also alle Relationen, die dann tatsächlich way-members als Mitglieder haben und nicht selbst ein nestedMP sind. Je tiefer dieser Baum, desto höher die Wahrscheinlichkeit, dass es mehr irrelevante members als relevante gibt. So ganz kann ich deinen Ausführungen nicht folgen. Im Prinzip ist das Multipolygon überraschend einfach zu berechnen und gleichzeitig geschickt aufgebaut. Es ging um (gedachte) nested MP, in denen MP Mitglieder anderer MP sind - das ist bisher nicht erlaubt. Für die gewöhnlichen MP, stimme ich Dir zu - schicke Sache. Mir fällt auf, dass der Terminus geschachtelte MP auch für die durch alternierende inner / outer Ringe konstruierten MP verwendet wird - von diesen habe ich ausdrücklich nicht gesprochen - mir ging es um die Verschachtelung von Flächen verschiedenen Typs, weil sie logisch Teil einer oder mehrerer anderer Flächen sind. [...] Das heißt auch, dass nur die Umringe als Typ outer definiert werden dürfen, die tatsächlich vom Typ des Multipolygons sind. Ich verweise dann einfach immer auf http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon - spart Tipp-Arbeit ;-) Für Grenzen bietet sich das Multipolygon an - nicht um irgendwelche inner zu definieren, sondern weil es möglich ist, das outer aus einer größeren Anzahl von (nicht geschlossenen) Polygonen zu definieren, die zusammen einen geschlossenen Umring ergeben. Ähnlich wie bei der coastline hat es gewisse Vorteile, nicht immer den ganzen Umring der z.B. USA laden zu müssen. Die Landesgrenze ist ein MP, die Kreisgenzen jeweils auch. Wer die Hauptstadt, Verwaltungszentrale oder was auch immer da rein bringen will, kann das dann über die Site machen. Members sind dann das Multipolygon mit der Grenze und der place-Node der Zentrale. Land und Kreise untereinander brauchen
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Duerfte ich als unbeteiligter Dritter dem OP diesen Link empfehlen: http://en.wikipedia.org/wiki/Spatial_database Interessanterweise gibt es keine gute Uebersetzung dafuer und Wikipedia verlinkt es auch nicht zu einem deutsche Artikel. Wer den findet, kann ihn ja gerne mal posten. Ich glaube, die spezielle Eigenschaft dieser Art der Datenhaltung scheint hier unbekannt, was den merkwuerdigen Optimierungswillen hin zu 'billigeren' Anfragen mit expliziten site-Relationen ausloest. Ich weiss ehrlich gesagt nicht, ob OSM wirklich so organisiert ist, aber ich habe es zumindest bisher immer angenommen. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 19.04.2012, 22:01 Uhr, schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Donnerstag, 19. April 2012 19:34:39 schrieb Joerg Fischer: Bernhard Weiskopf wrote: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Halte ich genauso. Ich erfasse den Regelfall, nicht seltene Sonderfälle wie Schnee auf dem Radweg. Sonst kommt der Nächste und entfernt alle maxspeed, denn die gelten schließlich nicht für Einsätze mit Sondersignal. Ist aber ganz einfach falsch. bicycle=designated ist das tag der Wahl. Gruß, Wolfgang bicycle=official ist das (neuere) tag der Wahl für benutzungspflichtige (Rad)Wege. Bei Wegen die nicht neben der Straße verlaufen, oder anders als mit dem blauen Schild gekennzeichnet sind, gibt es bicycle=designated :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 20. April 2012 15:03 schrieb Masi Master masi-mas...@gmx.de: Am 19.04.2012, 22:01 Uhr, schrieb Wolfgang wolfg...@ivkasogis.de: Ist aber ganz einfach falsch. bicycle=designated ist das tag der Wahl. bicycle=official ist das (neuere) tag der Wahl für benutzungspflichtige (Rad)Wege. Bei Wegen die nicht neben der Straße verlaufen, oder anders als mit dem blauen Schild gekennzeichnet sind, gibt es bicycle=designated :) So neu ist das auch nicht mehr. Und das entsprechende Proposel wurde kürzlich auf inaktiv gesetzt.[1] Das Proposel wurde seinerzeit notwendig, weil Uneinigkeit über die Bedeutung von bicycle=designated foot=designated bestand. Mein Eindruck ist, dass sich mittlerweile ein Konsens dahingehend gebildet hat, dass damit die blauen Scheiben mit den Fußgängern/Radfahrern (StVO Zeichen 237--241) gemeint sind. Entsprechend hat official seine Berechtigung mittlerweile verloren bzw. konnte sich ohnehin nicht durchsetzen.[2] Selbst nehme ich meine diesbezüglichen Edits auch wieder zurück, wenn ich darüber stolpere. Vielleicht meldet sich auch NOP hier noch zu Wort, wie er die Situation einschätzt. Statistische Analysen, wie sich die Tags über die Jahre entwickelt haben sind nach meiner Erkenntnis nicht existent und auch nicht ohne weiteres zu erstellen. Gruß, Falk [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Officially_dedicated_usage [2] Wenn aus diesen Beitrag mehr als 50 Beiträgen folgen, dann nehme ich diese Behauptung umgehend zurück und behaupte das Gegenteil. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 14:57 schrieb Ronnie Soak chaoschaos0...@googlemail.com: Ich weiss ehrlich gesagt nicht, ob OSM wirklich so organisiert ist, aber ich habe es zumindest bisher immer angenommen. AFAIK ist die Haupt-db eine Postgres-db ohne PostGIS (das sind die spatial-Erweiterungen), während Mapnik z.B. eine Datenbank mit PostGIS verwendet (verwenden kann). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 18.04.2012 17:12, schrieb Andre Joost: +1 Es gibt ja auch Räder mit besonderen Ansprüchen (Liegedreirad, Anhänger, Rennrad). Die Zumutbarkeit entscheidet der Radfahrer selbst. Den Rest regelt die Rechtsschutzversicherung ;-) Routingmäßig nervig wird das bicycle=no, wenn der Radweg nicht mit allen querenden Straßen (auch gegenüber) verbundne ist, oder solche Anschlüße im Garmin wegen -remove-short-arcs unter den Tisch fallen. Ohne das bicycle=no wird man dann wenigstens auf der Straße geroutet. Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ich kann dazu (besondere Ansprüche) in der deutschen StVO nichts finden. Nur, dass Rennräder von der Lichtpflicht ausgenommen sind. Diese Ausnahme kenne ich nur aus Österreich (Breite, Rennrad, etc.) Es gibt zwei Fälle: a) Straße bicycle=no -- Der StV-Teilnehmer muss selbst entscheiden, wann er sich dem Navi wiedersetzt und nicht den Radweg nutzten muss. b) Straße ohne Beschränkung -- Der StV-Teilnehmer muss selbst erkennen, wann er den Radweg nutzen muss. Egal, ob so oder so, ein mündiger Radfahrer sollte mit beidem leben können. LG, Jimmy PS: Wenn ein begleitender Radweg nicht an eine Kreuzung angebunden ist, dann wäre die Benützungspflicht aufgehoben (auch wenn er knapp daneben verläuft, da er nicht unter straßenbegleitend fällt), aber das bicycle=no würde den Router kräftig durcheinanderbringen. Ich bleibe Relationsanhänger: Eine gemeinsame Relation (Fahrbahn, Grünstreifen, Radweg, Gehweg) und der Router wüsste was zu tun ist, ohne komplizierte Algorithmen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 20. April 2012 15:42 schrieb Jimmy_K jimm...@gmx.at: Ich bleibe Relationsanhänger: Eine gemeinsame Relation (Fahrbahn, Grünstreifen, Radweg, Gehweg) und der Router wüsste was zu tun ist, ohne komplizierte Algorithmen. Kann man dafür eine etablierte oder vorgeschlagene Relation verwenden, und falls ja welchen Typs, oder sollte dazu ein neues Proposal erstellt werden? Warum willst Du da auch den Grünstreifen einbinden? Würde ein Poller auch in diese Relation kommen? Und eine Telefonzelle zwischen Radweg und Straße? Ein Verkehrsschild? Ein Hydrant? Ein Notruf-telefon? Eine Straßenlaterne? Der Gartenzaun, der den Fußweg begrenzt? Die Hausnummern? Der Bordstein? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, On 04/20/2012 02:54 PM, Christian Müller wrote: Ist es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn Schachtelungszusammenhänge explizit in den Relationen wären? Als jemand, der mit solchen Fragen staendig in der Praxis umgeht, kann ich sagen: Es ist 100% klar, dass ich mich nie darauf verlassen kann, dass unsere Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal geometrisch gueltige Polygone hin...) Ich muss also in jedem Fall, wenn ich jetzt nicht gerade nur Christian Muellers Heimatort analysieren will, die geometrische Abfrage *zusaetzlich* zu etwaigen explizit modellierten Beziehungen machen. Daher spart mir die explizierte Modellierung nichts, egal, wie schoen sie in der Theorie waere. (Ich teile allerdings auch die Ansicht, dass sie selbst in der Theorie genauso schoen ist wie is_in, also gar nicht ,) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Österreich NUTS (war: Suche nach Elbufer, Bad Schandau)
/1/ stimmt auch: AT ... Österreich AT1 ... Ostösterreich (NUTS1, wie gesagt, eine willkürliche Dreiteilung Österreichs) AT11 ... Burgenland (NUTS2, ein Bundesland) AT111 ... Mittelburgenland (NUTS3, eine willkürliche Region) und dann die Gemeinden (LAU2) Hier sehr übersichtlich: http://de.wikipedia.org/wiki/NUTS:AT Aber die Verwaltungseinteilung (mit Gemeindekennzahl) sind: * Bundesland: Burgenland (1) /4/ * Politischer Bezirk (PB): z.B. Oberpullendorf (108, Kennzeichen OP) /6/ * Gemeinde Deutschkreuz (10801) /8/ Gemeinde Draßmarkt (10802) ... (und dann sind PB noch in ein oder mehrere Gerichtsbezirke unterteilt) und noch kleiner: * Stadtbezirke, Gemeindebezirke /9/ (Wien, Graz, Linz,?) * Katastralgemeinde /10/ /4/ http://de.wikipedia.org/wiki/Bundesland_(%C3%96sterreich) http://de.wikipedia.org/wiki/Bundesland_%28%C3%96sterreich%29 /6/ http://de.wikipedia.org/wiki/Liste_der_Bezirke_und_Statutarst%C3%A4dte_in_%C3%96sterreich /8/ http://de.wikipedia.org/wiki/Gemeinde_(%C3%96sterreich) http://de.wikipedia.org/wiki/Gemeinde_%28%C3%96sterreich%29 /9/ http://de.wikipedia.org/wiki/Wiener_Gemeindebezirke /10/ http://de.wikipedia.org/wiki/Katastralgemeinde /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo nochmal, noch ein Nachtrag - für Statistiken, welche die implizite Variante der Flächenbezüge als Grundlage nutzen, wäre zwar auch ein Cache für aufwendig errechnete Ergebnisse denkbar - für einen solchen existieren aber m.W. in und um OSM weder Standards noch die Möglichkeit ihn sinnvoll zu teilen / publishen. Gibt es grob gedacht eine Kreuzung aus Nominatim und dem Relation Browser für das Browsen von Flächenbezügen? Evtl. gibt es da schon Ansätze in OSM Inspector oder anderen Validatoren. Ist die Overpass API momentan die einzige Möglichkeit Daten-Queries zu tätigen, oder gibt es noch andere Dienste, die evtl. zusätzlich, aus den OSM-Daten abgeleitete Daten bereitstellen? Die MapQuest-Dienste sind mir geläufig. Gruß und Dank, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 17:27 schrieb Christian Müller cmu...@gmx.de: Ist die Overpass API momentan die einzige Möglichkeit Daten-Queries zu tätigen, oder gibt es noch andere Dienste, die evtl. zusätzlich, aus den OSM-Daten abgeleitete Daten bereitstellen? Die MapQuest-Dienste sind mir geläufig. Es gibt da diverse Dienste, neben den von Dir genannten (Overpass und Nominatim) kommen mir u.a. XAPI und ein Online-Datenbank-Interface in der Schweiz in den Sinn, aber sobald Du wirklich viele Abfragen machen willst, empfehle ich Dir, eine eigene Kopie der DB (bzw. eines Ausschnitts) aufzusetzen. Dazu gibt es div. Möglichkeiten und Varianten, das Wiki hat einiges an Anleitungen und Tipps parat, s.z.B. osm2pgsql im Wiki für eine räumliche DB mit einem thematischen Auszug (site wird davon allerdings ignoriert, Multipolygone sind unterstützt). Auch osmium (framework) oder osmosis (damit kannst Du u.a. die DB replizieren, es gibt aber verschiedene Schemata) oder imposm könnten evtl. für Dich interessant sein. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Du kannst mit dem Planet Dump die Daten in jede DB stopfen, wenn Du dir die Mühe machst einen Converter zu schreiben. Nochmal: Es geht nicht darum, alle automatisch ermittelbaren/herstellbaren Flächenbezüge, manuell zu erfassen, sondern nur die, welche dem Mapper sinnvoll erscheinen. Der Optimierungswille den Du ansprichst, hat nicht nur etwas mit DBs zu tun. Warum gehen davon eigentlich alle aus? Nicht immer stecken die zu verarbeitenden Daten in einer fetten DB, die bereitwillig rechnet. Gäbe es die Flächenbezüge in den Daten wären z.B. auch billige JavaScript Hacks denkbar, die dann client-seitig laufen, anstatt einen Server zu belasten.. Gruß Am 20.04.2012 14:57, schrieb Ronnie Soak: Duerfte ich als unbeteiligter Dritter dem OP diesen Link empfehlen: http://en.wikipedia.org/wiki/Spatial_database Interessanterweise gibt es keine gute Uebersetzung dafuer und Wikipedia verlinkt es auch nicht zu einem deutsche Artikel. Wer den findet, kann ihn ja gerne mal posten. Ich glaube, die spezielle Eigenschaft dieser Art der Datenhaltung scheint hier unbekannt, was den merkwuerdigen Optimierungswillen hin zu 'billigeren' Anfragen mit expliziten site-Relationen ausloest. Ich weiss ehrlich gesagt nicht, ob OSM wirklich so organisiert ist, aber ich habe es zumindest bisher immer angenommen. Gruss, Chaos ___ 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] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20.04.2012 16:19, schrieb Frederik Ramm: Hallo, On 04/20/2012 02:54 PM, Christian Müller wrote: Ist es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn Schachtelungszusammenhänge explizit in den Relationen wären? Als jemand, der mit solchen Fragen staendig in der Praxis umgeht, kann ich sagen: Es ist 100% klar, dass ich mich nie darauf verlassen kann, dass unsere Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal geometrisch gueltige Polygone hin...) Liegt vielleicht auch an der elitären Haltung, die man ihnen entgegenbringt, will man es erklären (nur so ein Gedanke..). Ich stimme Dir im Inhalt zu, die Form finde ich grauenhaft.. Ist halt leider so. Ich muss also in jedem Fall, wenn ich jetzt nicht gerade nur Christian Muellers Heimatort analysieren will, die geometrische Abfrage *zusaetzlich* zu etwaigen explizit modellierten Beziehungen machen. Daher spart mir die explizierte Modellierung nichts, egal, wie schoen sie in der Theorie waere. Prophetentum ist eigentlich nicht unser Metier, aber ich stimme ein in den Kanon, dass OSM vermutlich immer ein Sammelsorium an verschiedensten Ausdrucksmöglichkeiten für geographische Sachverhalte bleiben wird. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 18:00 schrieb Christian Müller cmu...@gmx.de: Der Optimierungswille den Du ansprichst, hat nicht nur etwas mit DBs zu tun. Warum gehen davon eigentlich alle aus? Nicht immer stecken die zu verarbeitenden Daten in einer fetten DB, die bereitwillig rechnet. Gäbe es die Flächenbezüge in den Daten wären z.B. auch billige JavaScript Hacks denkbar, die dann client-seitig laufen, anstatt einen Server zu belasten.. Das stimmt, und wäre ein interessantes Thema für ein paralleles Projekt, wo man solche Bezüge aus der OSM db ableitet, und zum download bereitstellt. Man sollte aber nicht die Server des Gesamtprojekts, wo diese Bezüge bereits enthalten sind, --- wenn auch in einer Form, die eine gewisse Verarbeitung erfordert, um sie herauszubekommen --- damit belasten. Die Relationen würden sämtliche Nutzer der Daten (auch Mapper) zusätzlich belasten, jeden der ein Gebiet herunterlädt wo solche Dinge redundant explizit in speziellen Relationen stecken, und jeden, der dort die Daten irgendwie interpretieren oder weiterverarbeiten will, unabhängig davon, ob er das braucht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20.04.2012 16:19, schrieb Frederik Ramm: Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal geometrisch gueltige Polygone hin...) [...] Oder wir haben zu wenig gute How To Vids.. Vielleicht eine Youtube Hilfe in JOSM integrieren. Aber das feature nicht Video2Brain nennen, das ist m.W. ne Marke von einem größeren Buchverlag. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, Am Freitag, 20. April 2012 17:44:57 schrieb Martin Koppenhoefer: Am 20. April 2012 17:27 schrieb Christian Müller cmu...@gmx.de: Ist die Overpass API momentan die einzige Möglichkeit Daten-Queries zu tätigen, oder gibt es noch andere Dienste, die evtl. zusätzlich, aus den OSM-Daten abgeleitete Daten bereitstellen? Die MapQuest-Dienste sind mir geläufig. Es gibt da diverse Dienste, neben den von Dir genannten (Overpass und Nominatim) kommen mir u.a. XAPI und ein Online-Datenbank-Interface in der Schweiz in den Sinn, aber sobald Du wirklich viele Abfragen machen willst, empfehle ich Dir, eine eigene Kopie der DB (bzw. eines Ausschnitts) aufzusetzen. Dazu gibt es div. Möglichkeiten und Varianten, das Wiki hat einiges an Anleitungen und Tipps parat, s.z.B. osm2pgsql im Wiki für eine räumliche DB mit einem thematischen Auszug (site wird davon allerdings ignoriert, Multipolygone sind unterstützt). Auch osmium (framework) oder osmosis (damit kannst Du u.a. die DB replizieren, es gibt aber verschiedene Schemata) oder imposm könnten evtl. für Dich interessant sein. Für den Anfang würde ich osm2postgresql empfehlen. Da bekommt man den gewählten Ausschnitt, ohne dass da irgendwas rausgefiltert wird. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Hallo, Am Freitag, 20. April 2012 15:49:16 schrieb Martin Koppenhoefer: Am 20. April 2012 15:42 schrieb Jimmy_K jimm...@gmx.at: Ich bleibe Relationsanhänger: Eine gemeinsame Relation (Fahrbahn, Grünstreifen, Radweg, Gehweg) und der Router wüsste was zu tun ist, ohne komplizierte Algorithmen. Kann man dafür eine etablierte oder vorgeschlagene Relation verwenden, und falls ja welchen Typs, oder sollte dazu ein neues Proposal erstellt werden? Warum willst Du da auch den Grünstreifen einbinden? Würde ein Poller auch in diese Relation kommen? Und eine Telefonzelle zwischen Radweg und Straße? Ein Verkehrsschild? Ein Hydrant? Ein Notruf-telefon? Eine Straßenlaterne? Der Gartenzaun, der den Fußweg begrenzt? Die Hausnummern? Der Bordstein? Nur die Fahrbahn(en) und die sie begleitenden Rad-, Fuß-, was-auch- immer-Wege. Das wäre nicht nötig ohne diese unseligen getrennt gemappten Wege. Vermutlich ist es an der Zeit für eine neue Relation. Eine Weiterentwicklung (unter neuem Namen) von Dual-CarriageWay . Wenn Mapnik den mal unterstützt hätte, wären wir wahrscheinlich auch schon ein ganzes Stück weiter. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Hallo, Am Freitag, 20. April 2012 15:03:23 schrieb Masi Master: bicycle=official ist das (neuere) tag der Wahl für benutzungspflichtige (Rad)Wege. Bei Wegen die nicht neben der Straße verlaufen, oder anders als mit dem blauen Schild gekennzeichnet sind, gibt es bicycle=designated :) http://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren Mindestens umstritten. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
On 20/04/12 15:19, Falk Zscheile wrote: Am 20. April 2012 15:03 schrieb Masi Master masi-mas...@gmx.de: Am 19.04.2012, 22:01 Uhr, schrieb Wolfgang wolfg...@ivkasogis.de: Ist aber ganz einfach falsch. bicycle=designated ist das tag der Wahl. bicycle=official ist das (neuere) tag der Wahl für benutzungspflichtige (Rad)Wege. Bei Wegen die nicht neben der Straße verlaufen, oder anders als mit dem blauen Schild gekennzeichnet sind, gibt es bicycle=designated :) So neu ist das auch nicht mehr. Und das entsprechende Proposel wurde kürzlich auf inaktiv gesetzt.[1] Das Proposel wurde seinerzeit notwendig, weil Uneinigkeit über die Bedeutung von bicycle=designated foot=designated bestand. Mein Eindruck ist, dass sich mittlerweile ein Konsens dahingehend gebildet hat, dass damit die blauen Scheiben mit den Fußgängern/Radfahrern (StVO Zeichen 237--241) gemeint sind. Entsprechend hat official seine Berechtigung mittlerweile verloren bzw. konnte sich ohnehin nicht durchsetzen.[2] Selbst nehme ich meine diesbezüglichen Edits auch wieder zurück, wenn ich darüber stolpere. Das war eher ein automatisierter Prozess und heiß nichts anderes, als dass geraume Zeit nichts verändert wurde (keine Aktivität). Vielleicht meldet sich auch NOP hier noch zu Wort, wie er die Situation einschätzt. Statistische Analysen, wie sich die Tags über die Jahre entwickelt haben sind nach meiner Erkenntnis nicht existent und auch nicht ohne weiteres zu erstellen. Gruß, Falk [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Officially_dedicated_usage [2] Wenn aus diesen Beitrag mehr als 50 Beiträgen folgen, dann nehme ich diese Behauptung umgehend zurück und behaupte das Gegenteil. Ich verwende *=official um deutlich zu machen, dass dort blaue Schilder angebracht sind. *=designated ist mir in dieser Hinsicht einfach (noch) zu schwammig. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 18.04.2012 17:12, schrieb Andre Joost: Routingmäßig nervig wird das bicycle=no, wenn der Radweg nicht mit allen querenden Straßen (auch gegenüber) verbunden ist Ja, ein Beispiel hatte ich jüngst im Forum demonstriert: http://www.openrouteservice.org/index.php?start=8.17148,53.24343end=8.17287,53.24061pref=Pedestrianlang=denoMotorways=falsenoTollways=false Hier wird für Radler und Fußgänger das Überqueren der Kreuzung verhindert. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Admin-Levels und Place-Nodes (war: Suche nach Elbufer, Bad Schandau)
On Fri, Apr 20, 2012 at 11:04:43AM +0200, Andreas Labres wrote: On 19.04.12 19:44, Sarah Hoffmann wrote: Gibt's diese Tabelle zu admin_level=X gehört place=Y irgendwo im Wiki? Das wäre glaub ich auch hilfreich, wenn alle die gleiche Sprache sprechen. Es gibt eine arg knappe Beschreibung auf den Wiki-Seiten von Nominatim: http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Country_to_Street_level Das ist nicht mehr ganz aktuell. Müsste man mal etwas überarbeiten. Wo dazwischen ist da place=region angedacht? admin_level=5, aber ich weiss nicht, ob es überhaupt irgendwo auf der Welt konsistent so gebraucht wird. *) in AT gäb's noch Marktgemeinden, die quasi einen Wichtigkeitsstatus zwischen place=town und place=village hätten. Wenn ich Wikipedia richtig verstehe, ist das eher ein Titel mit dem sich die Gemeinden schmücken können, aber keine wirkliche zusätzliche Verwaltungsstufe. Insofern macht es aus Sicht der Suche relativ wenig Unterschied, wie man die taggt. Ich würde eher zu einem Zusatztag tendieren für solche feinen Unterscheidungen. s.o., irgendwie fehlt mir ein place=city_district o.ä. für den Stadtbezirk. Oder man nimmt place=suburb als Stadtbezirk und place=quarter als kleinteiligen Stadtteil (AT: Katastralgemeinde), wie Martin K. es denkt/vorschlägt. N.B.: Katastralgemeinde ist keine nur-städtische Ausprägung, jede Gemeinde ATs ist in ein oder mehrere Katastralgemeinden unterteilt. Nur in ländlichen Gegenden sind die Ortschaftsnamen meist die wichtigeren Namen. Unterhalb vom city/town-Level wird es wirklich chaotisch, weil es da praktisch keinen Konsens mehr gibt und das Vermischen von städischen und ländlichen Strukturen macht es nicht einfacher. Von den Tags, die Nominatim auswertet sind place=suburb (level 10) und place=neighbourhood(11) am gebräuchlichsten. Für Wien würde das vermutlich passen, für die ländlichen Gegenden eher weniger. Aber ihr sollt ja ohnehin nicht für die Suchmaschine taggen. ;) Wenn ihr da ein konsistentes Schema habt, kann man durchaus darüber reden das, wenn nötig, auch der Suche beizubringen. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Meine Erfahrungen und mein Vorgehen fasse ich nochmal zusammen: Wenn ein ausgeschilderter Radweg baulich von der Straße abgesetzt ist, man also nicht beliebig wechseln und abbiegen kann, zeichne ich den Radweg in der Regel separat, analog zum Vorgehen bei anderen Fahrbahnen. Dazu kommt an den Radweg bicycle = designated (oder bicycle = official, das habe ich bisher nicht benutzt). Wenn für den Radweg Benutzungspflicht, also Radfahrverbot auf der Straße besteht (gem. StVO), kommt zusätzlich an die Straße bicycle = no. Oft kommt hinzu oneway = yes bzw. oneway = no, je nach erlaubten Fahrtrichtungen, insbesondere wenn die Radwege an beiden Seiten neben der Straße verlaufen. Damit funktioniert das Routen bisher einwandfrei, in großen Zoomstufen wird sogar angezeigt, wenn man auf die Straße oder die andere Radwegseite wechseln muss, um beispielsweise links abbiegen zu können. Im Bereich von Abzweigen muss man Verbindungen, z. B. benutzbare querende Einfahrten, genau erfassen, darauf hat Andre schon hingewiesen. Abmalen aus Luftbildern klappt hier nicht, man muss detaillierte Ortskenntnisse besitzen. Bei Zweifeln zeichne ich den Radweg nicht separat. Wenn am Radweg noch ein Fußweg hängt, muss das Routing auch für Fußgänger beachtet werden. Bei Fußwegen (highway = footway), die ganz oder teilweise mit Zeichen 240 (gemeinsamer Fuß- und Radweg, foot = designated und bicycle = designated, aus Link von Wolfgang) gekennzeichnet sind, klappt das Routen für Radfahrer leider oft nicht. Hier ändere ich zurzeit auf highway = path), auch wenn es sich vom Aufbau um einen typischen schmalen Fußweg handelt. Dann kommt zusätzlich hinzu horse = no, denn der Defaultwert bei path ist horse = yes. Ist der Radweg - aus welchen Gründen auch immer - nicht benutzbar, kann man auf der Straße fahren, man fährt halt ein paar Meter neben der Routinglinie. PS: Gesetzte, auch die StVO, gibt es hier: http://www.gesetze-im-internet.de/aktuell.html Die juris GmbH veröffentlicht den Wortlaut der Gesetze im Auftrag der Bundesregierung, allerdings mit etwas Verzögerung zum Bundesanzeiger. From: Wolfgang [mailto:wolfg...@ivkasogis.de] Sent: Friday, April 20, 2012 7:55 PM Hallo, ... http://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren Mindestens umstritten. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 20.04.2012 22:00, schrieb Bernhard Weiskopf: Wenn für den Radweg Benutzungspflicht, also Radfahrverbot auf der Straße besteht (gem. StVO), kommt zusätzlich an die Straße bicycle = no. Ich hab ja nichts dagegen die Straße als begleitender benutzungspflichtiger Radweg existiert zu markieren, aber bitte nicht mit bicycle=no. Es ist dann für Auswertungen nicht mehr erkennbar ob das Verbot implizit oder explizit besteht, und falls irgendwann mal die Benutzungspflicht aufgehoben werden sollte, muss man alles neu kontrollieren ob ein Verbotsschild dort steht. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Hallo, Am Freitag, 20. April 2012 22:18:36 schrieb Chris66: Am 20.04.2012 22:00, schrieb Bernhard Weiskopf: Wenn für den Radweg Benutzungspflicht, also Radfahrverbot auf der Straße besteht (gem. StVO), kommt zusätzlich an die Straße bicycle = no. Ich hab ja nichts dagegen die Straße als begleitender benutzungspflichtiger Radweg existiert zu markieren, aber bitte nicht mit bicycle=no. +1 Vielleicht kann man sich da auf ein neues tag einigen. Wenn dann noch eine Relation besteht, die Fahrbahn und Nebenwege verbindet, um so besser. Übrigens ist für mich path die schlechteste aller Alternativen. Die Unterscheidung zu wirklichen Pfaden, z.B. Alpen, Moore, ... wird verwischt. Lieber Hauptnutzung cycleway/footway und die andere Nutzung mit yes dazu. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Toolchain Mapnik2 in einfach
Hallo Liste, ich habe mir auf Ubuntu eine Mapnik Toolchain aufgebaut nach diesem HowTo: http://switch2osm.org/serving-tiles/building-a-tile-server-from-packages/ Hat auch wunderbar funktioniert, allerdings bekomme ich wohl nur eine Mapnik 0.7 Installation. So wie ich verstanden habe, basiert der kürzlich aufgefrischte German Style nun auf Mapnik 2 und funktioniert nicht mit meiner Installation. Das im howto genutzte Repository von Kai Krüger scheint nur Mapnik 0.7 zu installieren. Hat jemand eine Idee, wie ich ähnlich einfach wie in obigem Link beschrieben eine Mapnik 2 installation bekomme? Ich bin kein Progger und tu mich schwer mit den HowTos die den gesamten manuellen Prozess mit Kompilieren der unzähligen Quellcodes beschreiben. Ist recht aufwändig und fehleranfällig, so dass ich den Versuch nach einer Nacht aufgegeben habe:-) Hintergrund ist, dass ich gerne für Locus Pro über Mobac Offline Karten generiere und diese, verständlicherweise, nicht über den offiziellen osm-Server gebaut werden sollen. Ist lokal auch viel schneller, grad bei Zoom 13. Ausserdem mache ich noch ein paar Anpassungen an den Style (zB highway=primary in rot statt dem mit BABs leicht zu verwechselden orange). Vielen Dank, MoosHam ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, On 04/20/2012 06:08 PM, Christian Müller wrote: Es ist 100% klar, dass ich mich nie darauf verlassen kann, dass unsere Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal geometrisch gueltige Polygone hin...) Liegt vielleicht auch an der elitären Haltung, die man ihnen entgegenbringt, will man es erklären (nur so ein Gedanke..). Ich stimme Dir im Inhalt zu, die Form finde ich grauenhaft.. Ist halt leider so. Du solltest das nicht als die Mapper sind alle bloede lesen, dann ist es auch nicht mehr grauenhaft. Es ist einfach eine Tatsache, dass an unserer Karte sehr viele Leute mitarbeiten, denen Informatikerdenken, denen abstrakte Modelle, ordentliche Datenstrukturen und so weiter nichts bedeuten und die sich in diese Welt nicht hineindenken koennen. Ein Stueck weit kann man durch clevere Editoren oder durch gute Howtos dafuer sorgen, dass auch solche Leute einen nuetzlichen Beitrag zum Projekt leisten koenen. Und in dem Masse, indem wir mehr Leute fuer zum Mitmachen gewinnen, werden wir in immer geek-fernere Bevoelkerungsschichten vorstossen. Vor dem Hintergrund ist es einfach voellig illusorisch, anzunehmen, man koennte irgendwann einen Zustand erreichen, in dem die Leute nicht bloss eine Grenzlinie zeichnen, nicht bloss einen geschlossenen Grenz-Way ziehen (was schon etwas komplizierter ist), nicht bloss ein schoenes Netz von Multipolygonen mit gemeinsam genutzten Kanten aufziehen (was nochmal diffiziler ist), sondern auch noch eine schoene explizite Hierarchie in das alles einbauen. Solche komplizierten Schemata muessen ja auch pflegbar sein. Das hat nichts damit zu tun, dass unsere Mapper Idioten sind; sie sind halt in zunehmendem Masse einfach Durchschnittsmenschen mit durchschnittlichen Faehigkeiten, und dazu muss auch unser Datenmodell passen. Denn *sonst* passiert genau das, was ab und zu mal in Beschwerden an die Data Working Group hochkocht, dass irgendwo einer muehevoll alles ordentlich und korrekt getaggt hat und die ganzen Neulinge mit boesen Mails verscheucht, die ihm seine Gegend kaputt machen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Frederik Ramm frede...@remote.org wrote: Solche komplizierten Schemata muessen ja auch pflegbar sein. +1 Die ÖPNV Relationen sind das beste Beispiel dafür, wie sich ein als möglichst umfassend und stimmig befundenes Oxomoa Schema einfach nicht durchsetzt. Selbst die Spezialisten mappen das Schema in zig Varianten. Die meisten örtlichen Mapper hingegen setzen intuitiv an die Stelle des Haltestellen-Schildes ein busstop und fertig. Denn genau diese Vokabel haben sie im Englisch-Unterricht oder als muttersprachliches Kind als Bezeichnung dafür gelernt. Wird eine Bushaltestelle verlegt, dann wird das Schild versetzt oder temporär ein anderes aufgestellt und das originale als ungültig gekennzeichnet. Dass jede Richtung einzeln gemappt wird, wird noch nahezu jedem klar. Aber dass zusätzlich zum busstop an der Stelle des Schildes noch ein Punkt auf der Straße gesetzt werden muss, erschließt sich den meisten nicht. Wenn sich aus der Schildstandort und dem Straßenverlauf in der Realität ergibt, wo der Bus hält, dann sollte das auch in OSM möglich sein. Und das kann dann auch nahezu jeder, der Karten versteht als abgebildete Realität verstehen. Auch Umsteigehaltestellen (als Relation) zusammenzufassen, dürfte nahezu jeder verstehen, der schon einmal umgestiegen ist. Ws nutzt OSM ein komplizertes Schema, wenn es nur wenige anwenden können? Möglicherweise muss man seine Freiheit, etwas mappen zu dürfen dann aufgeben, wenn es mehrfach so viele Mapper aus- als einschließt. Ergo: Die Modelle müssen so einfach und suggestiv wie möglich sein. Wenn ein Modell zu kompliziert wird, führe es nur dann ein, wenn Du ein allgemeinverständliches Editor Plugin dafür liefern kannst. Das hat nichts damit zu tun, dass unsere Mapper Idioten sind; Richtig! Denn nicht jeder macht den Computer zu einem seiner Lebensmittelpunkte. Es gibt tausend andere Dinge neben Multipolygonen etc, die man tun kann und dennoch ein lebenswertes Leben gestalten. Auch OSM-Geeks sind nicht zwangläufig deswegen blöd, wenn sie keine Gebinde aus Hunderten von Blumen herstellen, keine Pferde flüstern, keine 20 Kinder täglich neu begeistern, keinen LKW mit Anhänger rückwärts in eine 20 cm breitere Einfahrt setzen oder aus dem Stand einen Salto machen können. Aber genau diese Leute brauchen wir, wenn sie als Hobby beispielsweise geocachen, wandern, Boot-fahren, angeln oder radfahren. Die jeweils Anderen sind eben anders aber deswegen nicht dumm. Zurück zum multipolygon und zur boundary. Das multipolygon ist ein geometrisches Objekt und hat zunächst einmal wenig mit OSM zu tun. Was wir erfassen, ist eine Grenze, also boundary. Von daher wird es sich wesentlich weniger Mappern erschließen, warum ich an ein multipolygon Landkreis X dranpappen soll anstatt an ein boundary. Denn schließlich bezeichne ich auch keine curve mit Kirchstraße. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] suggerimenti pratici
Nel mappare mi sono venute a galla delle difficoltà. mi spiego Quando ho inserito dei numeri civici ho assegnato all'immobile un punto taggandolo con entrance=yes il problema è che il simbolo che ne deriva (due freccette orizzontali di sensioopposto dentro un quadratino bianco) non si ridimensionano al cambiare dello zoom per cui quando faccio delle visuali ampie il quadratino mi diventa anche più grande dell'edificio stesso. Devo impostare qualche settaggio oppure è un problema che non posso risolvere da solo? Un'altro quesito è: Vorrei stampare delle videate per poi uscire e prendere appunti sulla stampa ma non trovo il comando stampa e sono quindi costretto a fare ctrl+stamp ed incollare in un documento world. Come posso fare per stampare direttamente da JOSM? Grazie!___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Bridge oppure culvert ?
Am 20.04.2012 10:17, schrieb Alech OSM: Ciao da Firenze. Quando un fosso o rivo , waterway=stream passano sotto quattro-sei binari della ferrovia oppure sotto una rotatoria stradale, e lo spazio coperto è più lungo che largo (rispetto alla direzione dell’acqua) si deve usare bridge per la strada oppure culvert per il fosso ? Oppure entrambi ? Io ci metto culvert quando non c'è un ponte sopra, ma l'acqua passa in un tubo (di qualsiasi dimensione). Dove non c'è la balustrata sulla strada/ferrovia, non ci metto il bridge. -- cheers, Alex ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: Re: suggerimenti pratici
Un'altro quesito è: Vorrei stampare delle videate per poi uscire e prendere appunti sulla stampa ma non trovo il comando stampa e sono quindi costretto a fare ctrl+stamp ed incollare in un documento world. Come posso fare per stampare direttamente da JOSM? C'è http://walking-papers.org/ per stampare mappe già suddivise in quadranti. In alternativa, se ti serve una cosa più semplice, puoi esportare dal sito un'immagine JPG o PNG, e poi stamparla col tuo software preferito. Ciao, Simone OK grazie però non riesco a capire perchè JOAM non abbia la funzione di stampa che è una caratteristica fondamentale di qualsiasi programma. Non essendo un programmatore non posso capire il perchè nessuno aggiunge questa funzione, non è proprio fattibile?. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Bridge oppure culvert ?
Am 20. April 2012 11:44 schrieb Alexander Roalter alexan...@roalter.it: Am 20.04.2012 10:17, schrieb Alech OSM: Io ci metto culvert quando non c'è un ponte sopra, ma l'acqua passa in un tubo (di qualsiasi dimensione). +1, di solito insieme a layer=-1 Dove non c'è la balustrata sulla strada/ferrovia, non ci metto il bridge. bridge metto a precindere di balustrate. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Bridge oppure culvert ?
Il 20 aprile 2012 10:17, Alech OSM alech.hos...@gmail.com ha scritto: Ciao da Firenze. Quando un fosso o rivo , waterway=stream passano sotto quattro-sei binari della ferrovia oppure sotto una rotatoria stradale, e lo spazio coperto è più lungo che largo (rispetto alla direzione dell’acqua) si deve usare bridge per la strada oppure culvert per il fosso ? Oppure entrambi ? In casi del genere io uso solo tunnel=culvert su waterway=stream. bridge=yes lo metto dove è evidente che la costruzione è un ponte. In tutti i casi in cui ci sono vie che si incrociano è importante utilizzare il tag layer. Considerando il layer=0 implicito e corrispondente al suolo, utilizza layer=-1 o layer=1 congruentemente. Puoi anche utilizzare numeri più alti per incroci su più livelli. Paolo ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] suggerimenti pratici
Il giorno ven, 20/04/2012 alle 10.01 +0200, davide.bagn...@libero.it ha scritto: Nel mappare mi sono venute a galla delle difficoltà. mi spiego Un'altro quesito è: Vorrei stampare delle videate per poi uscire e prendere appunti sulla stampa ma non trovo il comando stampa e sono quindi costretto a fare ctrl+stamp ed incollare in un documento world. Come posso fare per stampare direttamente da JOSM? Non l'ho mai usato ma esiste un plugin di josm che si chiama print, forse è quello che ti ci vuole... -- Ciao Gio. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Re: suggerimenti pratici
Il 20/04/2012 12:11, davide.bagn...@libero.it ha scritto: OK grazie però non riesco a capire perchè JOAM non abbia la funzione di stampa che è una caratteristica fondamentale di qualsiasi programma. Perché di solito i diversi programmi producono un prodotto pronto per essere stampato, mentre il prodotto finito di JOSM è un insieme di dati da inserirsi in un database: non credo che sia così utile avere dei numeri e delle lettere stampati su carta. A te non interesserebbero, no? In alternativa bisognerebbe includere un motore di rendering, ma usando quale stile? Meglio lasciar fare il rendering ad un software di rendering, non trovi? Ciao! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Provincia di Aosta
Nell'aggiungere alcuni tag wikipedia, mi sono accorto che la provincia di Aosta è inclusa[1] nei dati OSM, seppure sia stata soppressa[2] nell'immediato dopoguerra. Che facciamo? La teniamo comunque, considerando che è prassi includerla negli elenchi delle province (targa automobilistica: AO) e che prima o poi (si spera) tutte quante le province italiane saranno soppresse dal punto di vista amministrativo? Ciao! Carlo [1] http://www.openstreetmap.org/browse/relation/45154 [2] http://it.wikipedia.org/wiki/Provincia_di_Aosta [3] http://it.wikipedia.org/wiki/Province_d%27Italia -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Fwd: [Tagging] Voting : Isolated buildings in mountain/wild used by hikers(/...) for shelter/sleeping/eating
Sapendo che non pochi di voi si occupanno anche di alpinismo, vi segnalo queste modifiche del wiki: Martin Da: sly (sylvain letuffe) li...@letuffe.org Data: 20. April 2012 16:31 Ogg: [Tagging] Voting : Isolated buildings in mountain/wild used by hikers(/...) for shelter/sleeping/eating A: tagg...@openstreetmap.org Hi, After the huge clean up, improve and re-wording by rudof (thanks rudolf) the 4 proposals are open for a vote at : http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Alpine_hut http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Wilderness_hut http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Basic_hut http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Lean_to The grouping page is here : http://wiki.openstreetmap.org/wiki/Proposed_features/wilderness_mountain_buildings Please use the talk page for generic comments on all 4 proposal here : http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/wilderness_mountain_buildings Or use one of the 4 specific proposal pages if you want to comment on one specific tag -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Non ho ben capito il caso specifico, ma ci sono 2 possibilità: a) esiste la provincia di Aosta allora ci deve essere un'oggetto che la rappresenta in OSM b) non esiste (più) allora non ci deve essere. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Immagino che il confine sia unico, essendo una regione, dovrebbe avere l'admin_level 4 invece che 6 :) Il giorno 20 aprile 2012 17:36, Martin Koppenhoefer dieterdre...@gmail.comha scritto: Non ho ben capito il caso specifico, ma ci sono 2 possibilità: a) esiste la provincia di Aosta allora ci deve essere un'oggetto che la rappresenta in OSM b) non esiste (più) allora non ci deve essere. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Re : La mappa OSM di Wikipedia si migliora
In fatto, c'è anche un plugin che si chiama Wikipedia in JOSM. Funziona con le coordinate GPS che sono nella Wikipedia. Dobbiamo selezionare un oggetto (relazione, node o poligono), cliccare sul buono titolo dato con il plugin e cliccare su « add tag » Florian Farge aka Otourly Sur lesprojets wikimédiens et l'Association française,OSM, et sur MOVIM Socio di Wikimedia Italia De : Carlo Stemberger carlo.stember...@gmail.com À : openstreetmap list - italiano talk-it@openstreetmap.org Envoyé le : Vendredi 20 avril 2012 16h42 Objet : Re: [Talk-it] La mappa OSM di Wikipedia si migliora Il 19/04/2012 13:34, Federico Cozzi ha scritto: 2012/4/19 Carlo Stembergercarlo.stember...@gmail.com: Ottimo! Un motivo in più per usare il tag wikipedia :-) Io non ho ben capito cosa bisogna fare per far evidenziare in rosso le aree, come per Lione[1]. Ho appena provato a mettere il tag wikipedia sulla relazione del comune di Milano, chissà se funziona? Funziona :) Davvero fantastico, non vedo l'ora che arrivi anche nella Wikipedia italiana. Ciao! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Il 20/04/2012 17:39, sabas88 ha scritto: Immagino che il confine sia unico, essendo una regione, dovrebbe avere l'admin_level 4 invece che 6 :) La relazione per la regione (Valle d'Aosta) esiste già: Quindi voi sareste per l'eliminazione della provincia, se ho ben capito. Il fatto che non esista come ente amministrativo, ma che esista per altri usi pratici (targhe delle auto, ad esempio), non ha alcuna rilevanza? Ciao! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] La mappa OSM di Wikipedia si migliora
2012/4/20 Carlo Stemberger carlo.stember...@gmail.com Funziona :) Davvero fantastico, non vedo l'ora che arrivi anche nella Wikipedia italiana. Se non mi sbaglio, già funziona! ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Il 20/04/2012 18:08, Carlo Stemberger ha scritto: Il 20/04/2012 17:39, sabas88 ha scritto: Immagino che il confine sia unico, essendo una regione, dovrebbe avere l'admin_level 4 invece che 6 :) La relazione per la regione (Valle d'Aosta) esiste già: Quindi voi sareste per l'eliminazione della provincia, se ho ben capito. Il fatto che non esista come ente amministrativo, ma che esista per altri usi pratici (targhe delle auto, ad esempio), non ha alcuna rilevanza? Beh... io ho caricato i confini del Piemonte, da quelle parti, ma non mi ero posto il problema se esistesse o meno la provincia di Aosta. Attualmente ci sono due relazioni identiche provincia e regione. Francamente direi che quel che fa fede è lo status legale. Se l'ente provincia di Aosta non esiste, non deve esistere nemmeno una relazione che lo rappresenti. Le targhe automobilistiche Ao si riferiranno evidentemente alla Valle d'Aosta come regione autonoma. -- Maurizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Am 20. April 2012 18:08 schrieb Carlo Stemberger carlo.stember...@gmail.com: Il 20/04/2012 17:39, sabas88 ha scritto: Quindi voi sareste per l'eliminazione della provincia, se ho ben capito. no, non necessariamente, sarei per l'eliminazione del tag admin_level=6 se non c'è una provincia. Il fatto che non esista come ente amministrativo, ma che esista per altri usi pratici (targhe delle auto, ad esempio), non ha alcuna rilevanza? Mi basterebbe già il fatto che esiste un tag con link ad un articolo di wikipedia per tenere l'oggetto. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] La mappa OSM di Wikipedia si migliora
Il 20/04/2012 18:30, Tiziano D'Angelo ha scritto: Se non mi sbaglio, già funziona! No; clicca su Mappa[1] e su Karte[2] e ti accorgerai della differenza. Ciao! Carlo [1] http://it.wikipedia.org/wiki/Milano [2] http://de.wikipedia.org/wiki/Mailand -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Il 20/04/2012 18:35, Martin Koppenhoefer ha scritto: Mi basterebbe già il fatto che esiste un tag con link ad un articolo di wikipedia per tenere l'oggetto. È in quest'elenco: http://it.wikipedia.org/wiki/Province_d%27Italia#Elenco_delle_province (però il link porta alla voce della regione) Ciao! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Re : La mappa OSM di Wikipedia si migliora
Il 20/04/2012 17:41, Otourly Wiki ha scritto: In fatto, c'è anche un plugin che si chiama Wikipedia in JOSM. Segnalo che serve una versione recente di JOSM: con la 5047 ottenevo Non è possibile caricare il plugin wikipedia. Cancellarlo dalle preferenze?, mentre con la 5181 tutto ok. Grazie ancora per le preziose segnalazioni! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
2012/4/20 Martin Koppenhoefer dieterdre...@gmail.com: no, non necessariamente, sarei per l'eliminazione del tag admin_level=6 se non c'è una provincia. In pratica abbiamo due relazioni con lo stesso perimetro, una delle due ha admin_level=4 e l'altra admin_level=6? La relazione della Provincia (che non esiste) quali informazioni dà in più rispetto alla relazione della Regione? Io sarei per eliminare la relazione della provincia. Il fatto che esista un articolo su Wikipedia non vuol dire che dobbiamo mantenere la relazione su OSM, perché si tratta di una provincia soppressa: per lo stesso motivo non terrei le relazioni corrispondenti ad altre province o comuni soppressi (es. http://it.wikipedia.org/wiki/Terra_di_Lavoro) Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Il 20/04/2012 19:08, Federico Cozzi ha scritto: 2012/4/20 Martin Koppenhoeferdieterdre...@gmail.com: no, non necessariamente, sarei per l'eliminazione del tag admin_level=6 se non c'è una provincia. In pratica abbiamo due relazioni con lo stesso perimetro, una delle due ha admin_level=4 e l'altra admin_level=6? Esatto. Io sarei per eliminare la relazione della provincia. Ok, allora ci aspetta un bel lavorone, dato che oltre che oltre a cancellare la relazione si deve anche intervenire su ogni way che la compone per eliminarne i riferimenti (province:left/province:right). Ciao! -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Am 20. April 2012 19:08 schrieb Federico Cozzi f.co...@gmail.com: 2012/4/20 Martin Koppenhoefer dieterdre...@gmail.com: no, non necessariamente, sarei per l'eliminazione del tag admin_level=6 se non c'è una provincia. In pratica abbiamo due relazioni con lo stesso perimetro, una delle due ha admin_level=4 e l'altra admin_level=6? La relazione della Provincia (che non esiste) quali informazioni dà in più rispetto alla relazione della Regione? diciamo che congela il perimetro della provincia sopressa anche se cambia quello della regione. Sono d'accordo che non ci deve essere una provincia (admin_level=6) che non c'è più, però se quel perimetro è quello della provincia nel 1945 e c'é un articolo Wikipedia linkato su questo perimetro non lo toglierei. Va aggiustato il tagging, quello è ovvio. Il fatto che esista un articolo su Wikipedia non vuol dire che dobbiamo mantenere la relazione su OSM, è un caso un po' ambiguo, sono d'accordo, però sono includista e quindi nel dubbio terrei l'informazione invece di toglierla. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Il 20/04/2012 20:01, Martin Koppenhoefer ha scritto: se quel perimetro è quello della provincia nel 1945 e c'é un articolo Wikipedia linkato su questo perimetro non lo toglierei. Va aggiustato il tagging, quello è ovvio. Il link l'ho aggiunto io questo pomeriggio, prima di accorgermi che la provincia in effetti non esiste più. Non sono neppure certo che la vecchia provincia avesse lo stesso confine dell'attuale regione; anzi, ho parecchi dubbi a riguardo. -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Il 04/20/2012 05:36 PM, Martin Koppenhoefer scrisse: b) non esiste (più) allora non ci deve essere. In linea di principio sono d'accordo con te. In pratica pero' non vorrei che si venisse a creare una di quelle situazioni che solo noi italiani sappiamo inventarci. Ad esempio se parte del territorio non e' piu' coperto da una provincia e si esegue una query per estrarre le province, il risultato sara' un'Italia coi buchi. Penso ad esempio a programmi esistenti o fatti da chi non conosce questi casi particolari. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Provincia di Aosta
Ho appena eliminato la provincia: http://www.openstreetmap.org/browse/changeset/11367902 Ciao! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-dk] cycleway=track, cycleway:left=none VS cycleway:right=track
Hej. Jeg har set at det er vanligt at tagge delte veje med denne: highway=*, oneway=yes, cycleway=track, cycleway:left=none, selvom det på wikien anbefales at der tagges med highway=*, oneway=yes, cycleway:right=track. Jeg antager at anledningen til dette er at den ellers ikke vises som en lilla-stiplet linje i JOSM men jeg er ikke sikker. Kan det vare så at det fortrinsvis tagges på førstnævnte måde når der findes mulighed at bruge en track i begge vejens retninger (da dens geometri jo enlig bare er splittet) sammenlignet med når det kun findes mulighed i én retning? Det ville give mening i så fald. Med venlig hilsen Hedda Nilsson Orviste Studentermedhjælper Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Postboks 450 2300 København S Email z...@tmf.kk.dk mailto:z...@tmf.kk.dk Fra: Kristian Krægpøth [mailto:k.kragp...@gmail.com] Sendt: 13. april 2012 23:01 Til: talk-dk@openstreetmap.org Emne: Re: [Talk-dk] At printe et kort Hej Peter Jeg tror ikke det er så himmelråbende åndssvagt et spørgsmål - jeg kan i hvert fald ikke finde ud af det. Jeg kan tegne et kort ud direkte fra OSM, men det er ikke lykkedes mig at tegne det ud med signaturer for fx vindmøller og kirker uafhængig af målestoksforhold. Ligesom jeg ikke kan styre skriftstørrelse af navne på bebyggelser. Det ville være rigtig herligt hvis nogen med kendskab til emnet kunne forklare en IT-idiot som mig, hvordan man gør. Og det prøver du, Leif, på - tak for det. Problemet er, at jeg ikke ved, hvad det betyder at eksportere til SVG og importere i Inkscape. Og hvad er tiles? Se det ved jeg godt er himmelråbende uvidende - men jeg vil meget gerne gøres klogere. Hvilke sider, hvilke taster? Så basal er min uvidenhed. Jeg håber engang at kunne udprinte kort til at cykle og gå efter. Fx i en kvalitet som http://www.haervej.dk/danmark/da-dk/menu/haervejen/kort/detailkort-haervejen/detailkort-med-sevaerdigheder-langs-haervejen.htm viser. Venlig hilsen Kristian Krægpøth ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-se] Rädda lite orter i påskhelgen
Nu ser Sverige ganska bra ut, för att inte säga mycket bra om man jämför med Europa i övrigt! Tycks som mycket av t.ex. Venedig kommer försvinna... lite konstigt detta med licensbytet kan jag tycka! Men det kommer finnas mycket att kartlägga efter att det rensats på icke godkända noder/vägar m.m. och de finns ju de som tycker att det är roligt att rita av Bings bilder, som jag till exempel... Mvh Henrik R Den 10 april 2012 12:18 skrev Odd Gustafsson odd_lars...@hotmail.com: Hej Bengt, Vad bra att du anmäler dig! Det är lite i elfte timmen, men allt som hinns med är ju bonus! (Jag har inte själv vart nationellt aktiv förrens nu) Jag ger gärna en beskrivning på vad vi gör. Man kan kalla det en kontrollerad borttagning av objekt som är skapade/förädlade av personer som ej svarat/nekat till licensbytet. Sedan finns det i många sammanhang goda möjligheter att återskapa samma objekt med hjälp av t ex Bing. Så översiktligt går jag tillväga så här: - Letar upp en väg som är skapad av någon som nekat till licensbytet - Ser vad andra (som *har* accepterat licensbytet) lagt till för information, kopierar det. - Tar bort objektet - Ritar om det efter Bing. - Klistrar in den kopierade informationen. Om nekaren har modifierat en väg letar jag upp eventuell nod/noder och tar bort dem och ev fixar till efter Bing Jag rekommenderar *starkt* att man installerar licenschange-plugin:et (om man nu jobbar i JOSM) Om du önskar få en mer detaljerad beskrivning hur man gör i JOSM så säg till! /Odd Date: Tue, 10 Apr 2012 11:27:56 +0200 From: be...@baverman.se Hejsan Jag tycker att det är väldigt bra jobbat och skulle vilja hjälpa till genom att kolla mitt närområde och kanske mer i större cirklar... Jag efterlyser dock en kortare beskrivning av vad ni gör. Hur ser arbetsflödet ut? Jag har inte hängt med i detaljerna tidigare eftersom jag tycker att hela detta med licensändringen är lite olustig och dåligt skött centralt ifrån. Förhoppningsvis kan en sådan beskrivning hjälpa fler att bli mer aktiva. vänligen Bengt Bäverman ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Rädda lite orter i påskhelgen
Jepp, lossnade rätt många tiondels procent över Påsken: http://odbl.poole.ch/ Har städat upp lite runt Haninge nu så motorvägarna och de flesta större vägar kommer att överleva utan hål eller annat skumt. Finns däremot mycket mikrokartläggande kvar att göra. Märkte också att Bing är rätt gammalt samt lite snett utanför centrum där i trakten så det får man se upp med. Gillar man att sitta hemma och rita av Bing så finns det massvis med områden som kunde få sig en genomgång. Speciellt sådana ställen som precis fått nya flygbilder som bara är något år gamla. Brukar själv piffa till cykelinfrastrukturen på de ställen jag fixar licensproblem då jag främst använder OSM vid cykling. :) /Joakim On 20 apr 2012, at 09:16, Henrik Rosvall wrote: Nu ser Sverige ganska bra ut, för att inte säga mycket bra om man jämför med Europa i övrigt! Tycks som mycket av t.ex. Venedig kommer försvinna... lite konstigt detta med licensbytet kan jag tycka! Men det kommer finnas mycket att kartlägga efter att det rensats på icke godkända noder/vägar m.m. och de finns ju de som tycker att det är roligt att rita av Bings bilder, som jag till exempel... Mvh Henrik R Den 10 april 2012 12:18 skrev Odd Gustafsson odd_lars...@hotmail.com: Hej Bengt, Vad bra att du anmäler dig! Det är lite i elfte timmen, men allt som hinns med är ju bonus! (Jag har inte själv vart nationellt aktiv förrens nu) Jag ger gärna en beskrivning på vad vi gör. Man kan kalla det en kontrollerad borttagning av objekt som är skapade/förädlade av personer som ej svarat/nekat till licensbytet. Sedan finns det i många sammanhang goda möjligheter att återskapa samma objekt med hjälp av t ex Bing. Så översiktligt går jag tillväga så här: - Letar upp en väg som är skapad av någon som nekat till licensbytet - Ser vad andra (som *har* accepterat licensbytet) lagt till för information, kopierar det. - Tar bort objektet - Ritar om det efter Bing. - Klistrar in den kopierade informationen. Om nekaren har modifierat en väg letar jag upp eventuell nod/noder och tar bort dem och ev fixar till efter Bing Jag rekommenderar *starkt* att man installerar licenschange-plugin:et (om man nu jobbar i JOSM) Om du önskar få en mer detaljerad beskrivning hur man gör i JOSM så säg till! /Odd Date: Tue, 10 Apr 2012 11:27:56 +0200 From: be...@baverman.se Hejsan Jag tycker att det är väldigt bra jobbat och skulle vilja hjälpa till genom att kolla mitt närområde och kanske mer i större cirklar... Jag efterlyser dock en kortare beskrivning av vad ni gör. Hur ser arbetsflödet ut? Jag har inte hängt med i detaljerna tidigare eftersom jag tycker att hela detta med licensändringen är lite olustig och dåligt skött centralt ifrån. Förhoppningsvis kan en sådan beskrivning hjälpa fler att bli mer aktiva. vänligen Bengt Bäverman ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se
[Talk-es] [CATASTRO] Cat2Osm nueva versión.
Hola a todos. Perdón por estar desaparecidos pero es que estas semanas tengo que redactar la memoria de mi proyecto y estamos hasta arriba. Hemos subido una nueva versión de Cat2Osm con unos pequeños arreglos: Mueve mejor los nodos de portales a sus parcelas. Mejora el cálculo de los usos y destinos cogiendo primero el destino con mayor área (porque son más específicos que los usos) y si no hay destinos entonces pasa a los usos. Redondea los últimos decimales de las coordenadas de los nodos para así evitar nodos superpuestos. Arreglos de pequeños detalles. PD: Murcia está a falta de 2 días de terminar y Zaragoza le quedan 800 horas para terminar (después de haber estado 2 semanas y pico). Saludos. -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: ander.pij...@deusto.es Móvil: +34 664471228 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Cat2Osm nueva versión.
¿Dónde la habéis subido? En https://github.com/AnderPijoan/cat2osm sigue estando la versión anterior. El 20/04/12 13:37, Ander Pijoan escribió: Hola a todos. Perdón por estar desaparecidos pero es que estas semanas tengo que redactar la memoria de mi proyecto y estamos hasta arriba. Hemos subido una nueva versión de Cat2Osm con unos pequeños arreglos: Mueve mejor los nodos de portales a sus parcelas. Mejora el cálculo de los usos y destinos cogiendo primero el destino con mayor área (porque son más específicos que los usos) y si no hay destinos entonces pasa a los usos. Redondea los últimos decimales de las coordenadas de los nodos para así evitar nodos superpuestos. Arreglos de pequeños detalles. PD: Murcia está a falta de 2 días de terminar y Zaragoza le quedan 800 horas para terminar (después de haber estado 2 semanas y pico). Saludos. -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: ander.pij...@deusto.es mailto:ander.pij...@deusto.es Móvil: +34 664471228 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale LibreOffice desde http://es.libreoffice.org/descarga/ LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] OGD - Haltestellen - WMS
Am 13.04.2012 18:06, schrieb Kelvan: Danke, offenbar sind aber die Daten nicht so toll. War aber irgendwie zu erwarten :( mfg, Florian ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at Da kann ich dir zum Glück (jetzt) widersprechen! Die Daten sind nahezu deckungsgleich mit unseren (dort wo die Haltestellen schon vorhanden sind). 1) von hier die *.KML holen: http://data.wien.gv.at/katalog/haltestellen.html 2) Methode I) a) mit GPSBabel in ein JOSM lesbares Format ändern, dann kann man in der note auch den echten Namen finden b) die z.b. *.xml öffnen Methode II) a) Plug-In opendata installieren b) die *.kml öffnen, nur leider steht dann in der note nicht der Haltestellenname 3) das Wiener Netz ergänzen LG, Jimmy ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Frage zum Zeichnen von Gebäuden mit mehreren Gebäudeteilen
Hallo, ich möchte ein Gebäude zeichnen, das aus drei Gebäudeteilen besteht – zwei davon haben 6 Stockwerke (das andere ist deutlich niedriger), diese beiden unterscheiden sich aber in Bezug auf addr:unit (also die Stiege). Wie auch immer, die Gebäudeteile grenzen jedenfalls unmittelbar aneinander. Ich zeichne also einen Weg rund um jedes Gebäudeteil und bezeichne es mit building:part=yes und dann (1. Möglichkeit) einen Weg um alle Teile herum (=Gebäudeumriss) mit dem Tag building=apartments oder (2. Möglichkeit) ich füge alle drei Teile zu einer Relation hinzu, die dann das entsprechende Tag building=apartments bekommt. Ich hab jetzt zig Male die unterschiedlichen Wiki-Seiten gelesen und denke, dass beide Vorgehensweisen eigentlich OK sein sollten. Aber JOSM gibt mir eine Warnung aus: Überlappende Linien – und zwar dort, wo die Gebäudeteile aneinandergrenzen. Nachdem ich einige Zeit herumprobiert habe bin ich auf die Idee gekommen, dass es sein könnte dass JOSM Gebäudeteile (building:part=yes) nicht als Flächen interpretiert (dieses Tag also nicht area=yes mitmeint) – und tatsächlich, wenn ich die Gebäudeteile als areas definiere, dann krieg ich die Fehlermeldung/Warnung nicht. Meine Frage: Ist das ein Bug (der bereits gemeldet ist oder den man melden sollte), ein Feature (weswegen ich die Warnung einfach ignorieren sollte) oder mach ich was grundsätzlich falsch? Danke im Voraus liebe Grüße, Stefan. -- E-Mails signieren verschlüsseln: - https://secure.wikimedia.org/wikipedia/de/wiki/Datenschutz - https://secure.wikimedia.org/wikipedia/de/wiki/E-Mail#Vergleich_mit_der_Postkarte - https://secure.wikimedia.org/wikipedia/de/wiki/GNU_Privacy_Guard Mein öffentlicher OpenPGP-Schlüssel: - http://stefan-nagy.at/public-key.asc signature.asc Description: This is a digitally signed message part ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Biwakschachteln
Derzeit laufen mehrere Votings, u.a. folgendes: http://wiki.openstreetmap.org/wiki/Proposed_features/Basic_hut Da geht es sowohl um das, was in der englischen Wikipedia bothy genannt wird, als auch um Biwakschachteln. Ich hatte mit solchen noch nichts zu tun, aber einige von euch sind ja im Hochgebirge unterwegs, also wird euch das Voting wahrscheinlch interessieren. Ihr habt dabei eine besondere Verantwortung, denn Biwakschachteln sind anscheinend eine alpine Spezialität. Ich finde nicht mal eine englische Übersetzung dafür. Bisher wird man Biwakschachteln wahrscheinlich mit amenity=shelter getaggt haben. Aber man kann argumentieren, dass ein Bothy im Grunde das gleiche ist und sich nur im building=* unterscheidet. Das Proposal geht faktisch dahin, dass amenity=shelter genutzt wird, bis das Unwetter vorbei ist, während tourism=basic_hut/chalet/guesthouse/hotel/hostel/motel/camp_site in erster Linie Schlafplätze für die Nacht sind. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
