Re: [Talk-transit] [Talk-gb-westmidlands] NaPTAN and the new PTtagging schema
Peter Miller wrote: Sent: 26 June 2009 6:24 PM To: Andy Robinson (blackadder-lists) Cc: 'Thomas Wood'; talk-gb-westmidla...@openstreetmap.org; talk- tran...@openstreetmap.org Subject: Re: [Talk-gb-westmidlands] [Talk-transit] NaPTAN and the new PTtagging schema On 26 Jun 2009, at 17:51, Andy Robinson (blackadder-lists) wrote: Peter Miller wrote: Sent: 26 June 2009 4:41 PM To: Thomas Wood Cc: talk-gb-westmidla...@openstreetmap.org; talk- tran...@openstreetmap.org Subject: Re: [Talk-gb-westmidlands] [Talk-transit] NaPTAN and the new PTtagging schema Your suggestions below make a lot of sense. I would however very much encourage you to include customary stops because they do indeed 'exist' even though there is no physical pole. Consider a road that doesn't have a name plate but when you people who live on the street what it is called they tell you. Does the street have a name or does it not - I suggest we would agree that it does? If a tree falls in a wood and there is no one to hear it did it make a sound etc. Customary stops can be confirmed by looking for physical marks of vehicles stopping or people standing around on the grass, from information at the stop opposite or from asking bus drivers. I would suggest that for now we believe NaPTAN. These are easy to add in a final cleanup anyway, just by usage of the route. The problem with the NaPTan data is that there are loads of stops that are probably just not used at all, hence we leave them turned off (silent data). I agree that we could and probably should import customary stops but I don't think we should assume they are actual in-use stops and hence should leave them silent in the database until someone confirms and adds highway=bus_stop For other areas of the country I think its fine (with the exception of CUS stops) to go ahead straight away and add the highway=bus_stop where there are few existing mapped stops. Ideally a post to the local uses in the area would confirm either way what they would like to do. You seem to be putting out different messages in the two above paragraphs. Are you saying you support the import of CUS stops or not. Also are you suggesting that bus stops are set as 'real' (ie active) stops. Yes, lets import them but not with the highway=bus_stop on them. Then OSMers can switch them on if they are in use or leave/delete them as they see fit. Possibly Roger will have some views on how many unused stops there are likely to be in the dataset. Looking at the Oct08 dataset there were 365,000 bus stops and 42,020 of them were unused at the time however this doesn't necessarily mean that they don't exist, only that no buses currently use them - in some cases they could be stops for summer-only services. I suggest that we should include all bus stops in the dataset regardless of use. We should removed stops that don't physically exist if there is no sign of them on the ground. Customary stops might need a visit to the friendly local bus operator who probably has all the information in his head. Physically marked stops can be checked by cruising the bus routes. Beyond that the only bit of data I dislike from the original run is the unverified=yes tag. It would be better to change this to verified=no for future imports (and easy to swap in West Mids.) sounds good Otherwise my experience in Brum is generally good in that with the exception of location (which is 10m to 100m off at least 50% of the time) the NaPTAN data matches the data on the ground very well. The accuracy will vary across the county and will reflect the care taken by each authority. I would expect it to be better in most places but might be proved wrong! Having a map that shows the bus stops would seem to be a good step to getting it improved by doing a physical survey or asking bus drivers to comment. If the data is hidden in the maps and not exposed it will be harder to sort out. I vote for having the data introduced as fully visisbly data but possibly we do it county by county. I am happy to be an early recipient of data for Suffolk and I think Ed Loach is keen to see the Essex data. Agreed, but the decision needs to come from the community on the ground, just as we have done with the West Midlands. Cheers Andy Regards, Peter I know Brian and others have documented a few oddities here: http://wiki.openstreetmap.org/wiki/NaPTAN_Error_Log Cheers Andy Traveline would strongly advocate for their inclusion so that OSM links seamlessly to their journey planners. Regards, Peter On 26 Jun 2009, at 16:21, Thomas Wood wrote: 2009/6/24 Peter Miller peter.mil...@itoworld.com: On 24 Jun 2009, at 18:20, Thomas Wood wrote: 2009/6/24 Peter Miller peter.mil...@itoworld.com: Can I suggest that we treat this import and any final tagging as a separate issue on separate timeline from the NaPTAN import just so long as no important information in the NaPTAN DB is lost in the
Re: [talk-ph] invitation by bmw club
On 6/18/09, maning sambale emmanuel.samb...@gmail.com wrote: I just got an invitation for a breakfast meeting with the bmw club. They are interested in our project mostly for gps navigation. They want to know more about OSM-PH especially how to use garmin nuvis and mapsource and other osm tools. If anybody wants to join (I can probably insist to bring along 2 OSMers) and help me share OSM love to these guys, let me know. It will be this sunday 9AM at the fort. (btw, it's fathers day) -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- hi, Yesterday was our talk with bmw car club about OSM (the pronounced it as awesome!) and GPS. Thanks to Rally and Eugene for joining and sharing their experiences. Here's what they have to say about us: http://www.bmwcarclub.org.ph/forum/showthread.php?p=20677#post20677 See post 38 onwards -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-legal-talk] Privacy and Terms
On 29 Jun 2009, at 17:11, SteveC wrote: On 26 Jun 2009, at 14:57, Peter Miller wrote: On 24 Jun 2009, at 06:56, SteveC wrote: Dear all One of the things that's resulted from getting help with the license process is that it's been noticed we don't have a lot of the legal furniture, and thus protection and clarity, found frequently elsewhere. We've been offered some fairly standard privacy and terms of use policies: http://wiki.openstreetmap.org/wiki/Privacy_Policy_- _Discussion_Draft http://wiki.openstreetmap.org/wiki/Terms_of_Use_-_Discussion_Draft We've put them up for your input as step 1. These aren't even recommended by us just yet, but to start a discussion on anything that may be bad (or maybe good - that would be novel!) with them? Thanks for that Steve. Lots to think about there, but it is certainly good to start with something standard and then see what needs changing. I fully support the process of adding a clear legal framework to the project but the terms and conditions and license can't be considered in isolation without looking at the Articles of Association at the same time. Andy asked for interest from people to work on the Articles of Association but I have not heard more about it and there is nothing on the foundation website. Is there a working group for this? Who is on it? Is it publishing minutes? Are there any proposed changes available for comment? Andy? oh I see he replied My concern here is to try to avoid creating an interesting target for 'carpet baggers' who may wish to 'privatise' OSM in the way that the mutual building societies were privatised in the past ten years in the UK. http://en.wikipedia.org/wiki/Carpet_baggers#United_Kingdom I suggest that we need to infuse all the legal arrangements with efforts to: 1) Avoid the OSMF being valuable as a 'take over' target with a potential financial value on the open market. Both the articles and the terms and conditions should help with this. I agree and, well, the key thing is that the OSMF doesn't own the data, and even if it were the licenser it can't just randomly privatise the data like CDDB right? And if not, then what is there that would give it value? 2) To protect the OSMF from hostile actions by excluding opportunities of financial reward to any parties (members, directors or contributors). Both the terms and conditions and articles should help with this. Regards, Peter Miller Best Steve ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk Best Steve ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk Best Steve ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Potted plants vs. garden beds
I think that the proposed tagging is incomplete I suggest to add: plant_type= orange_tree living=yes/no/plastic soil_type= ordinary_ground / water culture barrier_type=decorated_wood or washed out concrete color = dark_green or gray water_state= needs water / sufficiently watered / dryed out Gert Gremmen - Openstreetmap.nl (alias: cetest) Before printing, think about the environment. -Oorspronkelijk bericht- Van: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] Namens Iván Sánchez Ortega Verzonden: Saturday, June 27, 2009 11:40 PM Aan: talk@openstreetmap.org CC: Jorge L. Batista E Onderwerp: [OSM-talk] Potted plants vs. garden beds Hi all, In the talk-es list, a question has been raised about these things: http://www.flickr.com/photos/8171...@n04/3665245829/ http://www.flickr.com/photos/8171...@n04/3665221611/ http://www.flickr.com/photos/8171...@n04/3665245839/ Question is, would you call those ... a) barrier=potted_plant b) barrier=garden_bed c) Some other stuff Cheers, -- -- Iván Sánchez Ortega i...@sanchezortega.es - No por vivir la vida al limite eres ningún bicho raro. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thousands of small changesets by Tim Proegler
Has anyone contacted this user to ask about the source, and to discuss improvements to this import process? -Mikel From: Christoph Böhme christ...@b3e.net To: Thomas Wood grand.edgemas...@gmail.com Cc: S Knox roxyk...@yahoo.co.uk; talk@openstreetmap.org; Shaun McDonald sh...@shaunmcdonald.me.uk Sent: Wednesday, June 24, 2009 11:00:55 AM Subject: Re: [OSM-talk] Thousands of small changesets by Tim Proegler Thomas Wood grand.edgemas...@gmail.com schrieb: Can we ban it, the stuff its uploading is completely useless. (single nodes with only note tags and no other useful metadata) All the nodes I have looked at are for german petrol stations. The script does not seem to check if the station has already been mapped and only setting the note tag is really not much help in sorting this out later. I am also wondering were the data is coming from. 1753 petrol stations covering an area of 5x5 degrees are quite a lot, I think. Christoph 2009/6/24 Shaun McDonald sh...@shaunmcdonald.me.uk: http://www.mchme.com/#openstreetmap looks like the software they've used. 1753 changesets in less than 20 minutes. Shaun On 24 Jun 2009, at 17:58, S Knox wrote: Does anyone know why Tim Proegler http://www.openstreetmap.org/user/timproegler/edits has made so many small edits under the name of KMLManager in such a short space of time (1 day as a member)? The recent changes page was at one point full of his changesets. Is this legitimate, or a mistake? Regards Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ 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] Hall of Fame - Streets completed
Hi and hello from Germany! If you know some german, you might understand the joke: Essen ist fertig! (*) As Essen just declared to be completed in OSM I introduced a new Wiki Page: http://wiki.openstreetmap.org/wiki/Hall_of_Fame/Streets_complete If you know an area which has all its streets in OSM (and this is somehow documented) feel free to add an entry. Also feel free to give the page a nicer format :-) Best Greetings! Rotbarsch (Essen, Germany) (*) As Essen means also meal in german, this (Lunch/Dinner is ready) is what many children hear every day and which disturbs them doing much more important things than eating... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potted plants vs. garden beds
2009/6/29 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: I think that the proposed tagging is incomplete I suggest to add: plant_type= orange_tree +1 living=yes/no/plastic +1 soil_type= ordinary_ground / water culture why not barrier_type=decorated_wood or washed out concrete ? could be barrier:material color = dark_green or gray -1 water_state= needs water / sufficiently watered / dryed out -1 I guess your contribution had ironical intentions, but it still contains some valueable thoughts ;-) Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potted plants vs. garden beds
Rather than plant_type=orange_tree or similar, I think it would make more sense
to tag plants and trees with the scientific (Latin) name of their species or
hybrid. These are already standardized and the local language translations
('citrus x sinensis' = 'en:orange', 'es:naranja') are also standard, and can be
looked up by the map renderer rather than duplicated for every orange tree on
the
map.
I don't expect individual plants will be tagged very often (even the Germans
have
not added the 'unter den' linden trees) but for managed forests and perhaps
farmland it might be useful.
Further, following the OSM guidelines on verifiability, instead of making new
classification rules for tree / bush / shrub / whatever, just tag the size of
the plant in metres.
Of course this doesn't cover the tagging of pots; as far as I am aware there is
no existing categorization for those :-p.
--
Ed Avis e...@waniasset.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Dolomiti Mapping Party
Hi, I wish to announce that OSM mappers from Trentino Alto Adige are organizing a MP up in the Dolomites Great work to advance the map has been put everywhere, but specially to mountain tracks, like here: http://osm.org/go/0c...@g Please come and join us up in the wonderful mountainous region of Italy. The Mapping Party will be held on 1-2 august 2009. Overnight sleeping can be arranged and might as well be in an alpine hut. http://wiki.openstreetmap.org/wiki/Dolomiti_mapping_party -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Ingewikkeld?
Hallo allemaal, hoe ingewikkeld is het om: - Zelf een tile-server in elkaar te sleutelen - Extra relaties op te nemen bij het renderen - Javascript te maken om een POI op de kaart te laten zien Heeft er iemand toevallig een voorbeeld van bovenstaand 'liggen'? Groeten! Christ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Ingewikkeld?
On Mon, 29 Jun 2009, Christ van Willegen wrote: hoe ingewikkeld is het om: - Zelf een tile-server in elkaar te sleutelen Zie wiki. - Extra relaties op te nemen bij het renderen Zie wiki. - Javascript te maken om een POI op de kaart te laten zien http://devnext.openstreetmap.nl/rubke/ Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Google Summer of Code 2009 - signFinder.
Hallo Iedereen, Aan de late kant, maar laat ik me even introduceren: Ik ben Tijs Zwinkels, ik heb zojuist mijn kunstmatige intelligentie opleiding afgerond, en sinds een week of vijf ben ik onder de vlag van de google summer of codehttp://code.google.com/soc/bezig met een projecthttp://wiki.openstreetmap.org/wiki/GSoC_Student_Applications_2009#Draft_application:_Automatic_Street-Sign_Detection_and_Readingom automatisch Nederlandse straatnaamborden te detecteren, segmenteren, en hopenlijk ook te lezen. Stefan is mijn mentor voor dit project. Klinkt interessant? Vond ik ook. :) - kijk vooral ook even op het opengeo blog http://blog.opengeo.nl/index.php/2009/06/29/signfinder/ voor wat meer tekst, uitleg, en plaatjes. Ik zal vanaf heden proberen jullie als 'de community' wat regelmatiger op de hoogte te houden. De huidige methodiek werkt in een aantal gevallen vrij goed, met in meer van 80% van de gevallen de straatnaamborden op plaatjes perfect gesegmenteerd in mijn eigen testsethttp://mirror.openstreetmap.nl/openstreetphoto/tijs/results/210609/test1/. Probleem is dat mijn eigen trainset nagenoeg uitsluitend in een nieuwbouwwijk, met mooie shiny nieuwe blauwe straatnaamborden opgenomen is. Bij 'minder mooie' borden en andere camera's wordt de performance snel slechter. Ik ben zelf al bezig geweest met nieuwe data verzamelen, maar: Ik ben voorlopig nog wanhopig opzoek naar nieuwe data om op te trainen of te testen. Heeft iemand nog een set met foto's van straatnaamborden voor mapping purposes liggen? Voornaamste eis is dat het straatnaambord groot in beeld is (minimaal 1/400e van de totale oppervlakte van de foto), de foto van voldoende kwaliteit is, en dat het straatnaambord leesbaar is. Iemand die me kan helpen? Mocht je het leuk vinden om met het huidige product te spelen, de code staat online op http://code.google.com/p/signfinder/ . Het ding draait op linux, en heeft de opencv library nodig. Ik zal vanmiddag betere documentatie toevoegen, maar de werking is simpel: de signFinder-executable accepteerd een of meerdere jpg-foto's op de command line. Hij probeert hier straatnaamborden op de te vinden (remember, groot genoeg in beeld..), en schrijft een bestand met de naam filename_result.jpg weg waarin hij een lijntje om de gevonden borden heen tekent. - Tijs ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Google Summer of Code 2009 - signFinder.
Hoi Tijs, Ik heb waarschijnlijk nog wel wat bruikbare foto's. Waar zou ik die kwijt kunnen? Veelbelovende resultaten tot nu toe, maar de laatste stap, het lezen van de straatnamen uit de gedetecteerde borden, is uiteraard een cruciale om de post-processing van ruwe data (tracks + foto's) te helpen automatiseren. Heb je hier al resultaten mee bereikt? Verder zie ik mogelijkheden om van foto's die kompasrichting-informatie hebben (Android G1, iPhone 3GS) die gegevens te gebruiken om in combinatie met de hoek van de borden ten opzichte van de fotograaf een gooi te doen naar welke naam bij welke straat hoort. Is dat ook onderdeel van je project? martijn van exel http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes 2009/6/29 Tijs Zwinkels openstreet...@tumblecow.net: Hallo Iedereen, Aan de late kant, maar laat ik me even introduceren: Ik ben Tijs Zwinkels, ik heb zojuist mijn kunstmatige intelligentie opleiding afgerond, en sinds een week of vijf ben ik onder de vlag van de google summer of code bezig met een project om automatisch Nederlandse straatnaamborden te detecteren, segmenteren, en hopenlijk ook te lezen. Stefan is mijn mentor voor dit project. Klinkt interessant? Vond ik ook. :) - kijk vooral ook even op het opengeo blog voor wat meer tekst, uitleg, en plaatjes. Ik zal vanaf heden proberen jullie als 'de community' wat regelmatiger op de hoogte te houden. De huidige methodiek werkt in een aantal gevallen vrij goed, met in meer van 80% van de gevallen de straatnaamborden op plaatjes perfect gesegmenteerd in mijn eigen testset. Probleem is dat mijn eigen trainset nagenoeg uitsluitend in een nieuwbouwwijk, met mooie shiny nieuwe blauwe straatnaamborden opgenomen is. Bij 'minder mooie' borden en andere camera's wordt de performance snel slechter. Ik ben zelf al bezig geweest met nieuwe data verzamelen, maar: Ik ben voorlopig nog wanhopig opzoek naar nieuwe data om op te trainen of te testen. Heeft iemand nog een set met foto's van straatnaamborden voor mapping purposes liggen? Voornaamste eis is dat het straatnaambord groot in beeld is (minimaal 1/400e van de totale oppervlakte van de foto), de foto van voldoende kwaliteit is, en dat het straatnaambord leesbaar is. Iemand die me kan helpen? Mocht je het leuk vinden om met het huidige product te spelen, de code staat online op http://code.google.com/p/signfinder/ . Het ding draait op linux, en heeft de opencv library nodig. Ik zal vanmiddag betere documentatie toevoegen, maar de werking is simpel: de signFinder-executable accepteerd een of meerdere jpg-foto's op de command line. Hij probeert hier straatnaamborden op de te vinden (remember, groot genoeg in beeld..), en schrijft een bestand met de naam filename_result.jpg weg waarin hij een lijntje om de gevonden borden heen tekent. - Tijs ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Google Summer of Code 2009 - signFinder.
supermooi project! ik ben erg benieuwd naar de voortgang. wat betreft de foto's: zeg maar hoeveel je er wilt hebben :) ik heb er zeker enkele duizenden. ik zal er een zootje online zetten en je de url mailen. groet, floris Tijs Zwinkels wrote: Hallo Iedereen, Aan de late kant, maar laat ik me even introduceren: Ik ben Tijs Zwinkels, ik heb zojuist mijn kunstmatige intelligentie opleiding afgerond, en sinds een week of vijf ben ik onder de vlag van de google summer of codehttp://code.google.com/soc/bezig met een projecthttp://wiki.openstreetmap.org/wiki/GSoC_Student_Applications_2009#Draft_application:_Automatic_Street-Sign_Detection_and_Readingom automatisch Nederlandse straatnaamborden te detecteren, segmenteren, en hopenlijk ook te lezen. Stefan is mijn mentor voor dit project. Klinkt interessant? Vond ik ook. :) - kijk vooral ook even op het opengeo blog http://blog.opengeo.nl/index.php/2009/06/29/signfinder/ voor wat meer tekst, uitleg, en plaatjes. Ik zal vanaf heden proberen jullie als 'de community' wat regelmatiger op de hoogte te houden. De huidige methodiek werkt in een aantal gevallen vrij goed, met in meer van 80% van de gevallen de straatnaamborden op plaatjes perfect gesegmenteerd in mijn eigen testsethttp://mirror.openstreetmap.nl/openstreetphoto/tijs/results/210609/test1/. Probleem is dat mijn eigen trainset nagenoeg uitsluitend in een nieuwbouwwijk, met mooie shiny nieuwe blauwe straatnaamborden opgenomen is. Bij 'minder mooie' borden en andere camera's wordt de performance snel slechter. Ik ben zelf al bezig geweest met nieuwe data verzamelen, maar: Ik ben voorlopig nog wanhopig opzoek naar nieuwe data om op te trainen of te testen. Heeft iemand nog een set met foto's van straatnaamborden voor mapping purposes liggen? Voornaamste eis is dat het straatnaambord groot in beeld is (minimaal 1/400e van de totale oppervlakte van de foto), de foto van voldoende kwaliteit is, en dat het straatnaambord leesbaar is. Iemand die me kan helpen? Mocht je het leuk vinden om met het huidige product te spelen, de code staat online op http://code.google.com/p/signfinder/ . Het ding draait op linux, en heeft de opencv library nodig. Ik zal vanmiddag betere documentatie toevoegen, maar de werking is simpel: de signFinder-executable accepteerd een of meerdere jpg-foto's op de command line. Hij probeert hier straatnaamborden op de te vinden (remember, groot genoeg in beeld..), en schrijft een bestand met de naam filename_result.jpg weg waarin hij een lijntje om de gevonden borden heen tekent. - Tijs ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Google Summer of Code 2009 - signFinder.
Ik zal de ftp over een uurtje aanzetten :) Stefan Op 29 jun 2009 om 13:29 heeft Floris Looijesteijn o...@floris.nu het volgende geschreven:\ supermooi project! ik ben erg benieuwd naar de voortgang. wat betreft de foto's: zeg maar hoeveel je er wilt hebben :) ik heb er zeker enkele duizenden. ik zal er een zootje online zetten en je de url mailen. groet, floris Tijs Zwinkels wrote: Hallo Iedereen, Aan de late kant, maar laat ik me even introduceren: Ik ben Tijs Zwinkels, ik heb zojuist mijn kunstmatige intelligentie opleiding afgerond, en sinds een week of vijf ben ik onder de vlag van de google summer of codehttp://code.google.com/soc/bezig met een projecthttp://wiki.openstreetmap.org/wiki/GSoC_Student_Applications_2009#Draft_application:_Automatic_Street-Sign_Detection_and_Reading om automatisch Nederlandse straatnaamborden te detecteren, segmenteren, en hopenlijk ook te lezen. Stefan is mijn mentor voor dit project. Klinkt interessant? Vond ik ook. :) - kijk vooral ook even op het opengeo blog http://blog.opengeo.nl/index.php/2009/06/29/signfinder/ voor wat meer tekst, uitleg, en plaatjes. Ik zal vanaf heden proberen jullie als 'de community' wat regelmatiger op de hoogte te houden. De huidige methodiek werkt in een aantal gevallen vrij goed, met in meer van 80% van de gevallen de straatnaamborden op plaatjes perfect gesegmenteerd in mijn eigen testsethttp://mirror.openstreetmap.nl/openstreetphoto/tijs/results/210609/test1/ . Probleem is dat mijn eigen trainset nagenoeg uitsluitend in een nieuwbouwwijk, met mooie shiny nieuwe blauwe straatnaamborden opgenomen is. Bij 'minder mooie' borden en andere camera's wordt de performance snel slechter. Ik ben zelf al bezig geweest met nieuwe data verzamelen, maar: Ik ben voorlopig nog wanhopig opzoek naar nieuwe data om op te trainen of te testen. Heeft iemand nog een set met foto's van straatnaamborden voor mapping purposes liggen? Voornaamste eis is dat het straatnaambord groot in beeld is (minimaal 1/400e van de totale oppervlakte van de foto), de foto van voldoende kwaliteit is, en dat het straatnaambord leesbaar is. Iemand die me kan helpen? Mocht je het leuk vinden om met het huidige product te spelen, de code staat online op http://code.google.com/p/signfinder/ . Het ding draait op linux, en heeft de opencv library nodig. Ik zal vanmiddag betere documentatie toevoegen, maar de werking is simpel: de signFinder-executable accepteerd een of meerdere jpg-foto's op de command line. Hij probeert hier straatnaamborden op de te vinden (remember, groot genoeg in beeld..), en schrijft een bestand met de naam filename_result.jpg weg waarin hij een lijntje om de gevonden borden heen tekent. - Tijs ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Google Summer of Code 2009 - signFinder.
2009/6/29 Tijs Zwinkels openstreet...@tumblecow.net: Ik ben voorlopig nog wanhopig opzoek naar nieuwe data om op te trainen of te testen. Heeft iemand nog een set met foto's van straatnaamborden voor mapping purposes liggen? Voornaamste eis is dat het straatnaambord groot in beeld is (minimaal 1/400e van de totale oppervlakte van de foto), de foto van voldoende kwaliteit is, en dat het straatnaambord leesbaar is. Iemand die me kan helpen? Hoi Tijs, leuk project! Ik heb redelijk wat foto's uit België liggen met naambordjes (5 megapixel, met georeferentie), de layout zal anders zijn dan de standaard Nederlandse bordjes (vaak zwarte letters op witte achtergrond) - kan ik je daar mee helpen? gr, Dieter ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Google Summer of Code 2009 - signFinder.
Allemaal bedankt voor de foto's en de positieve reacties. Keep em coming! 2009/6/29 Martijn van Exel mve...@gmail.com Veelbelovende resultaten tot nu toe, maar de laatste stap, het lezen van de straatnamen uit de gedetecteerde borden, is uiteraard een cruciale om de post-processing van ruwe data (tracks + foto's) te helpen automatiseren. Heb je hier al resultaten mee bereikt? Nee, zo ver ben ik nog niet. Ik ben eerst nog even bezig met de segmentatie zelf verbeteren. Desalnietemin: We hebben nog tot 17 augustus voor de GSoC, en ik verwacht absoluut ook daarna nog aan dit project te bijven werken. Ik ga zonder enige twijfel nog toekomen aan het OCR-en van borden, en ik ben benieuwd naar de resultaten. Ook leuk te vermelden is dat een onderzoeksgroep aan Artificial Intelligence in Groningen zich bezighoudt met handschriftherkenning, wat in principe een 'lastigere variant' van OCR is. Ze zijn hier al jaren mee bezig, en in overleg is besloten dat ik evt. hun code mag gebruiken en open-sourcen als ik help. Een ander speerpunt is dat we deze technologie ook willen gaan gebruiken voor de detectie van andere verkeersborden. We kunnen wellicht verkeersborden detecteren, maximumsnelheden lezen, en verkeersborden lezen of juist blurren in foto's. Afijn, ik ga het binnenkort met Stefan hebben over de volgende stap. Verder zie ik mogelijkheden om van foto's die kompasrichting-informatie hebben (Android G1, iPhone 3GS) die gegevens te gebruiken om in combinatie met de hoek van de borden ten opzichte van de fotograaf een gooi te doen naar welke naam bij welke straat hoort. Is dat ook onderdeel van je project? Het daadwerkelijk gebruiken van deze technologie voor automatische mapping is nog een hele uitdaging opzich. Kompasinformatie kan daar bij helpen, maar ik denk dat het indien mogelijk ook zaak zal zijn om straatnaamborden aan zowel het begin-punt als eind-punt van de straat te fotograferen: We moeten immers ook weten waar een straat eindigd. Opzich is dit nog niet expliciet gedefinieerd als onderdeel van dit project; eerst maar eens die borden betrouwbaar lezen, maar het is zeer zeker een logische volgende stap. Bovendien en zoals ik al aangaf: Ik verwacht ook na het eindigen van de summer of code hiermee bezig te blijven en zoveel mogelijk praktische implementaties te genereren. :) - Tijs ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Google Summer of Code 2009 - signFinder.
On Mon, 29 Jun 2009, Tijs Zwinkels wrote: Verder zie ik mogelijkheden om van foto's die kompasrichting-informatie hebben (Android G1, iPhone 3GS) die gegevens te gebruiken om in combinatie met de hoek van de borden ten opzichte van de fotograaf een gooi te doen naar welke naam bij welke straat hoort. Is dat ook onderdeel van je project? Het daadwerkelijk gebruiken van deze technologie voor automatische mapping is nog een hele uitdaging opzich. Kompasinformatie kan daar bij helpen, maar ik denk dat het indien mogelijk ook zaak zal zijn om straatnaamborden aan zowel het begin-punt als eind-punt van de straat te fotograferen: We moeten immers ook weten waar een straat eindigd. Ik denk dat kompas richting vooral voor hergebruik van foto's kan helpen. Voor het rectificeren is meer nodig dan alleen een richting natuurlijk. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] [Talk-de] Hall of Fame - Strassen komplett erfasst!
Hi! Essen in Duitsland heeft 100% van de straats in OSM en een nieuwe Wiki-Pagina is geopened: http://wiki.openstreetmap.org/wiki/Hall_of_Fame/Streets_complete Mogen jullie ook jouw plaats in de Hall of Fame? Groeten uit Duitsland! Rotbarsch - Weitergeleitete Nachricht von r...@gmx-topmail.de - Datum: Mon, 29 Jun 2009 11:55:55 +0200 Von: Rotbarsch r...@gmx-topmail.de Antwort an: Openstreetmap allgemeines in Deutsch talk...@openstreetmap.org Betreff: [Talk-de] Hall of Fame - Strassen komplett erfasst! An: talk...@openstreetmap.org Ihr habt Sorgen :-) Wir keine mehr! Essen hat die Wette gegen Düsseldorf gewonnen und sich damit einen Stern auf dem Prachtboulevard (das ist der Weg zur perfekten Karte) gesichert: http://wiki.openstreetmap.org/wiki/Hall_of_Fame/Streets_complete Landkreise, Städte, Stadtteile, Bundesländer und andere Gebiete: Tragt Euch auch ein, wenn Eure Straßen zu 100% erfasst sind (und das plausibel nachvollziehbar ist). Viele Grüße vom Rotbarsch P.S: Jetzt sind wir fertig, oder? (Zitat von Jeepster auf der Essener Liste): Aber lasst uns jetzt bloß nicht ausruhen. Straßen sind fast vollständig. Es gibt aber noch so vieles zu tun. Ich stehe immer noch auf dem Standpunkt, OSM kann gar nicht fertig werden. Es gibt immer noch was zu tun. Ich muss noch so viele Häuser mappen, ich habe noch tausende Hausnummern vor der Brust, meine Buslinien sind noch nicht fertig, ich muss immer noch schauen, warum die routingfähige Karte, mich durch Parks (Gruga und Zoos) führt, keep right, melde mir auch jeden Tag (tag für tag) neue Fehler, die ausgebügelt werden müssen, auf OpenStreetBugs meldet sich auch jeden Tag ein neuer User der schreibt - hier ist auch noch ein Fussweg, dann fehlt bei 90% der Apotheken noch der Name, teilweise fehlen noch einige Kleingartenanlagen, der NRW Radweg ist auch noch nicht komplett, dann ist die Wanderkarte noch nicht so wie ich sie gerne hätte (die von Nop), man kann die Wege schlecht erkennen, in dem Zuge mein vogelfreier, in Katernberg sind noch Reitwege, ich werde mal Nop fragen, ob er mal mit nem Pferd vorbeikommt, dann fehlen auf dem Baldeneysee noch die Verbindungen der weißen Flotte, dann würde ich gerne das Klinikum komplett mappen (mit allen Gebäuden), dann auch die Gruga komplettieren. Im segerothpark habe ich aufgehört die Grabsteine zu mappen (für die 100%), der Limbecker Platz wird auch bald fertig, dann werden neue Radwege gebaut (achja die Brücke auf der Wasser Route in Borbeck ist fertig - auch gemappt), das Unigelände wird neu gestaltet . . . . . usw, usw. ___ Talk-de mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Google Summer of Code 2009 - signFinder.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Martijn van Exel wrote: Hmm, een collega van me heeft vrij gauw een app geschreven voor Android waarin de kompasrichting (drie dimensies) wel met de foto wordt opgeslagen. De hardware is niet open source, maar als softwareplatform is Android wel veel opener dan elke andere telefoon die voor de consumentenmarkt wordt geproduceerd. In de standaard camera-app worden die gegevens inderdaad, idioot genoeg, niet opgeslagen. Er zijn ook geen goede EXIF-tags voor. De Elphel neemt compasrichting ook gewoon mee :) En er is zeker wel een exif tag voor. 'Direction of Image'. [kan ook wel naar talk-nl] Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkpJObAACgkQYH1+F2Rqwn0UgwCggfd3AlS4Q3KSoKPkh6yu89cA P44Aniyj0EuEuuwO19ow9nOa1YfYytcs =sVDs -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Riding for the Disabled...
--- On Mon, 29/6/09, b.schulz...@scu.edu.au b.schulz...@scu.edu.au wrote: I'd say that since the name of the organisation is Riding for the Disabled it should appear on the map in exactly the same form. If it was offensive to it's customers one would think that the name would have been changed by now. And if nothing else offensive names are the fault of the company in question, not OSM. Tagging a POI with a different name may be more politically correct, but it can be confusing for map users if the map name doesn't match a name on a sign. name isn't the issue, the sign along the road is Gympie and District Riding for the Disabled, however that's where certainity ends, it's some kind of amenity, but probably not a tourism thing. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Riding for the Disabled...
Well I'm not deeply familiar with the organisation, but I'd say that something containing sport=equestrian would be the most appropriate. Or at least that would be the closest thing OSM currently has. - Original Message - From: John Smith delta_foxt...@yahoo.com Date: Monday, June 29, 2009 4:24 pm Subject: Re: [talk-au] Riding for the Disabled... To: talk-au@openstreetmap.org, b.schulz...@scu.edu.au --- On Mon, 29/6/09, b.schulz...@scu.edu.au b.schulz...@scu.edu.au wrote: I'd say that since the name of the organisation is Riding for the Disabled it should appear on the map in exactly the same form. If it was offensive to it's customers one would think that the name would have been changed by now. And if nothing else offensive names are the fault of the company in question, not OSM. Tagging a POI with a different name may be more politically correct, but it can be confusing for map users if the map name doesn't match a name on a sign. name isn't the issue, the sign along the road is Gympie and District Riding for the Disabled, however that's where certainity ends, it's some kind of amenity, but probably not a tourism thing. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Junctions (to name or not to name)
In my experience gosmore doesn't care at all about the names of the streets except for displaying them and searching for them. I've certainly never had a problem with gosmore routing not recognising a roundabout because it was unnamed. If someone can show me an example (a osm map link will do - preferably in QLD as I already have the gosmore file) of a roundabout that causes this problem, and I'll look into fixing the bug in gosmore. - David Stephen Hope wrote: This is most definitely a problem with Gosmore. The fact is, most roundabouts do not have names, and artificially giving them one to make a renderer (or routing program) happy is tagging for the renderer. Even if a roundabout did have a name, I'd be happier if the routing software just said turn onto roundabout, take second exit on Smith Highway than if it said turn onto Great Circle, turn onto Smith Highway. Names on roundabouts are so uncommon that I'd be looking for a road called Great Circle. Or are you saying that if the entry and exit roads and roundabout all have the same name it ignores the roundabout entirely, and this behaviour is what is broken? That's not too hard a fix to do in a program. Anything marked as a junction or roundabout should be getting special treatment anyway. It shouldn't matter if the roundabout has no name, the name of the street you're on, or the name of a different crossing street, as long as it is marked as a roundabout. It's still a bug if it causes a problem. Stephen 2009/6/28 Ross Scanlon i...@4x4falcon.com: This is not a problem with gosmore, the problem occurs where you have a street going through a roundabout without ANY name on the roundabout with the street named on both sides of the roundabout. It does not recognise the street continues through the roundabout and then out the other side. If there's no name on the streets or roundabout then it work's correctly. Likewise if the streets are named and the roundabout is named then there's not a problem. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- View this message in context: http://www.nabble.com/Junctions-%28to-name-or-not-to-name%29-tp24237610p24249798.html Sent from the OpenStreetMap - Australian Talk mailing list archive at Nabble.com. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Junctions (to name or not to name)
Thanks everyone for your input regarding roundabouts and under what circumstances to tag them with a name=* Whilst some opinions differ, I'd suggest that the majority of people who have responded to my post name roundabout junctions only when the roundabout has an official name (not the name of any primary road that forms a part of the junction) To me this seems a logical approach and is based on the mapping only what we see method that I often see written or referred to. I agree that it doesn't make sense to name junctions purely to get a particular renderer or routing program to perform as required. When approaching an unnamed roundabout with my particular GPS navigator using OSM routable data, it will speak - enter roundabout and take second exit to Foo street This is a perfectly acceptable and practical driving instruction. At this stage, I've removed the naming of roundabouts in the data that I'm working on, as none of them have official names. That leaves outstanding, two issues: 1. The error warnings in JOSM Validator for unnamed ways that are junction=roundabout 2. Lack of wiki information for newcomers (such as myself) when researching under what circumstances to name junction=roundabout Given that roundabouts are an incredibly common form of junction in Australia (I'd imagine in other countries too), I'd like to promote a consistent approach to how and under what circumstances they are named. As a newbie, I'll have to research further on how to reach agreement at an international level on naming conventions for junction=roundabout and then contact the JOSM development team regarding the Validator selecting roundabouts as error warnings. In the interim, I'd draw your attention to http://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Roundabouts as a potential location for expanded information to assist people in Australia when looking for clarification on this issue. Cheers, Rick :) ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Where is OSM getting this data?
I can't see what is creating the place marker for Curra in the centre of this map: http://www.openstreetmap.org/?lat=-26.06883lon=152.59675zoom=16layers=B000FTF In fact I couldn't find a place marker at all so I created a new one but I'm still stumped where this is getting pulled from. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Where is OSM getting this data?
--- On Mon, 29/6/09, Darrin Smith bel...@beldin.org wrote: That looks like the one that's automatically created at the centre of the administration boundary multipolygon (i.e. suburb boundary) Thanks for the replies, it gives me some where to hunt, unless I don't need to and it's only put in if there is no place marker in the polygon? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Vorschlag zum neutralen Mapping
Am Sonntag, 28. Juni 2009 09:20:24 schrieb Thomas Reincke: Nop schrieb: Abgesehen davon: Wieviel % der Straßen in OSM sind heute gut klassifiziert, haben aber keine Breite eingetragen, so daß sie mit diesem Vorschlag alle wieder nachbearbeitet werden müßten? Verfeinerungen wird es immer geben. Irgendwann werden statt des Straßenkörpers die Fahrbahnen gemappt, vielleicht noch das ganze als Fläche. Und für ein Rolli-Navi wäre es hilfreich die Bordsteinabsenkungen zu haben. OSM bietet da noch enormes Entwicklungspotential - vor allem wenn wir mal ein besseres GPS/Galileo (oder was auch immer) bekommen. Wenn, das kl. Wörtchen wenn nicht wär. Schau mal http://de.wikipedia.org/wiki/Galileo_(Satellitennavigation) Gallileo wird nicht soviel mehr Genauigkeit bieten (für normale Anwender), wie schon zur Zeit. Anhand eines Tracks wird man auch morgen kaum unterscheiden können auf welcher Spur einer Straße ich mich bewege. Dafür wäre es dann immer noch zu ungenau. ___ 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] Neu fuer OSM-Tool-Entwickler: OAuth
Hallo, Marcus Wolschon wrote: es gibt ein sehr vielversprechendes neues Feature (derzeit noch im Test unter oauth.dev.openstreetmap.org, aber vermutlich schon bald auf dem Produktionsserver): OAuth. Coole Sache. Wie lange ist so ein Token gültig? In der derzeitigen Implementation: So lange, bis es vom Benutzer widerrufen wird. Ich koennte mir aber vorstellen, dass man noch ein Limit einfuehrt irgendwann, bloss um zu vermeiden, dass irgendwelche lengst vergessenen Uralt-Tokens noch Gueltigkeit haben. Gilt es nur für ein Changeset oder für beliebig viele? Fuer beliebig viele. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aenderungen erschweren (war: Routerh?rtetest - Topologie oder STVO?)
Am Sonntag, 28. Juni 2009 16:58:08 schrieb Martin Koppenhoefer: Am 26. Juni 2009 11:55 schrieb Markus liste12a4...@gmx.de: Die erforderliche Formgenauigkeit ist von verschiedenen Faktoren abhängig: - gibt es Punkte die eine eigene Information tragen und unverzichtbar sind (Grenzstein auf Grenze, Kreuzungen, Abzweigungen, Ecken) ja - gibt es Punkte die für die Lagegenauigkeit unverzichtbar sind (Messpunkte) s.o. - wieviele Daten kann die DB speichern immer mehr Mag sein, aber irgendwo ist eine gewisse Genauigkeit trotzdem beschränkt. Das ist wie beim JPG Bild, man muß einen Kompromiss aus einerseits gutaussehendem Bild und andererseits Dateigröße finden. Ansonsten ist die Bearbeitung nur noch mit Superrechnern möglich und das Speicher ab einer gewissen Bilderzahl schwierig. Wirklich gewonnen ist am Ende dadurch auch nichts. Unsere Daten verhalten sich doch sehr ähnlich. - wieviele Eckpunkte sind auf einer Kurve erforderlich, damit daraus die Kurve abgeleitet werden kann (abhängig von Kurvenform) ganz so viele werden wir uns wahrscheinlich nicht erlauben können, bzw. Gegenfrage: wie genau soll die Kurve abgeleitet werden? (willst Du rausbekommen, ob der Übergang ein Klothoid oder ein Sinusoid oder noch was anderes ist, oder reicht Dir die Information krumm? Prinzipiell wird man nie automatisch (ohne Zusatztag für gekurvt) mit 100% Treffsicherheit behaupten können, diese Segmente sind eigentlich eine Kurve, weil die Information einfach nicht da ist, man kann nur vermuten). Gruß Martin Gruß Sven S. ___ 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] Vorschlag zum neutralen Mapping
Am Montag, 29. Juni 2009 09:45:28 schrieb Nop: Hi! qbert biker schrieb: Methode A: ich such mir eine Ecke aus, die nich ganz trivial ist, mappe alles so um, wie es mir passt um dann zu zeigen, dass dann das Routing besser wird. Waere nicht unbedingt nett gegenueber den Mappern, die da schon was gemacht haben. Kann ich nur bestätigen. Habe auch mal versucht, lokal ein besseres Modell zu demonstrieren und es hat keine 24 Stunden gedauert bis der erste Mapper auf der Matte stand um seine Tags zu verteidigen. :-) bye Nop Vielleicht könnte man diese Probleme umgehen, wenn man mehrere Layer zur Verfügung hätte. Z.B. auch einen Experimentellen. ___ 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] Mal aus Sicht eines Mappers
On Mon, 29 Jun 2009, dieter jasper wrote: warum solche Bescheidenheit. Aus meiner Sicht ist die Bedienung in den letzten Monaten sehr viel einfacher und intuitiver geworden. Habe allerdings noch Probleme mit Relationen. Dauerte schon etwas bis Tja, wer hat die nicht :-) Nachdem Karl die Konfliktlösung und die History-Funktionen jetzt eingebaut hat gibt es aus meiner Sicht momentan zwei große zu erledigende Themenkreise: 1) Relationseditor und alles drumherum 2) Layer und Möglichkeiten zur Datenausblendung (einige Gebiete sind mittlerweile wirklich schwer zu verändern) Und irgendwann habe ich ja auch mal wieder Urlaub und ein bisschen Zeit wird dann für JOSM abfallen (wenn mir nicht jemand zuvorkommt). Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von Orten
Hallo Johannes, EW als Kriterium Kannst Du das in Mapnik einbauen? wenn Du mir sagst, wie das geht :-( und ich dachte schon, Du kennst Dich da aus... Also: wer kann das umsetzen? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Urlaubsdaten
On Mon, 29 Jun 2009, Jan Tappenbeck wrote: gibt es zu Dialog zum Lösen von Datenkonflikten eine Beschreibung im Netz - verstehe das Tool nicht !!! Nein. Wenn Du es nicht verstehst auch ein Trac-Ticket aufmachen, beschreiben was Du nicht verstehst (bitte ausführlich, also z.B. was Du verstehst, was Du annimmst und was vollkommen unklar ist) und Gubaer als Adressat eintragen. Das ganze ist brandneu. Da gibt es bestimmt noch einiges zu verbessern. Generell musst Du dich immer zwischen Deiner eigenen und der Server-Version entscheiden bis alles grün ist :-) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mal aus Sicht eines Mappers
On Mon, 29 Jun 2009, Sven Sommerkamp wrote: Wenn man sich JOSM anschaut, dann ist das sicher nicht die allereinfachst zu bedienende Software. Aber es gibt auch keinen Grund, ihn schlechtzureden. Zumal man die Wahl hat, es gibt ja nicht nur JOSM. Nein, und ich könnte mir gerade für den Neuling deutlich einfachere Tools vorstellen. Ich bastele zu diesem Zweck gerade an einer Präsentation, die verdeutlichen soll, was ich meine. Ich hoffe das das so klappt wie ich denke. Programmieren kann ich nunmal leider (noch) nicht, aber ich hab viel Erfahrung im experimentieren ausprobieren und eine Sicht auf das Ganze welche sich von der der reinen Programmierer abhebt. Ich habe vor allem meine Probleme aus der Anfangszeit nicht vergessen! Ein Rat damit Du nicht nur für die Schublade arbeitest: - Nicht eine neue Anwendunge postulieren, sondern Vorschläge für die existierenden machen. - Vorschläge in einzelne Teile zerbrechen, die auch umsetzbar sind. - Notfalls ein schrittweises Vorgehen - kleine Sachen werden eher umgesetzt als große. - Keinen radikalen Bruch mit existierenden Verfahren - Microsoft ist mit seiner Word-Methode auch auf die Nase gefallen. - Für jede JOSM-relevante Idee ein Trac-Ticket aufmachen, sofern es nicht schon existiert. - Auf dem Boden bleiben. Etwas was Jahre zur Umsetzung braucht, brauchst Du heute nicht zu beschreiben. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
On Mon Jun 29, 2009 at 09:5108AM +0200, Sven Sommerkamp wrote: Am Montag, 29. Juni 2009 09:45:28 schrieb Nop: qbert biker schrieb: Methode A: ich such mir eine Ecke aus, die nich ganz trivial ist, mappe alles so um, wie es mir passt um dann zu zeigen, dass dann das Routing besser wird. Waere nicht unbedingt nett gegenueber den Mappern, die da schon was gemacht haben. Kann ich nur bestätigen. Habe auch mal versucht, lokal ein besseres Modell zu demonstrieren und es hat keine 24 Stunden gedauert bis der erste Mapper auf der Matte stand um seine Tags zu verteidigen. :-) Vielleicht könnte man diese Probleme umgehen, wenn man mehrere Layer zur Verfügung hätte. Z.B. auch einen Experimentellen. Sowas haben wir doch: du kannst im Tag ja sowas wie nen Namensraum verwenden, z.B. alles mit EXPERIMENT: beginnen lassen (oder deinem Usernamen, oder ...) Und wenn man neue Sachen ausprobieren oder was demonstrieren will, dann setzt man die Tags doch erst mal nur zusaetzlich. Oder versteh ich da gerade was nicht? -- Michael Bergbauer mich...@noname.franken.de Munich, Germany ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
Am Montag, 29. Juni 2009 10:13:06 schrieb Michael Bergbauer: On Mon Jun 29, 2009 at 09:5108AM +0200, Sven Sommerkamp wrote: Am Montag, 29. Juni 2009 09:45:28 schrieb Nop: qbert biker schrieb: Methode A: ich such mir eine Ecke aus, die nich ganz trivial ist, mappe alles so um, wie es mir passt um dann zu zeigen, dass dann das Routing besser wird. Waere nicht unbedingt nett gegenueber den Mappern, die da schon was gemacht haben. Kann ich nur bestätigen. Habe auch mal versucht, lokal ein besseres Modell zu demonstrieren und es hat keine 24 Stunden gedauert bis der erste Mapper auf der Matte stand um seine Tags zu verteidigen. :-) Vielleicht könnte man diese Probleme umgehen, wenn man mehrere Layer zur Verfügung hätte. Z.B. auch einen Experimentellen. Sowas haben wir doch: du kannst im Tag ja sowas wie nen Namensraum verwenden, z.B. alles mit EXPERIMENT: beginnen lassen (oder deinem Usernamen, oder ...) Und wenn man neue Sachen ausprobieren oder was demonstrieren will, dann setzt man die Tags doch erst mal nur zusaetzlich. Oder versteh ich da gerade was nicht? Nein, so meinte ich das nicht. Ich könnte mir vorstellen, das es vielleicht nicht nur den einen OSM Server in England gibt, oder altenativ doch nur den Einen aber mehrere OSM Datenbanken für unterschiedliche Anwendungen. Im Editor können dann die Einzelnen Layer ein und ausgeblendet werden. Mit kann Daten von dem einen in den Anderen übernehmen Als Layer könnte ich mir dann vorstellen: OSM NAV Routingfähige Karte für Navigationsgeräte, z.B. Garmin, Navit, Gosmore... OSM MAP Gerenderte Karten OSM SEA Für Seekarten auch auf Navigationsgeräten OSM ARCHFür Freunde der Archäologie OSM HISTHistorische Karten .. -Der Vorteil wäre, das weniger Datenverkehr entstünde. -Man könnte die Daten für den gedachten Zweck optimieren -Es käme der Übersicht beim Editieren zugute. -Trotz Spezialisierung hätte jeder Möglichkeiten seine Daten in OSM einzubringen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
Original-Nachricht Datum: Mon, 29 Jun 2009 10:13:06 +0200 Von: Michael Bergbauer listsub-...@noname.franken.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Vorschlag zum neutralen Mapping Sowas haben wir doch: du kannst im Tag ja sowas wie nen Namensraum verwenden, z.B. alles mit EXPERIMENT: beginnen lassen (oder deinem Usernamen, oder ...) Dann habe ich aber nur nachgewiesen, was ich vorher schon wusste. Von den anderen kommt ja keiner ran, ausser man liefert ne komplette Toolchain mit, die diese Sondertags auswertet und die habe ich im Moment nicht. Spannend wirds erst, wenn man die Mapper reinnimmt. Also mit den tags arbeitet, die gelistet sind und probiert, was man aus denen rauskitzeln kann. Und wenn man neue Sachen ausprobieren oder was demonstrieren will, dann setzt man die Tags doch erst mal nur zusaetzlich. Oder versteh ich da gerade was nicht? Speziell mir gehts darum, was ich mit den Informationen anfangen kann, die andere eingetragen haben, denn auch ich habe eigentlich keine Lust, ein komplett neues Taggingschema ueberzustuelpen. Bestimmte Unschaerfen kann man akzeptieren, aber an anderen sollte man arbeiten. Die Beispiele habe ich genannt: Kann man aus dem aktuellen Taggingschema bestimmte Informationen sicher auslesen oder nicht, die grossen Einfluss auf die Reisezeit haben. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mal aus Sicht eines Mappers
Dirk Stöcker schrieb: Nachdem Karl die Konfliktlösung und die History-Funktionen jetzt eingebaut hat gibt es aus meiner Sicht momentan zwei große zu erledigende Themenkreise: 1) Relationseditor und alles drumherum 2) Layer und Möglichkeiten zur Datenausblendung (einige Gebiete sind mittlerweile wirklich schwer zu verändern) Ja, das wäre gut Und irgendwann habe ich ja auch mal wieder Urlaub und ein bisschen Zeit wird dann für JOSM abfallen Hoffenlicht bald (wenn mir nicht jemand zuvorkommt). Wird wohl leider nicht passieren. Gruß Dieter Jasper Ciao ___ 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] Neu fuer OSM-Tool-Entwickler: OAuth
Frederik Ramm frede...@remote.org wrote: dabei wird an keepright.at ein spezielles Token uebermittelt Klingt für mich irgendwie nach Kerberos? Sven -- We don't know the OS that God uses, but the Vatican uses Linux (Sister Judith Zoebelein, Vatican Webmaster) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gebäude auf highway=pedestrian?
Hallo zusammen, Es geht um folgendes: http://osm.org/go/0MZu2pZ4w== Da ist ein highway=pedestrian und da stehen Gebäude drauf. osmarender macht das auch richtig. Nicht jedoch der mapnik. Nun sind die Gebäude ja strenggenommen auch nicht wirklich auf die Fußgängerzone drauf gebaut sondern die Fußgängerzone geht drum herum. Wie mappt man das denn nun richtig? Fußgängerzone als Multipoligon. Gebäude als inner? Sven -- linux is evolution, not intelligent design (Linus Torvalds) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
Sven Geggus schrieb: Es geht um folgendes: http://osm.org/go/0MZu2pZ4w== Da ist ein highway=pedestrian und da stehen Gebäude drauf. osmarender macht das auch richtig. Nicht jedoch der mapnik. Nun sind die Gebäude ja strenggenommen auch nicht wirklich auf die Fußgängerzone drauf gebaut sondern die Fußgängerzone geht drum herum. Wie mappt man das denn nun richtig? Fußgängerzone als Multipolygon. Gebäude als inner? Ich würde sagen: Ja! Bin zwar selber kein Fan davon, für jede Kleinigkeit Multipolygone einzusetzen, aber wenn man highway=pedestrian, area=yes als Fläche definiert, wo Fussgänger umherwandeln können, dann ist es richtig, die Gebäude auszuschneiden. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
Hallo Sven, Wie mappt man das denn nun richtig? Ich schlage vor, dass Gebäude einfach auf eine Landfläche gesetzt werden (sie stehen ja auch auf dem Gelände) Fußgängerzone als Multipoligon. Gebäude als inner? Das Handling von Multipolygon empfinde ich als derart aufwändig, dass ich eigentlich am liebsten /überall/ darauf verzichten möchte. Falls relationale Konstrukte für die Anwendungsprogramme erforderlich sind, dann könnte man diese doch regelbasiert aus den Benutzereingaben erzeugen? Falls relationale Konstrukte zur Diskriminierung uneindeutiger Fälle erforderlich sind, dann muss man halt in den sauren Apfel beissen... (unterirdische Seen oder Bunker, im See versunkene Wälder, o.ä.) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu fuer OSM-Tool-Entwickler: OAuth
Date: Mon, 29 Jun 2009 01:32:54 +0200 From: Frederik Ramm frede...@remote.org Subject: [Talk-de] Neu fuer OSM-Tool-Entwickler: OAuth To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Message-ID: 4a47fda6.1010...@remote.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Ich will dieser Tage mal eine Demo-Implementierung eines OAuth-Clients machen, denn es fehlt noch an brauchbarer Demo-Software bzw. ueberhaupt an Dokumentation - derzeit muss man sich den Rails-Source (rails-port-branches/oauth) aus dem SVN ziehen, um zu verstehen, was da passiert. That's good news! Ich würde gerne den Amenity Editor asap auf diese Schnittstelle umstellen. Kannst du mich bitte informieren, sobald du etwas fertig hast? Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hall of Fame - Strassen komplett erfasst!
Ihr habt Sorgen :-) Wir keine mehr! Essen hat die Wette gegen Düsseldorf gewonnen und sich damit einen Stern auf dem Prachtboulevard (das ist der Weg zur perfekten Karte) gesichert: http://wiki.openstreetmap.org/wiki/Hall_of_Fame/Streets_complete Landkreise, Städte, Stadtteile, Bundesländer und andere Gebiete: Tragt Euch auch ein, wenn Eure Straßen zu 100% erfasst sind (und das plausibel nachvollziehbar ist). Viele Grüße vom Rotbarsch P.S: Jetzt sind wir fertig, oder? (Zitat von Jeepster auf der Essener Liste): Aber lasst uns jetzt bloß nicht ausruhen. Straßen sind fast vollständig. Es gibt aber noch so vieles zu tun. Ich stehe immer noch auf dem Standpunkt, OSM kann gar nicht fertig werden. Es gibt immer noch was zu tun. Ich muss noch so viele Häuser mappen, ich habe noch tausende Hausnummern vor der Brust, meine Buslinien sind noch nicht fertig, ich muss immer noch schauen, warum die routingfähige Karte, mich durch Parks (Gruga und Zoos) führt, keep right, melde mir auch jeden Tag (tag für tag) neue Fehler, die ausgebügelt werden müssen, auf OpenStreetBugs meldet sich auch jeden Tag ein neuer User der schreibt - hier ist auch noch ein Fussweg, dann fehlt bei 90% der Apotheken noch der Name, teilweise fehlen noch einige Kleingartenanlagen, der NRW Radweg ist auch noch nicht komplett, dann ist die Wanderkarte noch nicht so wie ich sie gerne hätte (die von Nop), man kann die Wege schlecht erkennen, in dem Zuge mein vogelfreier, in Katernberg sind noch Reitwege, ich werde mal Nop fragen, ob er mal mit nem Pferd vorbeikommt, dann fehlen auf dem Baldeneysee noch die Verbindungen der weißen Flotte, dann würde ich gerne das Klinikum komplett mappen (mit allen Gebäuden), dann auch die Gruga komplettieren. Im segerothpark habe ich aufgehört die Grabsteine zu mappen (für die 100%), der Limbecker Platz wird auch bald fertig, dann werden neue Radwege gebaut (achja die Brücke auf der Wasser Route in Borbeck ist fertig - auch gemappt), das Unigelände wird neu gestaltet . . . . . usw, usw. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mal aus Sicht eines Mappers
Christian H. Bruhn schrieb: ... Schön auf den Punkt gebracht... Wenn die Unterscheidung ob eine Straße und track oder unclassified ist, nicht so einfach ist, dann ist das System wohl zu kompliziert für den Durchschnittsmapper. Wenn nur Spezialisten und Profis feststellen können, die Straße ein trunk ist oder nicht, dann sollte man überlegen, wie man es den Amateuren einfacher machen kann. Vielleicht wäre ein hierarisches System sinnvoll. Der Amateur taggt eindeutig (!), das was er sieht und der Profi hat die Möglichkeit die Information mit zusätzlichen Tags zu verfeinern.. Da wird es schwieriger... Hier ist gute Ortskenntniss erforderlich Die Information die u.a. rauskommen sollte: Für Wanderer: - geteerter Weg, zum Wandern ehr unbeliebt - darf ich über den dargstellten Weg zu meinem Ausgangspunkt für die Wanderung fahren Für Radfahrer - geteerter Weg, zum allgemeinen Radfahren ehr beliebt - Muss ich mit nennenswertem KFZ-Verkehr rechnen? Für KFZ: - darf ich den Weg benutzen - ist der Weg für meinen Benutzungzweck geeignet (naheliegendes Ziel - Fernziel/ Ausflugsverkehr -Fernverkehr) Sowas kann auch ein Profi aus der Ferne nur schwer einschätzen. Ein ortsfremder Profi wird aber kaum ohne persönlichem Bezug ein gemapptes Wegenetz noch mal abgehen/fahren um es zu verfeinern. Also bleibt es ausserhalb der stark frequentierten Gebiete bei dem was der örtiche Mapper - nicht selten eben der Amateur der seine Umgebung auch gerne in OSM hätte hängen. Von daher sollte track und unclassified auch vom Amateur problemlos eingeordnet werden können. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
qbert biker schrieb: - Spurenzahl Besonders in Verbindung mit dem kreuzungsfreien Ausbau und Tempolimit ein wichtiges Kriterium. Eine Spur mehr bedeutet Ueberholmoeglichkeit und ausserorts macht das u.U den Unterschied zwischen 90 und 120kmh aus und das ist eine Menge. Dem wird durch trunk (in der Verwendung für autobahnähnlich ausgebaut!) Rechnung getragen. Ohne Kenntniss vom tageszeit/wochentagsabhängigem Verkehrsaufkommen mehr als 100km/h als Durchschnittsgeschwindigkeit für den Router auf Autobahnabschnitten anzusetzen halte ich für realitätsfremd. Sicher gibt es Beispielabschnitte wo das geht (z.B A20), aber alleine aus einer 2. Spur kann man nicht darauf schliessen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
Sven Sommerkamp schrieb: Nein, so meinte ich das nicht. Ich könnte mir vorstellen, das es vielleicht nicht nur den einen OSM Server in England gibt, oder altenativ doch nur den Einen aber mehrere OSM Datenbanken für unterschiedliche Anwendungen. Im Editor können dann die Einzelnen Layer ein und ausgeblendet werden. Mit kann Daten von dem einen in den Anderen übernehmen Als Layer könnte ich mir dann vorstellen: OSM NAV Routingfähige Karte für Navigationsgeräte, z.B. Garmin, Navit, Gosmore... OSM MAP Gerenderte Karten OSM SEA Für Seekarten auch auf Navigationsgeräten OSM ARCH Für Freunde der Archäologie OSM HIST Historische Karten .. -Der Vorteil wäre, das weniger Datenverkehr entstünde. -Man könnte die Daten für den gedachten Zweck optimieren -Es käme der Übersicht beim Editieren zugute. -Trotz Spezialisierung hätte jeder Möglichkeiten seine Daten in OSM einzubringen Die Idee gibt es ja schon mindestens seit topografische Elemente in OSM Einzug gehalten haben um Natur und Verkehrswege sauber auseinanderhalten zu können. Das Problem ist aber die Layer (bzw. getrennte Datenbanken) soweit zueinandener kompatibel zu halten dass man die Vorteile jedes einzelnen Teilbereichs miteinander kombinieren kann. So bleibt eigentlich nur die Option im Editor die Layer virtuell durch ein/ausblenden von Tag-Gruppen zu erzeugen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
2009/6/29 Markus liste12a4...@gmx.de Hallo Sven, Wie mappt man das denn nun richtig? Ich schlage vor, dass Gebäude einfach auf eine Landfläche gesetzt werden (sie stehen ja auch auf dem Gelände) Falsch. Das Gebäude steht eindeutig nicht auf highway=pedestrian, sonern auf seiner eigenen Parzelle mit eigenen Zugangsrechten. Somit ist ein Multipoligon vermutlich angebracht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lummerland
http://osm.org/go/ehqD76IOO== ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
Peter Dörrie schrieb: 2009/6/29 Markus liste12a4...@gmx.de mailto:liste12a4...@gmx.de Hallo Sven, Wie mappt man das denn nun richtig? Ich schlage vor, dass Gebäude einfach auf eine Landfläche gesetzt werden (sie stehen ja auch auf dem Gelände) Falsch. Das Gebäude steht eindeutig nicht auf highway=pedestrian, sonern auf seiner eigenen Parzelle mit eigenen Zugangsrechten. Somit ist ein Multipoligon vermutlich angebracht. Und wo ist das Problem die pedestrian -Fläche aus zwei Flächen zusammenzusetzen? Eine Strasse wird ja auch beliebig oft gesplittet um z.B. über Brücken zu führen oder rechtlich Grenzen zu berücksichtigen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
Am Montag, den 29.06.2009, 08:56 +0200 schrieb qbert biker: Ist es cool, werden viele Leute nach genau dem Tagging vorgehen, weil ihre Straße auch so cool aussehen / funktionieren soll. Hat leider wenig mit coolness zu tun, sondern ist ein eher langweiliger Prozess der Verifizierung. Hm. Die Frage muss doch erlaubt sein: Willst du Daten-Genauigkeit haben, die *EINEN VORTEIL BIETET* oder nur etwas, was theoretisch besser wäre? Wenn es einen Vorteil gibt, solltest du das in einem wie auch immer gearteten *PRAKTISCHEN* Beispiel demonstrieren. Dass die Parameter genutzt werden *KÖNNEN* um eventuell irgendwo etwas *PRÄZISERE* Ergebnisse zu liefern steht außer Frage. Ich stelle nur nach wie vor in Frage, dass man das für irgendwelche *PRAKTISCHEN* Dinge *BRAUCHT*. Du redest grade mehr in Richtung Verifikation und Theoriemodelle. Das ist schon arg weit weg von etwas, was einen Mapper für mehr Datenerhebung begeistern würde. Oder besser: Ich würde mir wünschen, dass jemand eine Anwendung vorstellt, die aus der Existenz detaillierter Daten direkt und in der Gegenwart einen Nutzen zieht, den ein normaler Mapper sehen kann. Gruß, Bernd -- Autos sind und bleiben Phallus-Symbole. Kein Wunder, dass sich der Smart so schlecht verkauft. Kein Mann möchte freiwillig ein Phallus-Symbol, das auch quer in die Lücke passt! - Eckart von Hirschhausen (dt. Comedian) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu fuer OSM-Tool-Entwickler: OAuth
Hallo, Sven Geggus wrote: dabei wird an keepright.at ein spezielles Token uebermittelt Klingt für mich irgendwie nach Kerberos? Kerberos ist doch was, was auf einer zentralen Userdatenbank basiert, und die User koennen dann verschiedene fuer sie freigeschaltete Dienste nutzen. Bei OAuth liegt der Fokus darin, dass Du als User Berechtigungen delegieren kannst, ohne dass es dabei bei irgendwem eine zentrale Userdatenbank geben muesste. OAuth hat keinerlei Identity Management. OAuth braucht auch auch kein shared secret zwischen allen beiteiligten Diensten. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
Original-Nachricht Datum: Mon, 29 Jun 2009 11:58:35 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Vorschlag zum neutralen Mapping Dem wird durch trunk (in der Verwendung für autobahnähnlich ausgebaut!) Rechnung getragen. Nein, da von trunk nur ein Teil erfasst wird. Fuer den einen muss es fast eine Autobahn sein, fuer den anderen reichen ein paar Bruecken und Abfahrten. Dabei fallen viele kreuzungsfrei ausgebaute Strecken durch, z.B. die typische Umgehungsstrasse mit einer Spur pro Richtung. Aber gerade die bringen oft einen erheblichen Vorteil. Ohne Kenntniss vom tageszeit/wochentagsabhängigem Verkehrsaufkommen mehr als 100km/h als Durchschnittsgeschwindigkeit für den Router auf Autobahnabschnitten anzusetzen halte ich für realitätsfremd. Die erste Stufe, das statische Routing, nimmt die theoretisch erreichbare Geschwindigkeit nach den Verkehrsregeln. Die wird typischerweise bei der Autobahn mit 130 angesetzt, was oft real erreichbar ist. Ohne ein gutes statisches Reisezeitmodell als Basis zu haben, macht die Einbeziehung der Dynamik wenig Sinn 130 deshalb, weil das auf den Durschnittsfahrer gut passt. Hier koennte OSM dann noch voll seine Vorteile ausspielen, da ja die Modellparameter offen fuer jeden sind. Man kann einen Porsche-Set bauen, einen Enduro-Set und natuerlich wie bisher Radfahrer und Fussgaenger usw. Sicher gibt es Beispielabschnitte wo das geht (z.B A20), aber alleine aus einer 2. Spur kann man nicht darauf schliessen. Dann gilt es Daten zu sammeln und die einzutragen. Dann nimmt der Router den Default, den er aus der Strassenbeschreibung hat und setzt den oertlich und ggf. nach Tageszeit runter. Das eine ist die Erweiterung des anderen. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
Moin, Nop schrieb: Hi! Mario Salvini schrieb: Hi Nop, das highway=track ein Verbot induziert ist aber auch nur deine persönliche Meinung, aber nicht allgemeiner Konsens. Nö, isses nicht. Das habe ich nämlich nicht gesagt. Die Aussage ist: Anhand von Straßenbelag und Breite kann man eine kleine Straße und einen geteerten Feldweg nicht voneinander unterscheiden. Erst das Verbot für normale Fahrzeuge liefert den entscheidenden Hinweis. Klassifzierung funktioniert dagegen an dieser Stelle sehr gut. Wenn deiner Aussage nach das Verbot für normale Fahrzeuge den entscheidenden Hinweis für die Klassifizierung in unclassified und track liefert, was ist deiner Meinung nach dann falsch an der Aussage: Highway= track impliziert das Verbot für normale Fahrzeuge? +1 an Mario Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sightwalk, deutsches Google-Streetview
On Sun, Jun 28, 2009 at 06:30:24PM +0200, Jonas Krückel wrote: Tim 'avatar' Bartel schrieb: Hi, nur als kleiner Hinweis: Sightwalk (http://sightwalk.de) ging wohl im April schon durch das Netz, aber ich bin erst jetzt durch Zufall drauf gestoßen. Und augenscheinlich gab es noch keinen Hinweis in talk-de, den ich also hiermit nachhole. Idee: Google Streetmap, Kartenmaterial: OSM. Cool, sowas ähnliches gibt es auch in Bulgarien oder Rumäninen (weiß gerade nicht mehr genau). Die haben uns sogar ihre GPS-Tracks gespendet AFAIK. Wie siehts mit diesen Betreibern aus? Wäre auch toll, wenn man die Bilder nutzen dürfte, um POIs zu bestimmen. Ich hatte diesbezgl. mit dem Betreiber schon vor einer Weile Kontakt, er hat sich aber nicht wieder gemeldet. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
Original-Nachricht Datum: Mon, 29 Jun 2009 12:39:23 +0200 Von: Bernd Wurst be...@bwurst.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Vorschlag zum neutralen Mapping Hm. Die Frage muss doch erlaubt sein: Willst du Daten-Genauigkeit haben, die *EINEN VORTEIL BIETET* oder nur etwas, was theoretisch besser wäre? Einfache Antwort. Daten-Genauigkeit bietet immer Vorteile, aber nicht jeder Vorteil laesst sich sofort und jetzt realisieren. Ein Router verwendet alle Daten zwischen Start und Ziel und wird auch von allen Daten beeinflusst. Wenn es einen Vorteil gibt, solltest du das in einem wie auch immer gearteten *PRAKTISCHEN* Beispiel demonstrieren. Ich kann versuchen, ein Verstaendnis dafuer zu wecken, dass exakte Beschreibung, Datenpraezision und Anwendungsentwicklung Hand in Hand gehen muessen und sich gegenseitig befruchten. Dass die Parameter genutzt werden *KÖNNEN* um eventuell irgendwo etwas *PRÄZISERE* Ergebnisse zu liefern steht außer Frage. Ich stelle nur nach wie vor in Frage, dass man das für irgendwelche *PRAKTISCHEN* Dinge *BRAUCHT*. Du redest grade mehr in Richtung Verifikation und Theoriemodelle. Das ist schon arg weit weg von etwas, was einen Mapper für mehr Datenerhebung begeistern würde. Modelle nicht Theoriemodelle. Das ist keine blanke Theorie, sondern steckt in jedem Navi drin. Ansonsten will ich die Mapper mehr dafuer begeistern, nach genaueren Definitionen zu arbeiten, weil sie dann mit weniger Arbeit mehr schaffen koennen. Das ganze hin und her ummappen, das viel zu oft passiert, loescht ja Informationen und ist sicher nicht motivierend. Mal im Zweifelsfall ein Tag mehr einzutragen, das eine ganz spezifische Eigenschaft beschreibt (z.B. dieser Bereich ist kreuzungsfrei) bleibt auch erhalten, wenn jemand die Klasse ummappt. Stand nur highway=trunk drin, ist sie weg, wenn jemand meint, es sei ein primary. Oder besser: Ich würde mir wünschen, dass jemand eine Anwendung vorstellt, die aus der Existenz detaillierter Daten direkt und in der Gegenwart einen Nutzen zieht, den ein normaler Mapper sehen kann. Das bleibt Wunschgedanke. Die Verbesserungen beim Routing werden nur bei sorgfaeltiger Verifikation sichtbar. Eine Einzelroute oder eine gut vorberechnete Reisezeit ist ein Hinweis, aber nur ein Einzelwert. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
Hallo Garry, Ich schlage vor, dass Gebäude einfach auf eine Landfläche gesetzt werden (sie stehen ja auch auf dem Gelände) Falsch. Das Gebäude steht eindeutig nicht auf highway=pedestrian, sondern auf seiner eigenen Parzelle mit eigenen Zugangsrechten. Schon klar. Aber in besagtem Beispiel ist die Parzelle ja noch nicht in der DB. Mein Vorschlag ist ein grundsätzlicher: Gebäude stehen qua Definition immer auf einer Landfläche. Man braucht deshalb nicht extra in dieser Landfläche eine Grundfläche des Gebäudes /ausschneiden/ um dann dort das Gebäude hineinzusetzen. Also einfach das Gebäude auf den Wald draufklatschen oder auf das Industrie- oder Wohngebiet oder die Parzelle oder was auch immer. Also wo immer möglich keine Multipolygone mehr verwenden. (zumindest nicht auf Benutzerebene) wo ist das Problem die pedestrian -Fläche aus zwei Flächen zusammenzusetzen? Eine Fussgängerzone wird nicht dadurch zu zwei Fussgängerzonen, dass da ein Haus drin steht. Genausowenig wie aus einem Wald zwei Wälder werden, wenn dort ein Weg durchführt. Anders ist es, wenn zwei Dörfer oder explizit benannte Ortsteile durch beispielsweise eine Bahnlinie getrennt sind, dann hat jedes Dorf ein eigenes Polygon. Eine Strasse wird ja auch beliebig oft gesplittet um z.B. über Brücken zu führen ja. oder rechtlich Grenzen zu berücksichtigen. Das könnte man m.E. einfach durch die Grenzlinie dokumentieren. Die Strasse und die Grenze sind ganz unterschiedliche Klassen und sollten m.E. nicht durch gemeinsame Punkte verknüpft werden. Die Verknüpfung ist keine topologische, sondern eine virtuelle. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
qbert biker schrieb: Dem wird durch trunk (in der Verwendung für autobahnähnlich ausgebaut!) Rechnung getragen. Nein, da von trunk nur ein Teil erfasst wird. Fuer den einen muss es fast eine Autobahn sein, fuer den anderen reichen ein paar Bruecken und Abfahrten. Dabei fallen viele Darum schrieb ich auch in der Verwendung für autobahnähnlich ausgebaut!(mind.2Spuren je Richtung und Kreuzungsfrei) kreuzungsfrei ausgebaute Strecken durch, z.B. die typische Umgehungsstrasse mit einer Spur pro Richtung. Aber gerade die bringen oft einen erheblichen Vorteil. Typisch für Umgehungsstrassen ist auch dass sie häufig deutlich länger sind (um den Ort herum gebaut) und relativ stark frequentiert (auch mit Schwerverkehr) sind (sonst würde man keine Umghung bauen) so dass sich der erhebliche Vorteil wieder relativiert. Mehr als 80km/h im Schnitt sind da kaum drinn Ausserdem ist dem entstehenden Vorteil schon damit Rechnung getragen dass es keine Ortsdurchfahrt (maxspeed=50, egal ob jetzt explizit oder implizit ermittelt) ist Ohne Kenntniss vom tageszeit/wochentagsabhängigem Verkehrsaufkommen mehr als 100km/h als Durchschnittsgeschwindigkeit für den Router auf Autobahnabschnitten anzusetzen halte ich für realitätsfremd. Die erste Stufe, das statische Routing, nimmt die theoretisch erreichbare Geschwindigkeit nach den Verkehrsregeln. Die wird typischerweise bei der Autobahn mit 130 angesetzt, was oft real erreichbar ist. Ohne ein gutes statisches Reisezeitmodell als Basis zu haben, macht die Einbeziehung der Dynamik wenig Sinn 130 deshalb, weil das auf den Durschnittsfahrer gut passt. Sorry, dass ist absolut realitätsfremd! Wenn man die jeweilige Höchsgeschwindigkeit (bzw. Richtgeschwindigkeit bei Autobahnen) für den Router für den Durschnittsfahrer annimmt kommt man zwar wahrscheinlich auch zu einer geeigneten Route weil es realtiv zueinander wieder passt, aber die ermitteltete Reisezeit passt vorne und hinten nicht! Hier koennte OSM dann noch voll seine Vorteile ausspielen, da ja die Modellparameter offen fuer jeden sind. Man kann einen Porsche-Set bauen, einen Enduro-Set und natuerlich wie bisher Radfahrer und Fussgaenger usw. Das hat mit OSM nichts zu tun, dass ist eine Frage der Anwendungsapplikation und hat schon mit den ersten Navi-Systemen auf Notebook/PDA-Basis zur Jahrtausendwende funktioniert (Festeinbauten waren zu der Zeit für den Durschnittsfahrer noch fast unerschwinglich). Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
Am 29. Juni 2009 13:26 schrieb Markus liste12a4...@gmx.de: Mein Vorschlag ist ein grundsätzlicher: Gebäude stehen qua Definition immer auf einer Landfläche. Man braucht deshalb nicht extra in dieser Landfläche eine Grundfläche des Gebäudes /ausschneiden/ um dann dort das Gebäude hineinzusetzen. Hi! Für Landuse würde ich dir zustimmen, da geht es um eine Beschreibung der Flächennutzung. Ein Platz für Fußverkehr ist aber ein konkretes Objekt, das z.B. auch routing ermöglichen soll... Ich verstehe auch nicht, wieso diverse Leute hier Multipolygone immer so kompliziert reden... Es ist eigentlich eine ziemlich simple Angelegenheit. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] F: Park-Insel in Mapnik
Am 29. Juni 2009 07:54 schrieb Martin Simon grenzde...@gmail.com: Am 29. Juni 2009 02:29 schrieb Andreas Neumann andr-neum...@gmx.net: Mapnik ignoriert das layer-tag bei Flächen. Dieses Tag ist auch nicht dazu gedacht, die Zeichenreihenfolge anzugeben, sondern um die *reale* vertikale Lage von sich überschneidenden Objekten zueinander (Bsp.: Straße und Brücke über Straße, die Brücke erhält layer 1, die Straße keinen layer, also die Standardeinstellung von 0) festzulegen. Da die bei Flächen wie Park, Wald, See nicht sinnvoll ist, sollte hier eine Multipolygon-Relation[1] eingesetzt werden. Also den See als outer, die Insel als inner in die Relation eintragen - ich habe das bei dem See südlich der Straße mal gemacht und die Insel zusätzlich noch mit place=island markiert, damit auswertende Programme wissen, daß es sich um eine Insel handelt. ja, bei Inseln ist eine Multipolygon-Relation sinnvoll, bei vielen anderen Stellen, wo dieses Problem auftritt, jedoch nicht: ein Wald in einem Park sollte z.B. nicht per multipolygon aus dem Park ausgenommen werden, da der Wald ja auch Park ist (ansonsten würde man aussagen: der Wald ist nicht im Park). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
2009/6/29 Markus liste12a4...@gmx.de Hallo Garry, Ich schlage vor, dass Gebäude einfach auf eine Landfläche gesetzt werden (sie stehen ja auch auf dem Gelände) Falsch. Das Gebäude steht eindeutig nicht auf highway=pedestrian, sondern auf seiner eigenen Parzelle mit eigenen Zugangsrechten. Schon klar. Aber in besagtem Beispiel ist die Parzelle ja noch nicht in der DB. Mein Vorschlag ist ein grundsätzlicher: Gebäude stehen qua Definition immer auf einer Landfläche. Man braucht deshalb nicht extra in dieser Landfläche eine Grundfläche des Gebäudes /ausschneiden/ um dann dort das Gebäude hineinzusetzen. Doch, muss man. Wenn zum Beispiel jemand mal die Größe der Fußgängerzone (oder des Waldes) berechnen will, dann bekommt er ein Problem wenn das Gebäude einfach hineingesetzt ist. Also einfach das Gebäude auf den Wald draufklatschen oder auf das Industrie- oder Wohngebiet oder die Parzelle oder was auch immer. Also wo immer möglich keine Multipolygone mehr verwenden. (zumindest nicht auf Benutzerebene) wo ist das Problem die pedestrian -Fläche aus zwei Flächen zusammenzusetzen? Eine Fussgängerzone wird nicht dadurch zu zwei Fussgängerzonen, dass da ein Haus drin steht. Richtig Genausowenig wie aus einem Wald zwei Wälder werden, wenn dort ein Weg durchführt. Falsch, wenn man es genau nimmt. Ein Wald ist ein Wald, weil dort Bäume stehen. Auf einem Weg stehen keine Bäume, also gehört er nicht zum Wald. Anders ist es, wenn zwei Dörfer oder explizit benannte Ortsteile durch beispielsweise eine Bahnlinie getrennt sind, dann hat jedes Dorf ein eigenes Polygon. Eine Strasse wird ja auch beliebig oft gesplittet um z.B. über Brücken zu führen ja. oder rechtlich Grenzen zu berücksichtigen. Das könnte man m.E. einfach durch die Grenzlinie dokumentieren. Die Strasse und die Grenze sind ganz unterschiedliche Klassen und sollten m.E. nicht durch gemeinsame Punkte verknüpft werden. Die Verknüpfung ist keine topologische, sondern eine virtuelle. Gruss, Markus ___ 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] Deichscharte, war: Re: waterway=dam / OSM Inspector / water
Markus schrieb: Habe den Artikel etwas ausgebaut: http://de.wikipedia.org/wiki/Deichschart Ah... Ich suche also nun ein tag für Stöpe, falls wir das von barrier=dyke_opening unterscheiden wollen ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lummerland
Hallo, Chris-Hein Lunkhusen wrote: http://osm.org/go/ehqD76IOO== Lustig, aber natuerlich nichts, was auf Dauer drin bleiben sollte... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM als Beispiel für gescheiterte Basisd emokratie
Am 29. Juni 2009 09:17 schrieb Sven Sommerkamp s_sommerk...@gmx.de: Ein OSM mit mehreren Layern könnte Daten entflecheten und ermöglichen bsw. Navigation zuzuarbeiten oder Kartendartstellungen oder Seekarten oder Archäologischen Kartenusw. Dann könnte für die einzelnen Layer leichter bessere Regeln gefunden werden. dagegen. Mehrere (unabhängige) Layer führen dazu, dass die Daten untereinander inkonsistent werden. Um das zu vermeiden müsste man doch wieder alle Layer laden, im Endeffekt würde sich kein Vorteil sondern nur das Risiko ergeben, dass die Daten untereinander nicht mehr passen bzw. topologische Zusammenhänge verfälscht werden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
Am 29. Juni 2009 12:17 schrieb Peter Dörrie peter.doer...@googlemail.com: 2009/6/29 Markus liste12a4...@gmx.de Ich schlage vor, dass Gebäude einfach auf eine Landfläche gesetzt werden (sie stehen ja auch auf dem Gelände) Falsch. Das Gebäude steht eindeutig nicht auf highway=pedestrian, sonern auf seiner eigenen Parzelle mit eigenen Zugangsrechten. Somit ist ein Multipoligon vermutlich angebracht. +1, entweder multipolygon, oder die pedestrian-area aufteilen und drum rum führen. Dass das multipolygon-handling (noch) ziemlich aufwendig ist, kann kein Grund sein, es nicht richtig zu machen ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lummerland
On Mon, 29 Jun 2009, Frederik Ramm wrote: Chris-Hein Lunkhusen wrote: http://osm.org/go/ehqD76IOO== Lustig, aber natuerlich nichts, was auf Dauer drin bleiben sollte... Klar doch. Mitten im Ozean stört es nicht und es ist wirklich liebevoll gemacht. Außerdem ist das ein hübsches Easter-Egg. Ich habe es mir auf alle Fälle gesichert, falls es ein böser Rowdy löscht. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lummerland
Am Montag, 29. Juni 2009 13:41:36 schrieb Frederik Ramm: Hallo, Chris-Hein Lunkhusen wrote: http://osm.org/go/ehqD76IOO== Lustig, aber natuerlich nichts, was auf Dauer drin bleiben sollte... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Das wäre z.B. etwas für eine speziellen OSM Layer gewesen.. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lummerland
Hallo Chris-Hein, http://osm.org/go/ehqD76IOO== Da fehlt noch man_made=dyke oder man_made=pillar denn dort ist das Wasser etwa 4000 m tief... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aenderungen erschweren (war: Routerh?rtetest - Topologie oder STVO?)
Am 29. Juni 2009 09:26 schrieb Sven Sommerkamp s_sommerk...@gmx.de: - wieviele Daten kann die DB speichern immer mehr Mag sein, aber irgendwo ist eine gewisse Genauigkeit trotzdem beschränkt. Das ist wie beim JPG Bild, man muß einen Kompromiss aus einerseits gutaussehendem Bild und andererseits Dateigröße finden. Ansonsten ist die Bearbeitung nur noch mit Superrechnern möglich und das Speicher ab einer gewissen Bilderzahl schwierig. das war z.B. 1999 so, als ich meine erste homepage gebaut habe. Wenn ich heutzutage ein Bild speichere, wo's drauf ankommt (z.B. Druck), nehme ich entweder gleich png oder speichere das JPG als 100% Qualität. Und genauso würde ich OSM auch sehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lummerland
obwohl doch jeder weiß, dass das echte Lummerland bei Essen liegt (und kein Fake ist): http://osm.org/go/0GMEuZv81== Markus schrieb: Hallo Chris-Hein, http://osm.org/go/ehqD76IOO== Da fehlt noch man_made=dyke oder man_made=pillar denn dort ist das Wasser etwa 4000 m tief... Gruss, Markus ___ 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] Lummerland
On Mon, 29 Jun 2009, Markus wrote: http://osm.org/go/ehqD76IOO== Da fehlt noch man_made=dyke oder man_made=pillar denn dort ist das Wasser etwa 4000 m tief... Zumindest Neu-Lummerland war eine schwimmende Insel. Über die Gründung von Lummerland steht soweit mir bekannt ist nichts im Buch drin. Ist bestimmt eine Zacke eines unterseeischen Berges. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deichscharte, war: Re: waterway=dam / OSM Inspector / water
Hallo Heiko, Ich suche also nun ein tag für Stöpe, falls wir das von barrier=dyke_opening unterscheiden wollen ;-) Ja, das macht Sinn: Ein Deichtor kann man mit wenigen Handgriffen schnell schliessen. Um eine Stöpe zu schliessen braucht man eine ganze Feuerwehrmanschaft und einen Bagger und Füllmaterial und viele Mannarbeitsstunden. Gruss, Markus PS: vom Erfinden von Tags verstehe ich allerdings nicht so viel - zumal die ja eigentlich in Englisch sein sollen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
On Mon Jun 29, 2009 at 10:2745AM +0200, Sven Sommerkamp wrote: Am Montag, 29. Juni 2009 10:13:06 schrieb Michael Bergbauer: On Mon Jun 29, 2009 at 09:5108AM +0200, Sven Sommerkamp wrote: Vielleicht könnte man diese Probleme umgehen, wenn man mehrere Layer zur Verfügung hätte. Z.B. auch einen Experimentellen. Sowas haben wir doch: du kannst im Tag ja sowas wie nen Namensraum verwenden, z.B. alles mit EXPERIMENT: beginnen lassen (oder deinem Usernamen, oder ...) Und wenn man neue Sachen ausprobieren oder was demonstrieren will, dann setzt man die Tags doch erst mal nur zusaetzlich. Oder versteh ich da gerade was nicht? Nein, so meinte ich das nicht. Ich könnte mir vorstellen, das es vielleicht nicht nur den einen OSM Server in England gibt, oder altenativ doch nur den Einen aber mehrere OSM Datenbanken für unterschiedliche Anwendungen. Mehrere Datenbanken heisst (bei der Groesse des OSM-Datenbank), dass wir entweder deutlich 'groessere' Server brauchen oder aber die Datenbanken auf mehrere Server verteilen muessen. Problematisch dabei sind bereits die Indices auf den grossen Tabellen, diese muessen auf jeden Fall komplett im Speicher gecacht werden koennen um performanten Zugriff geweaehrleisten zu koennen. Im Editor können dann die Einzelnen Layer ein und ausgeblendet werden. Mit kann Daten von dem einen in den Anderen übernehmen Als Layer könnte ich mir dann vorstellen: OSM NAV Routingfähige Karte für Navigationsgeräte, z.B. Garmin, Navit, Gosmore... OSM MAP Gerenderte Karten OSM SEA Für Seekarten auch auf Navigationsgeräten OSM ARCH Für Freunde der Archäologie OSM HIST Historische Karten .. -Der Vorteil wäre, das weniger Datenverkehr entstünde. -Man könnte die Daten für den gedachten Zweck optimieren -Es käme der Übersicht beim Editieren zugute. -Trotz Spezialisierung hätte jeder Möglichkeiten seine Daten in OSM einzubringen Vielleicht brauchen wir nur bessere Editoren (und evtl. ne bessere API) um Namensraeume in den Tags auswaehlen zu koennen? -- Michael Bergbauer mich...@noname.franken.de Munich, Germany ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lummerland
Am Montag 29 Juni 2009 schrieb Chris-Hein Lunkhusen: http://osm.org/go/ehqD76IOO== ;-) Also im Moment sieht das ziemlich kaputt aus (in wasser versenkt), hat das jemand gescreenshottet als es noch ganz war? -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de http://schokokeks.org - professional webhosting signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Status xapi?
Hi, Wie ist denn grad der Status der osmxapi? Im Moment liefert keiner der im Wiki gelisteten Server ein Ergebnis und das seit gefühlt mind. ner Woche oder so. MfG, -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de http://schokokeks.org - professional webhosting signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lummerland
Zitat von Markus liste12a4...@gmx.de: http://osm.org/go/ehqD76IOO== denn dort ist das Wasser etwa 4000 m tief... Für Menschen ohne Phantasie mag das stimmen... Ich habe jedenfalls im Internet recherchiert und habe den Beweis gefunden, dass die Insel dort existiert: http://www.informationfreeway.org/?lat=47.886898lon=-17.401316zoom=17 Wer es nicht glaubt, sollte sich mal auf den Weg machen! Rotbarsch ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM als Beispiel für gescheiterte Basisd emokratie
Hallo Martin, Ein OSM mit mehreren Layern könnte Daten entflecheten dagegen. Mehrere (unabhängige) Layer führen dazu, dass die Daten untereinander inkonsistent werden. Sehr wahr. Dennoch könnte man die Daten virtuell in Layer gliedern/filtern. Damit man diese bedarfsgerecht nutzen kann. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von Orten
Am 29. Juni 2009 10:01 schrieb Markus liste12a4...@gmx.de: Hallo Johannes, EW als Kriterium Kannst Du das in Mapnik einbauen? wenn Du mir sagst, wie das geht :-( und ich dachte schon, Du kennst Dich da aus... Also: wer kann das umsetzen? Der Mapnik-Style wird in England von Kartographen gepflegt. Die sind guten Vorschlägen gegenüber durchaus aufgeschlossen, bauen aber auch nicht gerade alles ein, was mal eben so angefordert wird (aus berechtigter Angst vor Cluttering). Der offizielle Weg geht über ein Ticket im OSM-Trac mit Mapnik als Komponente. Falls Du das Ticket schreibst, könntest Du auch neben den EW die politisch-administrative Funktion (z.B. Hauptstadt eines Regierungsbezirks) als Kriterium mitaufführen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deichscharte, war: Re: waterway=dam / OSM Inspector / water
Hallo, am 29.06.2009 14:04 schrieb Markus: Hallo Heiko, Ich suche also nun ein tag für Stöpe, falls wir das von barrier=dyke_opening unterscheiden wollen ;-) Ja, das macht Sinn: Ein Deichtor kann man mit wenigen Handgriffen schnell schliessen. Um eine Stöpe zu schliessen braucht man eine ganze Feuerwehrmanschaft und einen Bagger und Füllmaterial und viele Mannarbeitsstunden. Treffer! Und das bedeutet, dass dyke_opening nicht ganz passt: Ein Loch im Deich (bzw. der Spundwand) haben wir in beiden Fällen. Der Unterschied besteht in der Art des Verschließens. Wir könne aber auch beschließen, die Unschärfe hinzunehmen. Für Wanderer und Fahrer ist es nur wichtig zu wissen: Da ist ein Loch in der Wand/im Wall, da komme ich durch, wenn nicht gerade Hochwasser droht oder geübt wird. Der Hochwasserschutz vor Ort weiß ohnehin, welcher Durchlass wie zu schließen ist. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM als Beispiel für gescheiterte Basisd emokratie
Am 29. Juni 2009 14:14 schrieb Markus liste12a4...@gmx.de: Ein OSM mit mehreren Layern könnte Daten entflecheten dagegen. Mehrere (unabhängige) Layer führen dazu, dass die Daten untereinander inkonsistent werden. Sehr wahr. Dennoch könnte man die Daten virtuell in Layer gliedern/filtern. Damit man diese bedarfsgerecht nutzen kann. ja, im Editor. Das ist sicher der bessere Weg. Da besteht dann zwar auch die Gefahr, dass man mal eine Straße so verschiebt, dass der Briefkasten die Seite wechselt, man features in einen Landuse einschließt, die dort nicht hingehören und ähnliches, aber wenn das hier schon seit längerem so intensiv gewünscht wird (potenzielle Erfordernis ist sicher stark kontext- / bzw. OSM-Dichte-abhängig), dann wird es vermutlich irgendwann auch kommen (Dirk ist ja dem Vernehmen nach auch dafür ;-) ). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
Am Montag, 29. Juni 2009 13:16:22 schrieb qbert biker: Original-Nachricht Datum: Mon, 29 Jun 2009 12:39:23 +0200 Von: Bernd Wurst be...@bwurst.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Vorschlag zum neutralen Mapping Hm. Die Frage muss doch erlaubt sein: Willst du Daten-Genauigkeit haben, die *EINEN VORTEIL BIETET* oder nur etwas, was theoretisch besser wäre? Einfache Antwort. Daten-Genauigkeit bietet immer Vorteile, aber nicht jeder Vorteil laesst sich sofort und jetzt realisieren. Ein Router verwendet alle Daten zwischen Start und Ziel und wird auch von allen Daten beeinflusst. Wie genau definierst du Datengenauigkeit? Wenn es einen Vorteil gibt, solltest du das in einem wie auch immer gearteten *PRAKTISCHEN* Beispiel demonstrieren. Ich kann versuchen, ein Verstaendnis dafuer zu wecken, dass exakte Beschreibung, Datenpraezision und Anwendungsentwicklung Hand in Hand gehen muessen und sich gegenseitig befruchten. Was ist in deinem Sinne Datenpräzision, mal ein Beispiel? Dass die Parameter genutzt werden *KÖNNEN* um eventuell irgendwo etwas *PRÄZISERE* Ergebnisse zu liefern steht außer Frage. Ich stelle nur nach wie vor in Frage, dass man das für irgendwelche *PRAKTISCHEN* Dinge *BRAUCHT*. Du redest grade mehr in Richtung Verifikation und Theoriemodelle. Das ist schon arg weit weg von etwas, was einen Mapper für mehr Datenerhebung begeistern würde. Modelle nicht Theoriemodelle. Das ist keine blanke Theorie, sondern steckt in jedem Navi drin. Ansonsten will ich die Mapper mehr dafuer begeistern, nach genaueren Definitionen zu arbeiten, weil sie dann mit weniger Arbeit mehr schaffen koennen. Das ganze hin und her ummappen, das viel zu oft passiert, loescht ja Informationen und ist sicher nicht motivierend. Mal im Zweifelsfall ein Tag mehr einzutragen, das eine ganz spezifische Eigenschaft beschreibt (z.B. dieser Bereich ist kreuzungsfrei) bleibt auch erhalten, wenn jemand die Klasse ummappt. Stand nur highway=trunk drin, ist sie weg, wenn jemand meint, es sei ein primary. Oder besser: Ich würde mir wünschen, dass jemand eine Anwendung vorstellt, die aus der Existenz detaillierter Daten direkt und in der Gegenwart einen Nutzen zieht, den ein normaler Mapper sehen kann. Das bleibt Wunschgedanke. Die Verbesserungen beim Routing werden nur bei sorgfaeltiger Verifikation sichtbar. Eine Einzelroute oder eine gut vorberechnete Reisezeit ist ein Hinweis, aber nur ein Einzelwert. Gruesse Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deichscharte, war: Re: waterway=dam / OSM Inspector / water
Am 29. Juni 2009 14:17 schrieb Norbert Kück o...@nk-bre.net: am 29.06.2009 14:04 schrieb Markus: Ich suche also nun ein tag für Stöpe, falls wir das von barrier=dyke_opening unterscheiden wollen ;-) Ja, das macht Sinn: Ein Deichtor kann man mit wenigen Handgriffen schnell schliessen. Um eine Stöpe zu schliessen braucht man eine ganze Feuerwehrmanschaft und einen Bagger und Füllmaterial und viele Mannarbeitsstunden. Treffer! Und das bedeutet, dass dyke_opening nicht ganz passt: Ein Loch im Deich (bzw. der Spundwand) haben wir in beiden Fällen. Der Unterschied besteht in der Art des Verschließens. Wir könne aber auch beschließen, die Unschärfe hinzunehmen. nö, würde ich nicht tun. Ihr habt die Unterschiede herausgearbeitet, sie sind nicht unerheblich, mit 2 klaren Vorschlägen kann man also die Gegebenheiten klar wiedergeben, wieso darauf verzichten? Man könnte ja z.B. auch einen Untertag dyke_opening:type machen, der die Art der Öffnung regelt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Historische Wege
Hallo miteinander, ich habe diese alte römische Straße als historic=archaeological_site getaggt: http://www.openstreetmap.org/browse/way/36351912 Leider ist dieses Tag für einzelne Nodes oder Flächen gedacht, d.h. die Straße erscheint nicht auf der Karte. Könnt ihr mir sagen, wie solche alten Straßen erfasst werden? Danke, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian? - Multiploygone
Martin Simon schrieb: Am 29. Juni 2009 13:26 schrieb Markus liste12a4...@gmx.de: Mein Vorschlag ist ein grundsätzlicher: Gebäude stehen qua Definition immer auf einer Landfläche. Man braucht deshalb nicht extra in dieser Landfläche eine Grundfläche des Gebäudes /ausschneiden/ um dann dort das Gebäude hineinzusetzen. Hi! Für Landuse würde ich dir zustimmen, da geht es um eine Beschreibung der Flächennutzung. Ein Platz für Fußverkehr ist aber ein konkretes Objekt, das z.B. auch routing ermöglichen soll... Ich verstehe auch nicht, wieso diverse Leute hier Multipolygone immer so kompliziert reden... Es ist eigentlich eine ziemlich simple Angelegenheit. Wie simple dass das ist zeigt sich immer wieder z.B. am Schwarzwald der regelmässig komplett im Wald ersäuft... Nur weil der Gebirgszug Schwarzwald heisst muss man daraus noch kein zusammenhängendes Waldgebiet machen... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mapping Party in den Dolomiten
Hallo, am 1. und 2. August findet in den Dolomiten eine Mapping-Party statt. Mehr Infos hier: http://wiki.openstreetmap.org/wiki/DE:Dolomiti_mapping_party Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag zum neutralen Mapping
Original-Nachricht Datum: Mon, 29 Jun 2009 13:36:09 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Vorschlag zum neutralen Mapping qbert biker schrieb: Darum schrieb ich auch in der Verwendung für autobahnähnlich ausgebaut!(mind.2Spuren je Richtung und Kreuzungsfrei) Eben, auf dieses _und_ kommts mir an. Es ergeben sich 4 kombinationen mit spezifischen Eigenschaften: 1 Spur ohne kreuzungsfreien Ausbau 2 oder mehr Spuren ohne kreuzungsfreien Ausbau 1 Spur mit Ausbau 2 oder mehr Spuren mit Ausbau Alle 4 Kombinationen haben eine eigene Charakteristik. Typisch für Umgehungsstrassen ist auch dass sie häufig deutlich länger sind (um den Ort herum gebaut) Das beruecksichtigt das Reisezeitmodell automatisch, denn die Strecke ist ja ein Basisparameter. und relativ stark frequentiert (auch mit Schwerverkehr) sind (sonst würde man keine Umghung bauen) so dass sich der erhebliche Vorteil wieder relativiert. Mehr als 80km/h im Schnitt sind da kaum drinn Das kann deine Erfahrung sein, ich habe andere gemacht. Aber es spielt ja auch keine Rolle, denn du kannst dir deinen Router nach persoenlichen Praeferenzen bis aufs i-Tuepfelchen abstimmen. Faehrst du lieber durch die Innenstadt, gerne. Sorry, dass ist absolut realitätsfremd! Dann trag bei dir 100 ein, bei mir waerens ca. 140-150. aber die ermitteltete Reisezeit passt vorne und hinten nicht! Probiers doch einfach aus, ich rede dir nicht rein. Ich habe nur ein paar Zahlen genannt, die sich bewaehrt haben. Das hat mit OSM nichts zu tun, dass ist eine Frage der Anwendungsapplikation Die Applikationen leben praktisch zu 100% von den Daten. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von Orten
Hallo, Markus wrote: :-( und ich dachte schon, Du kennst Dich da aus... Also: wer kann das umsetzen? Man kann in der osm.xml im Layer placenames (ca. ab Zeile 7017) statt Parameter name=tableplanet_osm_point/Parameter schreiben Parameter name=table(select way,name,capital from plant_osm_point where place is not null order by population desc)/Parameter Hierdurch erreicht man, dass die Orte innerhalb der einzelnen Styles absteigend nach Bevoelkerung durchgegangen werden. Innerhalb der einzelnen Styles heisst, dass immer noch alle cities vor allen towns gezeichnet werden, selbst wenn mal eine town mehr Einwohner haben sollte (was sehr wahrscheinlich ist, da der Grossteil der cities 0 Einwohner hat!). Ferner muss aber auch in der default.style von osm2pgsql dafuer gesorgt werden, dass die Bevoelkerungszahl ueberhaupt in die Datenbank uebernommen wird: # OsmType Tag DataType Flags node population int8 linear Datenbanken, die mittels slim mode Changesets nachfuehren, muessen dabei komplett neu initialisiert werden. Der hier beschreibene Schwerte-Fall resultiert vermutlich daher, dass eine wichtigere city in der Naehe von Schwerte einen laengeren Namen hatte, so dass dieser Name mit einer anderen city in Konflikt geriet und nicht gezeichnet wurde. Fuer das kleinere Schwerte war die Luecke dann spaeter noch gross genug. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM als Beispiel für gescheiterte Basisd emokratie
Am Montag, 29. Juni 2009 14:14:01 schrieb Markus: Hallo Martin, Ein OSM mit mehreren Layern könnte Daten entflecheten dagegen. Mehrere (unabhängige) Layer führen dazu, dass die Daten untereinander inkonsistent werden. Naja, unterschiedliche Verwendungen führen wohl zu unterschiedlichen Optimierungen der Daten. Das muß nicht unbedingt schlimm sein.. Eine Seekarte braucht z.B. keine Straßennamen, Bäcker und sonstige POI's sind auch nicht notwendig. Und eine routingfähige Straßenkarte braucht keine Seezeichen und keine Gebäudedarstellung. Eine Gerenderte Karte braucht keine totale Ortsgenauigkeit, sondern gute Lesbarkeit In kommerziellen Kartenwerken werden manchmal Informationen vereinfacht, und nicht immer ortsgenau dargestellt. Das sind nicht unbedingt Eastereggs. Übersichtlichkeit und Lesbarkeit steht bei diesen Karten berechtigter Weise im Vordergrund. Sehr wahr. Dennoch könnte man die Daten virtuell in Layer gliedern/filtern. Damit man diese bedarfsgerecht nutzen kann. Wenn das ein einfacher gehbarer Weg ist.. Ich bin da relativ Leidenschaftslos, es würde wohl dann Sinn machen, das diese für bestimmte Zwecke gepflegten Daten auch in getrennte Dateien fließen. Gruss, Markus Gruß Sven S. ___ 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] Status xapi?
Hallo Hanno, seit gefühlt mind. ner Woche oder so. hypercube hat einen Hardware-Schaden. Der Betreiber hat auf dev schon mehrmals um Hilfe gebeten, aber keine Reaktion erhalten. Jetzt greifen alle direkt auf die Abi zu... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM als Beispiel für gescheiterte Basi sdemokratie
Am 29. Juni 2009 14:40 schrieb Sven Sommerkamp s_sommerk...@gmx.de: Naja, unterschiedliche Verwendungen führen wohl zu unterschiedlichen Optimierungen der Daten. Das muß nicht unbedingt schlimm sein.. Eine Seekarte braucht z.B. keine Straßennamen, Bäcker und sonstige POI's sind auch nicht notwendig. In der Seefahrt spielen Bäcker eine wichtige Rolle. Stichwort: Brötchentütennavigation ;-) Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
Ich habe noch ein Beispiel welches bei Mapnik in der Zwischenzeit wieder falsch gerendert wird. (D.h. es sah schon einmal besser aus) http://osm.org/go/0m...@6um=?layers=0b00ftf Dort ist jedoch das die highway=pedestrian als Fläche wirklich unter dem Gebäude zu begehen, da es auf Säulen/Stützen steht. Es wurde dabei sogar layer=1 verwendet, da es ja wirklich eine Ebene über dem Boden ist, jedoch kann es Mapnik mit dem derzeitigen Stil nicht korrekt darstellen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Historische Wege
Am 29. Juni 2009 14:24 schrieb olvagor o...@terbrueggen.net: Hallo miteinander, ich habe diese alte römische Straße als historic=archaeological_site getaggt: http://www.openstreetmap.org/browse/way/36351912 Leider ist dieses Tag für einzelne Nodes oder Flächen gedacht, d.h. die Straße erscheint nicht auf der Karte. Könnt ihr mir sagen, wie solche alten Straßen erfasst werden? Da haben wir leider nach meiner Kenntnis noch nichts. Es sind Bestrebungen im Gange, in diesem Bereich eine ganze Reihe neuer Tags zu erfinden, wenn es mehr gibt, werde ich es hier posten. U.A. geht es dabei auch um Thermen, Aquädukte, (Amphit-)Theater, Tempel, historische Hafenanlagen, Brücken, etc. Falls die Straße noch irgendwie passierbar ist (und dies z.B. nicht verboten ist), würde ich sie je nach Zustand als Track oder footway eintragen (oder path, keine Ahnung, wofür das verwendet wird). Du könntest auch zusätzlich eine Ruine vergeben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Martin Koppenhoefer schrieb: Am 26. Juni 2009 17:15 schrieb Heiko Jacobs heiko.jac...@gmx.de: Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch spontanes zurücktaggen nicht verbauen ;-) m.E. sollte man solche autodidaktischen Versuche offline machen, und nicht in den Daten aller löschen, mal sehen was passiert, und wenn sich einige Gegenstimmen mit berechtigten Argumenten melden, weilterhin Beharrungsvermögen zeigen. Du vergisst bei dem Thema ständig, dass die cycleway=*-Variante eine derzeit zulässige Variante ist, auch wenn Dir diese Variante nicht gefällt. Solange sie zulässig ist, sollte alles getan werden, die Unterstützung durch Router zu verbessern. Entweder brauchen wir völlig neue Renderer, ansonsten können wir vernünftiges Radwegerendering vergessen (in beiden Modellen, einseitige im einen Modell, nichtüberlappend im anderen Modell) solange der Radweg oben liegt, finde ich die Überlappung nicht schlimm ... was eine ziemlich radfahrzentrierte Sichtweise ist. Ein Autofahrer dürfte sich durch eine solche Darstellung ziemlich gestört fühlen... Für die opencyclemap ist das Problem so meinetwegen gelöst, aber für die halbwegs an alle gerichtete slippy map geht das so nicht. So wie bisher ist es aber auch nicht optimal... und bin mir nicht sicher, ob eine verschobene Geometrie in allen Fällen vernünftiger wäre. Schon eher sicher bin ich mir, dass ich in einem Radwege-rendering eher die Straße verschieben würde als den Radweg. Auch das ist ein eziemlich radfahrzentrierte Sicht, die schon dann nicht mehr funktioniert, wenn beiderseits Radwege existieren... Deswegen verdrängt man normalerweise von der Mitte her. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
Am 29. Juni 2009 14:52 schrieb André Riedel riedel.an...@gmail.com: Ich habe noch ein Beispiel welches bei Mapnik in der Zwischenzeit wieder falsch gerendert wird. (D.h. es sah schon einmal besser aus) http://osm.org/go/0m...@6um=?layers=0b00ftf Dort ist jedoch das die highway=pedestrian als Fläche wirklich unter dem Gebäude zu begehen, da es auf Säulen/Stützen steht. Es wurde dabei sogar layer=1 verwendet, da es ja wirklich eine Ebene über dem Boden ist, jedoch kann es Mapnik mit dem derzeitigen Stil nicht korrekt darstellen. ja, klarer Renderfehler, würde ich ein Trac-Ticket mapnik erstellen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hat jemand ein gutes Foto von einer Bund esstraßen Anschlußstelle?
So etwas fehlt noch auf der http://wiki.openstreetmap.org/wiki/DE:Map_Features. Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Party in den Dolomiten
Hallo Martin, am 1. und 2. August http://wiki.openstreetmap.org/wiki/DE:Dolomiti_mapping_party Super Idee! denkt an den barometrischen Höhenmesser: http://wiki.openstreetmap.org/wiki/DE:Altitude Damit das Höhenmodell verfeinert werden kann... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM als Beispiel für gescheiterte Basisd emokratie
Am 29. Juni 2009 14:40 schrieb Sven Sommerkamp s_sommerk...@gmx.de: Ein OSM mit mehreren Layern könnte Daten entflecheten dagegen. Mehrere (unabhängige) Layer führen dazu, dass die Daten untereinander inkonsistent werden. Naja, unterschiedliche Verwendungen führen wohl zu unterschiedlichen Optimierungen der Daten. Das muß nicht unbedingt schlimm sein.. genau, das ist im Gegenteil sogar erwünscht, sollte aber gem. dem OSM-Credo nicht in der Datenbank stattfinden, sondern in der Auswertung/Darstellung. Eine Seekarte braucht z.B. keine Straßennamen, Bäcker und sonstige POI's sind auch nicht notwendig. ja, aber wenn Du im Straßenbereich editierst, wirst Du auch keine Seezeichen zu sehen bekommen (da diese auf See/am Wasser sind), d.h. es kann Dir egal sein. Und eine routingfähige Straßenkarte braucht keine Seezeichen und keine Gebäudedarstellung. dito für Seezeichen, -1 für Gebäudedarstellung. Vielleicht braucht _Deine_ Straßenkarte keine Gebäude, meine schon. Eine Gerenderte Karte braucht keine totale Ortsgenauigkeit, sondern gute Lesbarkeit -1, es kommt auf den Zweck/ die Intention an. Das mappen wir (zum Glück) nicht explizit, daher s.o.: pre-/postprocessing beim Anwender, nicht in der Datenbank. In kommerziellen Kartenwerken werden manchmal Informationen vereinfacht, und nicht immer ortsgenau dargestellt. ja. Und? Wir zeichnen ja keine Karte, auch wenn das immer mal wieder so dargestellt wird. Dennoch könnte man die Daten virtuell in Layer gliedern/filtern. Damit man diese bedarfsgerecht nutzen kann. Wenn das ein einfacher gehbarer Weg ist.. Ich bin da relativ Leidenschaftslos, es würde wohl dann Sinn machen, das diese für bestimmte Zwecke gepflegten Daten auch in getrennte Dateien fließen. Vielleicht verstehe ich Dich ja auch falsch. Meinst Du z.B., ein Node/POI könnte zusätzlich eine Information/Tag für den Renderer bekommen wie z.B: rendern bis Zoom 10, bzw. Renderpriorität 7? So was könnte man ja durchaus machen (oder z.B. einen Node, der explizit die Position der Beschriftung angibt, wie man es auch bei einer manuell erstellten Karte machen würde). Die Renderer wären ja trotzdem frei, diese Zusatz-Informationen zu verwenden oder zu verwerfen. Wenn Du dagegen meinst, wir sollten die Straßen einmal für den Renderer und einmal für den Router zeichnen und jeweils separat in verschiedenen Datenbanken ablegen, dann wird das (hoffentlich) nicht kommen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian?
Martin Koppenhoefer schrieb: ja, klarer Renderfehler, würde ich ein Trac-Ticket mapnik erstellen. das gibt es schon: http://trac.openstreetmap.org/ticket/1971 noch ein nettes Beispiel dazu: http://osm.org/go/0DgRStnlZ== Der Gebäudeteil, der in Mapnik fehlt, steht auf Betonstützen über dem Boden, hängt also eindeutig in der Luft. Etwas weiter Süd-östlich ist noch ein zweiter Fall (BlueBoxx) zu finden. Wie bereits vorgeschlagen, wäre ein halbtransparentes Gebäuderendering in diesen Fällen vermutlich das richtige, um keine Infos zu verlieren. Grüße ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Am 29. Juni 2009 14:54 schrieb Heiko Jacobs heiko.jac...@gmx.de: Du vergisst bei dem Thema ständig, dass die cycleway=*-Variante eine derzeit zulässige Variante ist, auch wenn Dir diese Variante nicht gefällt. Solange sie zulässig ist, sollte alles getan werden, die Unterstützung durch Router zu verbessern. Zulässig ist alles, was nicht schadet, diese Grenze hast Du hier überschritten. Das übersiehst Du. Ich habe natürlich überhaupt nichts dagegen, das Routing zu verbessern, aber bitte nicht dadurch, dass der Leidensdruck durch Zerstören funktionierender Lösungen erhöht wird. Entweder brauchen wir völlig neue Renderer, ansonsten können wir vernünftiges Radwegerendering vergessen (in beiden Modellen, einseitige im einen Modell, nichtüberlappend im anderen Modell) solange der Radweg oben liegt, finde ich die Überlappung nicht schlimm ... was eine ziemlich radfahrzentrierte Sichtweise ist. wenn Du Dir den Post ansiehst, ging es mir um Radfahrerkarten. Bei den anderen Karten liegt der cycleway AFAIR immer unten. und bin mir nicht sicher, ob eine verschobene Geometrie in allen Fällen vernünftiger wäre. Schon eher sicher bin ich mir, dass ich in einem Radwege-rendering eher die Straße verschieben würde als den Radweg. Auch das ist ein eziemlich radfahrzentrierte Sicht, ja, ist doch berechtigt, wenn wir von Fahrradkarten sprechen, oder? die schon dann nicht mehr funktioniert, wenn beiderseits Radwege existieren... kommt auf die Straßenbreite und die Zoomstufe an. In niedrigen Zoomstufen könnte auch die Mittellinie beider Radwege interpoliert werden und von dieser aus jeweils ein Offset nach aussen (geht ja aber sowieso derzeit nicht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude auf highway=pedestrian? - Mu ltiploygone
Am 29. Juni 2009 14:27 schrieb Garry garr...@gmx.de: Wie simple dass das ist zeigt sich immer wieder z.B. am Schwarzwald der regelmässig komplett im Wald ersäuft... Nur weil der Gebirgszug Schwarzwald heisst muss man daraus noch kein zusammenhängendes Waldgebiet machen... das stimmt. Allerdings wäre es sehr schön, eine zusätzliche Möglichkeit (z.B. Polygon und daraus abgeleitet die Größe und Ausrichtung des Schriftzugs / Sichtbarkeit in versch. Zoomstufen) zu haben, um die Namen, die auf physischen Karten üblicherweise auftauchen (Meernamen, Gebirge, Täler, größere Wälder, etc.) auch entsprechend darstellen zu können, z.B. Schwarzwald, Schwäbische Alb, Fichtelgebirge, Dolomiten, etc. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
