[Talk-transit] NaPTAN - Time for the rest?
Hello all, It's now been more than a year since we got permission to import the NaPTAN dataset, so far only 53 of the 143 counties that we have the data for have been imported. So, in short, is it time for the rest to be dumped in? Discussion please. Regards, Thomas ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN - Time for the rest?
That certainly sounds good to me. Along those lines, what are the chances of importing updated data from a newer edition of NaPTAN for the existing regions? In London I know of several areas where bus stops have been relocated/reconfigured recently (Camden Town, South Kensington) so OSM is already out of date. I've mentioned this before, but the other thing I'd really like to see imported from NapTAN is the pedestrian entry/exit locations for rail and tube stations! Bryce On Sat, Mar 13, 2010 at 12:44 PM, Thomas Wood grand.edgemas...@gmail.com wrote: Hello all, It's now been more than a year since we got permission to import the NaPTAN dataset, so far only 53 of the 143 counties that we have the data for have been imported. So, in short, is it time for the rest to be dumped in? Discussion please. Regards, Thomas ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN - Time for the rest?
Thomas If you want a refresh of the NaPTAN dataset, then just ask me and I will arrange for this be made available. I appreciate that this could be a two-edged sword it would update the data, but in the areas where work has already been done on the data from a year ago, it may over-write any local edits made to that data - or has this already been taken into account, so that new data would sit alongside existing data and would only be accepted if it is appropriate at each location? Cheers Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Thomas Wood Sent: 13 March 2010 12:45 PM To: osm; OSM - Talk GB Subject: [Talk-transit] NaPTAN - Time for the rest? Hello all, It's now been more than a year since we got permission to import the NaPTAN dataset, so far only 53 of the 143 counties that we have the data for have been imported. So, in short, is it time for the rest to be dumped in? Discussion please. Regards, Thomas ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN - Time for the rest?
I would certainly hope that any updates are not used to overwrite existing local edits. I have spent far too many hours checking and updating the data to have a newer version overwrite it. A smart merge would be more useful, I would write it if required. As too 'dumping in' the remaining county data I would prefer that it is handled locally where possible. The NaPTAN data is useful and good in parts but needs checking and improving too. I think too much data is imported just because it is available - I prefer imports to add value. NaPTAN can add value but that is best realised by someone local to the import managing it. Cheers, Chris Roger Slevin wrote: Thomas If you want a refresh of the NaPTAN dataset, then just ask me and I will arrange for this be made available. I appreciate that this could be a two-edged sword it would update the data, but in the areas where work has already been done on the data from a year ago, it may over-write any local edits made to that data - or has this already been taken into account, so that new data would sit alongside existing data and would only be accepted if it is appropriate at each location? Cheers Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Thomas Wood Sent: 13 March 2010 12:45 PM To: osm; OSM - Talk GB Subject: [Talk-transit] NaPTAN - Time for the rest? Hello all, It's now been more than a year since we got permission to import the NaPTAN dataset, so far only 53 of the 143 counties that we have the data for have been imported. So, in short, is it time for the rest to be dumped in? Discussion please. Regards, Thomas ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [talk-ph] Announcing: OSM-PH Marikina Mapping Party
I like the German flyer. I can probably create something like it but who will print it? On Fri, Mar 12, 2010 at 10:48 PM, Andre Marcelo-Tanner an...@enthropia.comwrote: Should we create an Philippine version of the OSM Info Flyers here: http://www.openstreetmap.de/img/flyer-big.jpg and http://svn.openstreetmap.org/misc/pr_material/english_flyer_ajr_2008-04/OSMFlyer-English.pdf and I like the German version. Translation is here: http://svn.openstreetmap.org/misc/pr_material/german_flyer_2009_03/TRANSLATION or maybe a modified version of http://svn.openstreetmap.org/misc/pr_material/recruitment_poster/poster.png which I think maning posted? To give out to newbies and people at the mall passing by or who might be interested in wth were doing? Andre ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Announcing: OSM-PH Marikina Mapping Party
Hi! Here are some drafts for the banner. http://sorbisorbi.wikispaces.com/file/view/banner-300x75cm_wb.jpg/ http://sorbisorbi.wikispaces.com/file/view/banner-300x75cm_fc.jpg On Thu, Mar 11, 2010 at 7:58 PM, maning sambale emmanuel.samb...@gmail.comwrote: Hi, One week to go for the Marikina Mapping Party. For those interested, please confirm here: http://wiki.openstreetmap.org/wiki/WikiProject_Philippines/Mapping_Party/Marikina or here http://www.facebook.com/event.php?eid=325986027476#!/event.php?eid=325986027476ref=ts I need a list of experienced OSMers so that we can pair them with the newbies fieldwork. If you will bring a GPS unit or a laptop, let me know. Planning page is here: http://wiki.openstreetmap.org/wiki/WikiProject_Philippines/Mapping_Party/Marikina/Planning If anyone, wants to help please do. Specifically: 1. Banner design 2. A simple pamphlet to give newbies a rough introduction to OpenStreetMap and the scheduled activities for the day cheers, maning On Sun, Feb 28, 2010 at 9:42 PM, Eugene Alvin Villar sea...@gmail.com wrote: One problem we'll have is where in SM City Marikina do we plan to hold the editing sessions. I think we may need to get a reservation somewhere and where there are power outlets for the laptops. On Sun, Feb 28, 2010 at 8:31 PM, maning sambale emmanuel.samb...@gmail.com wrote: In regards to the event, where would we be meeting exactly, what if someone had no internet but wanted to join, they couldnt just go to those big malls, an exact location is needed too maybe. I intend to visit the venue this week to locate the exact meeting place (+- 10 meters) Andre ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Announcing: OSM-PH Marikina Mapping Party
Banner design: let's just reuse one of the standard designs: http://weait.com/files/banner.png On Thu, Mar 11, 2010 at 7:58 PM, maning sambale emmanuel.samb...@gmail.comwrote: Hi, One week to go for the Marikina Mapping Party. For those interested, please confirm here: http://wiki.openstreetmap.org/wiki/WikiProject_Philippines/Mapping_Party/Marikina or here http://www.facebook.com/event.php?eid=325986027476#!/event.php?eid=325986027476ref=tshttp://www.facebook.com/event.php?eid=325986027476#%21/event.php?eid=325986027476ref=ts I need a list of experienced OSMers so that we can pair them with the newbies fieldwork. If you will bring a GPS unit or a laptop, let me know. Planning page is here: http://wiki.openstreetmap.org/wiki/WikiProject_Philippines/Mapping_Party/Marikina/Planning If anyone, wants to help please do. Specifically: 1. Banner design 2. A simple pamphlet to give newbies a rough introduction to OpenStreetMap and the scheduled activities for the day cheers, maning On Sun, Feb 28, 2010 at 9:42 PM, Eugene Alvin Villar sea...@gmail.com wrote: One problem we'll have is where in SM City Marikina do we plan to hold the editing sessions. I think we may need to get a reservation somewhere and where there are power outlets for the laptops. On Sun, Feb 28, 2010 at 8:31 PM, maning sambale emmanuel.samb...@gmail.com wrote: In regards to the event, where would we be meeting exactly, what if someone had no internet but wanted to join, they couldnt just go to those big malls, an exact location is needed too maybe. I intend to visit the venue this week to locate the exact meeting place (+- 10 meters) Andre ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] Freemap - OpenStreetMap for walkers (hikers) - feature ideas?
Hi, Walking isn't just about long-distance stuff. Being able to say: x is my starting point and I have [10|30|60mins|...] and I am [slow as a snail|average|running from mad mappers], please take me on a circular route that avoids busy roads, goes through nice parks, maybe goes to places people marked as good viewpoints, and accounts for me being slow uphill. If you have an algorithm which does that you should be able to add: x is my starting point and I have [10|30|60mins|...] and I am [slow as a snail|average|a mad mapper running], please take me on a circular route that covers some entries in OpenStreetBugs, preferably going along streets which have buildings tagged but no house numbers. Patrick Petschge Kilian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM for walkers / hikers - getting it going!
So mtb:scale=5 would be a vertical cliff? Have you seen the video that plays in the Blacks outdoor shops?? Yes would be the answer! Incredible. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] First drop in planet size ?
Nic Roets wrote: (since we got rid of the segments) From 8.2 GB to 8.1 GB: http://planet.openstreetmap.org/ Maybe something is wrong with it. I don't know if anybody has the same problem but I can't manage to complete an extract with osmosis. I'm doing the same thing as everytime and it doesn't work. I tried downloading it again, nothing, another version of osmosis, nothing, another version of .poly, nothing. At the moment I'm waiting for it to extract from bz2 and try again, maybe it's just bz2 ... error: SEVERE: Thread for task 1-read-xml failed org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to parse xml file /dev/stdin. publicId=(null), systemId=(null), lineNumber=529642199, columnNumber=27. osmosis: bzip2 -d -c planet-100310.osm.bz2 | osmosis/bin/osmosis --read-xml /dev/stdin --bounding-polygon clipIncompleteEntities=true file=croatia50km.poly --write-xml file=- | bzip2 -c 20100310-croatia50km.osm.bz2 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] First drop in planet size ?
There's a bug in the code that generated this week's planet. You should either wait until next week or filter the planet with the following command: bzcat /osm/planet-10*.osm.bz2 |egrep -v '#[0-9]*;'|... There has been a long discussion on 'dev', mentioning other remedies. On Sat, Mar 13, 2010 at 6:29 PM, hbogner hbog...@gmail.com wrote: Nic Roets wrote: (since we got rid of the segments) From 8.2 GB to 8.1 GB: http://planet.openstreetmap.org/ Maybe something is wrong with it. I don't know if anybody has the same problem but I can't manage to complete an extract with osmosis. I'm doing the same thing as everytime and it doesn't work. I tried downloading it again, nothing, another version of osmosis, nothing, another version of .poly, nothing. At the moment I'm waiting for it to extract from bz2 and try again, maybe it's just bz2 ... error: SEVERE: Thread for task 1-read-xml failed org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to parse xml file /dev/stdin. publicId=(null), systemId=(null), lineNumber=529642199, columnNumber=27. osmosis: bzip2 -d -c planet-100310.osm.bz2 | osmosis/bin/osmosis --read-xml /dev/stdin --bounding-polygon clipIncompleteEntities=true file=croatia50km.poly --write-xml file=- | bzip2 -c 20100310-croatia50km.osm.bz2 ___ 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] First drop in planet size ?
Thx for help, I'll try it. Now I have to follow 'dev' too :D Nic Roets wrote: There's a bug in the code that generated this week's planet. You should either wait until next week or filter the planet with the following command: bzcat /osm/planet-10*.osm.bz2 |egrep -v '#[0-9]*;'|... There has been a long discussion on 'dev', mentioning other remedies. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] First drop in planet size ?
Will this also be a problem if you try to import via osm2pgsql into postgres? Thanks, John On 3/13/10, hbogner hbog...@gmail.com wrote: Thx for help, I'll try it. Now I have to follow 'dev' too :D Nic Roets wrote: There's a bug in the code that generated this week's planet. You should either wait until next week or filter the planet with the following command: bzcat /osm/planet-10*.osm.bz2 |egrep -v '#[0-9]*;'|... There has been a long discussion on 'dev', mentioning other remedies. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- John J. Mitchell ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] First drop in planet size ?
My understanding is that all Xml compliant* parsers will abort at the file offsets that Frederik mentions. My advice is to use the egrep filter when in doubt, because you will loose no more than a dozen lines in a planet file of billions of lines. *: (My split program is not compliant and will happily ignore these errors: http://trac.openstreetmap.org/browser/applications/rendering/gosmore/bboxSplit.cpp) On Sat, Mar 13, 2010 at 7:44 PM, John Mitchell mitchellj...@gmail.com wrote: Will this also be a problem if you try to import via osm2pgsql into postgres? Thanks, John On 3/13/10, hbogner hbog...@gmail.com wrote: Thx for help, I'll try it. Now I have to follow 'dev' too :D Nic Roets wrote: There's a bug in the code that generated this week's planet. You should either wait until next week or filter the planet with the following command: bzcat /osm/planet-10*.osm.bz2 |egrep -v '#[0-9]*;'|... There has been a long discussion on 'dev', mentioning other remedies. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- John J. Mitchell ___ 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] First drop in planet size ?
That is very deep c++ code! care to comment on how it works? would be very interested to understand its performance ! looks very fast. mike On Sat, Mar 13, 2010 at 7:06 PM, Nic Roets nro...@gmail.com wrote: My understanding is that all Xml compliant* parsers will abort at the file offsets that Frederik mentions. My advice is to use the egrep filter when in doubt, because you will loose no more than a dozen lines in a planet file of billions of lines. *: (My split program is not compliant and will happily ignore these errors: http://trac.openstreetmap.org/browser/applications/rendering/gosmore/bboxSplit.cpp ) On Sat, Mar 13, 2010 at 7:44 PM, John Mitchell mitchellj...@gmail.com wrote: Will this also be a problem if you try to import via osm2pgsql into postgres? Thanks, John On 3/13/10, hbogner hbog...@gmail.com wrote: Thx for help, I'll try it. Now I have to follow 'dev' too :D Nic Roets wrote: There's a bug in the code that generated this week's planet. You should either wait until next week or filter the planet with the following command: bzcat /osm/planet-10*.osm.bz2 |egrep -v '#[0-9]*;'|... There has been a long discussion on 'dev', mentioning other remedies. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- John J. Mitchell ___ 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
Re: [OSM-talk] First drop in planet size ?
Hello James, I wanted to split the planet into overlapping bboxes like this (click to see actual size): http://dev.openstreetmap.de/gosmore/ On talk I described how I was dissatisfied with osmosis's memory consumption. So I came up with this observation: Most entities will end up in one or two extracts. And when it's two, it's in a pattern that is often repeated, say Africa bbox and Middle East bbox. Never Africa and Canada. So of the 2^168 possible combinations only around 3000 is actually used. So bboxSplit allocates 16 bits for each entity. Those are then indexes into the array of 'youniouns'. If a new node comes along, I check it against list of bboxes and it typically matches 1 or 2. So to find out quickly if I already have that combination of bboxes, I also have an STL map on the array of younions. A hashtable would have been faster. Ways and relations also trigger the code that merge younions. bboxSplit is faster than the corresponding bunzip and any program that uses libxml, i.e. very fast. Regards, Nic On Sat, Mar 13, 2010 at 10:03 PM, jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com wrote: That is very deep c++ code! care to comment on how it works? would be very interested to understand its performance ! looks very fast. mike On Sat, Mar 13, 2010 at 7:06 PM, Nic Roets nro...@gmail.com wrote: My understanding is that all Xml compliant* parsers will abort at the file offsets that Frederik mentions. My advice is to use the egrep filter when in doubt, because you will loose no more than a dozen lines in a planet file of billions of lines. *: (My split program is not compliant and will happily ignore these errors: http://trac.openstreetmap.org/browser/applications/rendering/gosmore/bboxSplit.cpp) On Sat, Mar 13, 2010 at 7:44 PM, John Mitchell mitchellj...@gmail.com wrote: Will this also be a problem if you try to import via osm2pgsql into postgres? Thanks, John On 3/13/10, hbogner hbog...@gmail.com wrote: Thx for help, I'll try it. Now I have to follow 'dev' too :D Nic Roets wrote: There's a bug in the code that generated this week's planet. You should either wait until next week or filter the planet with the following command: bzcat /osm/planet-10*.osm.bz2 |egrep -v '#[0-9]*;'|... There has been a long discussion on 'dev', mentioning other remedies. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- John J. Mitchell ___ 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
Re: [OSM-talk] First drop in planet size ?
you are bunziping the code ? you are scanning the bzip blocks? it is faster than the bunzip. But maybe you mean that it is very fast. I have experimented with bziprecover to extract blocks on their own, i made a perl script to extract blocks from a wikipedia file that can be used to run the processing of the huge file by many people in parallel. https://code.launchpad.net/~jamesmikedupont/+junk/openstreetmap-wikipedia It is a tool to extract lat/long coords from the wikipedia articles. Such a processing of the large files would allow us to team up and all help. We really need to just have an index file of all the blocks so that we can find the ones that we need. Imagine being able to process the bzip file directly! mike On Sat, Mar 13, 2010 at 9:31 PM, Nic Roets nro...@gmail.com wrote: Hello James, I wanted to split the planet into overlapping bboxes like this (click to see actual size): http://dev.openstreetmap.de/gosmore/ On talk I described how I was dissatisfied with osmosis's memory consumption. So I came up with this observation: Most entities will end up in one or two extracts. And when it's two, it's in a pattern that is often repeated, say Africa bbox and Middle East bbox. Never Africa and Canada. So of the 2^168 possible combinations only around 3000 is actually used. So bboxSplit allocates 16 bits for each entity. Those are then indexes into the array of 'youniouns'. If a new node comes along, I check it against list of bboxes and it typically matches 1 or 2. So to find out quickly if I already have that combination of bboxes, I also have an STL map on the array of younions. A hashtable would have been faster. Ways and relations also trigger the code that merge younions. bboxSplit is faster than the corresponding bunzip and any program that uses libxml, i.e. very fast. Regards, Nic On Sat, Mar 13, 2010 at 10:03 PM, jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com wrote: That is very deep c++ code! care to comment on how it works? would be very interested to understand its performance ! looks very fast. mike On Sat, Mar 13, 2010 at 7:06 PM, Nic Roets nro...@gmail.com wrote: My understanding is that all Xml compliant* parsers will abort at the file offsets that Frederik mentions. My advice is to use the egrep filter when in doubt, because you will loose no more than a dozen lines in a planet file of billions of lines. *: (My split program is not compliant and will happily ignore these errors: http://trac.openstreetmap.org/browser/applications/rendering/gosmore/bboxSplit.cpp ) On Sat, Mar 13, 2010 at 7:44 PM, John Mitchell mitchellj...@gmail.com wrote: Will this also be a problem if you try to import via osm2pgsql into postgres? Thanks, John On 3/13/10, hbogner hbog...@gmail.com wrote: Thx for help, I'll try it. Now I have to follow 'dev' too :D Nic Roets wrote: There's a bug in the code that generated this week's planet. You should either wait until next week or filter the planet with the following command: bzcat /osm/planet-10*.osm.bz2 |egrep -v '#[0-9]*;'|... There has been a long discussion on 'dev', mentioning other remedies. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- John J. Mitchell ___ 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
Re: [OSM-talk] First drop in planet size ?
No. It runs on the uncompressed planet, like this : bzcat /osm/planet-10*.osm.bz2 | /osm/gosmore/bboxSplit \ -85.05113 73.125009.44906 180.0 gzip 0720048510241024.osm.gz \ -25.48295 120.58594 72.91964 180.0 gzip 0855020310240587.osm.gz \ -85.05113 98.43750 13.23995 172.61719 gzip 0792047410031024.osm.gz \ ... I'm not too worried about further optimizations: Unlike wikipedia, there isn't the same urgency to have up-to-date. Except for disaster relief. On Sat, Mar 13, 2010 at 10:42 PM, jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com wrote: you are bunziping the code ? you are scanning the bzip blocks? it is faster than the bunzip. But maybe you mean that it is very fast. I have experimented with bziprecover to extract blocks on their own, i made a perl script to extract blocks from a wikipedia file that can be used to run the processing of the huge file by many people in parallel. https://code.launchpad.net/~jamesmikedupont/+junk/openstreetmap-wikipedia It is a tool to extract lat/long coords from the wikipedia articles. Such a processing of the large files would allow us to team up and all help. We really need to just have an index file of all the blocks so that we can find the ones that we need. Imagine being able to process the bzip file directly! mike On Sat, Mar 13, 2010 at 9:31 PM, Nic Roets nro...@gmail.com wrote: Hello James, I wanted to split the planet into overlapping bboxes like this (click to see actual size): http://dev.openstreetmap.de/gosmore/ On talk I described how I was dissatisfied with osmosis's memory consumption. So I came up with this observation: Most entities will end up in one or two extracts. And when it's two, it's in a pattern that is often repeated, say Africa bbox and Middle East bbox. Never Africa and Canada. So of the 2^168 possible combinations only around 3000 is actually used. So bboxSplit allocates 16 bits for each entity. Those are then indexes into the array of 'youniouns'. If a new node comes along, I check it against list of bboxes and it typically matches 1 or 2. So to find out quickly if I already have that combination of bboxes, I also have an STL map on the array of younions. A hashtable would have been faster. Ways and relations also trigger the code that merge younions. bboxSplit is faster than the corresponding bunzip and any program that uses libxml, i.e. very fast. Regards, Nic On Sat, Mar 13, 2010 at 10:03 PM, jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com wrote: That is very deep c++ code! care to comment on how it works? would be very interested to understand its performance ! looks very fast. mike On Sat, Mar 13, 2010 at 7:06 PM, Nic Roets nro...@gmail.com wrote: My understanding is that all Xml compliant* parsers will abort at the file offsets that Frederik mentions. My advice is to use the egrep filter when in doubt, because you will loose no more than a dozen lines in a planet file of billions of lines. *: (My split program is not compliant and will happily ignore these errors: http://trac.openstreetmap.org/browser/applications/rendering/gosmore/bboxSplit.cpp) On Sat, Mar 13, 2010 at 7:44 PM, John Mitchell mitchellj...@gmail.com wrote: Will this also be a problem if you try to import via osm2pgsql into postgres? Thanks, John On 3/13/10, hbogner hbog...@gmail.com wrote: Thx for help, I'll try it. Now I have to follow 'dev' too :D Nic Roets wrote: There's a bug in the code that generated this week's planet. You should either wait until next week or filter the planet with the following command: bzcat /osm/planet-10*.osm.bz2 |egrep -v '#[0-9]*;'|... There has been a long discussion on 'dev', mentioning other remedies. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- John J. Mitchell ___ 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] short links
Hi, One question : What is the algorithm used to convert the short OSM link from/to lat/lon One sugestion : It sshould be nice to increase the potientiality of the osm.org. I explain : http://osm.org/go/0CUlOS6B- redirects to http://www.openstreetmap.org/?lat=47.2553lon=6.0121zoom=14layers=B000FTF http://osm.org/at/0CUlOS6B- could redirect to http://www.openstreetmap.org/?mlat=47.2553mlon=6.0121zoom=14layers=B000FTF Other shortcuts can be suggested... like http://osm.org/car/0CUlOS6B-/0CUpGUF for car routing http://osm.org/hike/0CUlOS6B-/0CUpGUF http://osm.org/bike/0CUlOS6B-/0CUpGUF and, i'm shure you have understoud the principle so you have understoud what could be http://osm.org/car/0A75uZ/0CUlOS6B-/0CUpGUF -- FrViPofm ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] short links
Hi, There is some info in a blog post I made a few months back: http://blog.shaunmcdonald.me.uk/2010/01/openstreetmap-shortlinks/ Shaun On 13 Mar 2010, at 21:35, Vincent Pottier wrote: Hi, One question : What is the algorithm used to convert the short OSM link from/to lat/lon One sugestion : It sshould be nice to increase the potientiality of the osm.org. I explain : http://osm.org/go/0CUlOS6B- redirects to http://www.openstreetmap.org/?lat=47.2553lon=6.0121zoom=14layers=B000FTF http://osm.org/at/0CUlOS6B- could redirect to http://www.openstreetmap.org/?mlat=47.2553mlon=6.0121zoom=14layers=B000FTF Other shortcuts can be suggested... like http://osm.org/car/0CUlOS6B-/0CUpGUF for car routing http://osm.org/hike/0CUlOS6B-/0CUpGUF http://osm.org/bike/0CUlOS6B-/0CUpGUF and, i'm shure you have understoud the principle so you have understoud what could be http://osm.org/car/0A75uZ/0CUlOS6B-/0CUpGUF -- FrViPofm ___ 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-nl] Geocalculaties
On Saturday 13 March 2010, Sybren A. Stüvel wrote: On 12-3-2010 21:42, ce-test, qualified testing bv - Gert Gremmen wrote: Waar kan ik een overzicht vinden van handige formules uit ge geo-goniometrie. DE library voor geometrische algoritmen is CGAL: http://www.cgal.org/ Helemaal mee eens, maar CGAL houdt zich bezig met discrete algoritmen en data structuren die werken op bijv. verzamelingen punten, polygonen, polyhedra, etc. Zie: http://www.cgal.org/Manual/last/doc_html/cgal_manual/packages.html#part_V Als ze het hebben over een triangulation, gaat het niet over het meten van afstanden en hoeken, maar om het opdelen van polygon of verzameling punten in een verzameling driehoeken. Het mooie van CGAL is dat ze exact zijn: als je normaalgesproken met geometrische formules rekent m.b.v. floating point getallen op een computer maak je veel afrondingsfouten die ervoor zorgen dat een punt bijvoorbeeld de ene keer aan de linker kant van een lijn ligt en de andere keer aan de andere kant. Door middel van slimme truuks (die iets meer rekentijd kosten) kan CGAL daar omheen werken (maar je kan er ook voor kiezen om hier geen gebruik van te maken). Je zou voor jouw applicatie dus wel gebruik kunnen maken van de exacte primitieven van CGAL om je berekeningen te doen, maar ze hebben geen kant-en-klare beeld(manipulatie/vergelijkins)functies. Tot zo ver de intro CGAL ;-) -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Geocalculaties
daar ben ik ook mee bezig geweest vorig jaar. ik heb hier 2 budget webcams liggen met zogenaamde groothoeklenzen. helaas zijn die maar ongeveer 80 graden :) en daarnaast is m'n fiets ook nog afgebrand. ik vermoed dat iemand me probeert tegen te houden... groet, floris ce-test, qualified testing bv - Gert Gremmen wrote: Jawel. Ik stel mij het volgende voor: Snelle electrische fiets Camera kijkt naar links (optioneel rechts) met 120-180 graden beeld voorlopig 1204 pixels hor. Snelle GPS logger met 5 locaties per sec Elke 3 seconden een foto Uit de gps track berekenen we koers, snelheid en locaties van de fotos Probleem : sync tussen gps en camera ; tools: statistiek (middelen) en interpolatie Bij 5 m/s hebben we 15 m tussen de fotos, prima base afstand voor triangulatie tot 100-150 m ? Door het aanwijzen van een pixel op 2 foto's (kies afstand tussen fotos 15-30-45 m) waarop een object Gemeenschppelijk is afgebeeld en de eigenschappen van de camera's (pixel versus hoek) kan je een driehoek maken waaruit de locaties van het object kunnen worden vastgesteld. Probleem: wat wordt de nauwkeurigheid, dit vereist wat nader onderzoek. Voordelen: we kunnen over water heen taggen (misschien wel 1 km weg) hoekpunten van gebouwen kan je nooit goed taggen ivm gps problemen, nu wel we hebben georeferenced fotos ala streetview het taggen van objecten kan offline Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Stefan de Konink Verzonden: vrijdag 12 maart 2010 22:33 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Geocalculaties Op 12-03-10 22:04, ce-test, qualified testing bv - Gert Gremmen schreef: Natuurlijk kan dat, jouw extra parameters zijn alleen nodig om de Hor-pixels in een hoek om te zetten. Dat is een kwestie van calibratie van de camera, desnoods met een GEO-driehoek ;)) Begrijp ik goed dat jij het volgende wil doen: GPS locatie + AfstandStereo(Afstand tussen Camera's, Afstand Tussen beeld, Hoek object op de Photo) + Hoek foto Stefan ___ 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] Geocalculaties
Wow, ik snap je doel Gert en als dat zou lukken is dit erg gaaf. Echter vraag ik me de nauwkeurigheid wel af. Want als ik even tel met een nauwkeurigheid van 2 mtr op 3 sec bij 5mtr/sec = tan hoek = 4/15 = 14,9% afwijking max. (mijn wiskunde is wat roestig ;) ). Al zou je het nauwkeuriger moeten kunnen krijgen als je alle punten in 1 lijn legt dus dan is de vraag wat de afwijking van de GPS lijn is over x mtr. Over de camera metingen daar snap ik niet veel van dus ik hoop dat je daar nauwkeurig kan zijn en dit lukt. Succes! Groet, Frank aka Frenzel Op 13 maart 2010 08:56 schreef ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl het volgende: Jawel. Ik stel mij het volgende voor: Snelle electrische fiets Camera kijkt naar links (optioneel rechts) met 120-180 graden beeld voorlopig 1204 pixels hor. Snelle GPS logger met 5 locaties per sec Elke 3 seconden een foto Uit de gps track berekenen we koers, snelheid en locaties van de fotos Probleem : sync tussen gps en camera ; tools: statistiek (middelen) en interpolatie Bij 5 m/s hebben we 15 m tussen de fotos, prima base afstand voor triangulatie tot 100-150 m ? Door het aanwijzen van een pixel op 2 foto's (kies afstand tussen fotos 15-30-45 m) waarop een object Gemeenschppelijk is afgebeeld en de eigenschappen van de camera's (pixel versus hoek) kan je een driehoek maken waaruit de locaties van het object kunnen worden vastgesteld. Probleem: wat wordt de nauwkeurigheid, dit vereist wat nader onderzoek. Voordelen: we kunnen over water heen taggen (misschien wel 1 km weg) hoekpunten van gebouwen kan je nooit goed taggen ivm gps problemen, nu wel we hebben georeferenced fotos ala streetview het taggen van objecten kan offline Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Stefan de Konink Verzonden: vrijdag 12 maart 2010 22:33 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Geocalculaties Op 12-03-10 22:04, ce-test, qualified testing bv - Gert Gremmen schreef: Natuurlijk kan dat, jouw extra parameters zijn alleen nodig om de Hor-pixels in een hoek om te zetten. Dat is een kwestie van calibratie van de camera, desnoods met een GEO-driehoek ;)) Begrijp ik goed dat jij het volgende wil doen: GPS locatie + AfstandStereo(Afstand tussen Camera's, Afstand Tussen beeld, Hoek object op de Photo) + Hoek foto Stefan ___ 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] Geocalculaties
Gert, Een 3D modeller is een applicatie waarmee je 3D scenes kunt modelleren. Voorbeeld is hier [1] te zien Wat ik wil is openstreetmap data (ways/nodes) om te zetten naar een formaat wat zo'n modeller kan inlezen. Dit is dan zichtbaar als een platte pannenkoek want openstreetmap heeft (bijna) geen hoogte informatie. Vervolgens wil ik foto's invoegen in de scene waarbij het perspectief precies klopt met de openstreetmap data. Daarna moet het met wat creatief camera werk en een export functie mogelijk zijn om nieuwe node/ways toe te voegen aan de hand van de aanwezige stereo informatie. Wat ik zoek is een 3D modeller waarvoor ik eenvoudig een osm import/export filter kan maken en waarin ik een foto (rechthoek met texture?) kan zetten. 1. http://blog.hubalek.net/media/1/20060514-sketchup.png ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Geocalculaties
On 13-3-2010 10:00, Dick wrote: Wat ik zoek is een 3D modeller waarvoor ik eenvoudig een osm import/export filter kan maken en waarin ik een foto (rechthoek met texture?) kan zetten. Check Blender: http://www.blender.org/ Het is Open Source dus goed voor je portemonnee en je karma, en een van de beste 3D applicaties die ik ken. Je kan het scripten met Python (ook Open Source, en net als Blender een product van Nederlandsche bodem) waardoor importeren/exporteren erg makkelijk is - mits je het formaat kent natuurlijk. Groet, -- Sybren A. Stüvel http://stuvel.eu/ signature.asc Description: OpenPGP digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Geocalculaties
Ik snap het. Maar dan moet je dus wel de foto's eerst taggen (automatisch?) op voldoende al aanwezige OSM referentie-punten, zodat de software de foto zelf kan draaien schuiven tot er een perspectief match optreedt. Dan weet je waar de foto precies is genomen. Nadeel is dat de fouten van de nieuwe ingelezen punten cumulatief worden als die nieuwe punten weer gebruikt worden voor een volgende fotoserie Dan is het wel handig als je toch echt weet waar de foto genomen is. In new york zou dit algoritme wel eens moeilijk kunnen worden met dat rechthoekig gelegen stratenpatroon, de verschillen zitten hem daar nu juist in de hoogte Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Dick Verzonden: zaterdag 13 maart 2010 10:00 Aan: talk-nl@openstreetmap.org Onderwerp: Re: [OSM-talk-nl] Geocalculaties Gert, Een 3D modeller is een applicatie waarmee je 3D scenes kunt modelleren. Voorbeeld is hier [1] te zien Wat ik wil is openstreetmap data (ways/nodes) om te zetten naar een formaat wat zo'n modeller kan inlezen. Dit is dan zichtbaar als een platte pannenkoek want openstreetmap heeft (bijna) geen hoogte informatie. Vervolgens wil ik foto's invoegen in de scene waarbij het perspectief precies klopt met de openstreetmap data. Daarna moet het met wat creatief camera werk en een export functie mogelijk zijn om nieuwe node/ways toe te voegen aan de hand van de aanwezige stereo informatie. Wat ik zoek is een 3D modeller waarvoor ik eenvoudig een osm import/export filter kan maken en waarin ik een foto (rechthoek met texture?) kan zetten. 1. http://blog.hubalek.net/media/1/20060514-sketchup.png ___ 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] Geocalculaties
Ik denk dat het wel iets teveel is. De driehoeksmetingen die ik wil zijn eenvoudige gonio metingen, maar in een ortho assenstelsel. De GPS data is in een geheel nader formaat, en ook nog eens in een WGS-84 projectie. Geen idee hoe ingewikkeld de berekeningen daardoor worden. Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Sybren A. Stüvel Verzonden: zaterdag 13 maart 2010 10:07 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Geocalculaties On 13-3-2010 10:00, Dick wrote: Wat ik zoek is een 3D modeller waarvoor ik eenvoudig een osm import/export filter kan maken en waarin ik een foto (rechthoek met texture?) kan zetten. Check Blender: http://www.blender.org/ Het is Open Source dus goed voor je portemonnee en je karma, en een van de beste 3D applicaties die ik ken. Je kan het scripten met Python (ook Open Source, en net als Blender een product van Nederlandsche bodem) waardoor importeren/exporteren erg makkelijk is - mits je het formaat kent natuurlijk. Groet, -- Sybren A. Stüvel http://stuvel.eu/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Kassen
Ik zie dat er flink gemapped wordt in de omgeving van delft. Een van Us (hulde) heeft ook veel kassen gemapped. Ik voindt dat de renderer daar best een altenatief kleurtje voor Mag maken, als de mapper daar tenminste de tag warehouse heeft gebruikt. Ik stel voor een beetje kunstmatig blauwgroen-grijs ??? Gert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Kassen
Eens. Op 13 maart 2010 10:22 schreef ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl het volgende: Ik zie dat er flink gemapped wordt in de omgeving van delft. Een van Us (hulde) heeft ook veel kassen gemapped. Ik voindt dat de renderer daar best een altenatief kleurtje voor Mag maken, als de mapper daar tenminste de tag warehouse heeft gebruikt. Ik stel voor een beetje kunstmatig blauwgroen-grijs ??? Gert ___ 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] Geocalculaties
Ja die nauwkeurigheid is het probleem, maar Met wat middelen (veel punten) en interpoleren Kan je wel de basisafstand tussen de foto's beter krijgen. Elke foto op zich is onnauwkeurig qua plaats, en ook de set is +/- 15 meter (GPS) maar de onderlinge Afstand is PRECIES 3 seconden. (CHDK hardware gestuurd) Uit de opeenvolgende gps punten kan je de afgelegde afstand en de kompasrichting van de basis-as van de twee fotos bepalen. Voila, en ik hoop op 10 cm uit te komen. Door niet opeenvolgende fotos maar foto's te skippen kan je een langere basisafstand maken, en verder kijken. Aanvullende problemen ontstaan in bochten Ik hoop in de software een idee te geven van de nauwkeurigheid door het object te plotten als punt met een rode cirkel eromheen die de onnauwkeurigheid aangeeft. Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens F. Heinen Verzonden: zaterdag 13 maart 2010 9:50 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Geocalculaties Wow, ik snap je doel Gert en als dat zou lukken is dit erg gaaf. Echter vraag ik me de nauwkeurigheid wel af. Want als ik even tel met een nauwkeurigheid van 2 mtr op 3 sec bij 5mtr/sec = tan hoek = 4/15 = 14,9% afwijking max. (mijn wiskunde is wat roestig ;) ). Al zou je het nauwkeuriger moeten kunnen krijgen als je alle punten in 1 lijn legt dus dan is de vraag wat de afwijking van de GPS lijn is over x mtr. Over de camera metingen daar snap ik niet veel van dus ik hoop dat je daar nauwkeurig kan zijn en dit lukt. Succes! Groet, Frank aka Frenzel Op 13 maart 2010 08:56 schreef ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl het volgende: Jawel. Ik stel mij het volgende voor: Snelle electrische fiets Camera kijkt naar links (optioneel rechts) met 120-180 graden beeld voorlopig 1204 pixels hor. Snelle GPS logger met 5 locaties per sec Elke 3 seconden een foto Uit de gps track berekenen we koers, snelheid en locaties van de fotos Probleem : sync tussen gps en camera ; tools: statistiek (middelen) en interpolatie Bij 5 m/s hebben we 15 m tussen de fotos, prima base afstand voor triangulatie tot 100-150 m ? Door het aanwijzen van een pixel op 2 foto's (kies afstand tussen fotos 15-30-45 m) waarop een object Gemeenschppelijk is afgebeeld en de eigenschappen van de camera's (pixel versus hoek) kan je een driehoek maken waaruit de locaties van het object kunnen worden vastgesteld. Probleem: wat wordt de nauwkeurigheid, dit vereist wat nader onderzoek. Voordelen: we kunnen over water heen taggen (misschien wel 1 km weg) hoekpunten van gebouwen kan je nooit goed taggen ivm gps problemen, nu wel we hebben georeferenced fotos ala streetview het taggen van objecten kan offline Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Stefan de Konink Verzonden: vrijdag 12 maart 2010 22:33 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Geocalculaties Op 12-03-10 22:04, ce-test, qualified testing bv - Gert Gremmen schreef: Natuurlijk kan dat, jouw extra parameters zijn alleen nodig om de Hor-pixels in een hoek om te zetten. Dat is een kwestie van calibratie van de camera, desnoods met een GEO-driehoek ;)) Begrijp ik goed dat jij het volgende wil doen: GPS locatie + AfstandStereo(Afstand tussen Camera's, Afstand Tussen beeld, Hoek object op de Photo) + Hoek foto Stefan ___ 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] Geocalculaties
Ik hoop dat je er iets moois voor op kunt zetten! Dit gaat buiten mijn kennis gebied dus helaas kan ik je hier niet mee helpen... Groet, Frank Op 13 maart 2010 10:32 schreef ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl het volgende: Ja die nauwkeurigheid is het probleem, maar Met wat “middelen” (veel punten) en interpoleren Kan je wel de basisafstand tussen de foto’s beter krijgen. Elke foto op zich is onnauwkeurig qua plaats, en ook de set is +/- 15 meter (GPS) maar de onderlinge Afstand is PRECIES 3 seconden. (CHDK hardware gestuurd) Uit de opeenvolgende gps punten kan je de afgelegde afstand en de kompasrichting van de basis-as van de twee fotos bepalen. Voila, en ik hoop op 10 cm uit te komen. Door niet opeenvolgende fotos maar foto’s te skippen kan je een langere basisafstand maken, en “verder” kijken. Aanvullende problemen ontstaan in bochten…. Ik hoop in de software een idee te geven van de nauwkeurigheid door het object te plotten als punt met een rode cirkel eromheen die de onnauwkeurigheid aangeeft. *Van:* talk-nl-boun...@openstreetmap.org [mailto: talk-nl-boun...@openstreetmap.org] *Namens *F. Heinen *Verzonden:* zaterdag 13 maart 2010 9:50 *Aan:* OpenStreetMap NL discussion list *Onderwerp:* Re: [OSM-talk-nl] Geocalculaties Wow, ik snap je doel Gert en als dat zou lukken is dit erg gaaf. Echter vraag ik me de nauwkeurigheid wel af. Want als ik even tel met een nauwkeurigheid van 2 mtr op 3 sec bij 5mtr/sec = tan hoek = 4/15 = 14,9% afwijking max. (mijn wiskunde is wat roestig ;) ). Al zou je het nauwkeuriger moeten kunnen krijgen als je alle punten in 1 lijn legt dus dan is de vraag wat de afwijking van de GPS lijn is over x mtr. Over de camera metingen daar snap ik niet veel van dus ik hoop dat je daar nauwkeurig kan zijn en dit lukt. Succes! Groet, Frank aka Frenzel Op 13 maart 2010 08:56 schreef ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl het volgende: Jawel. Ik stel mij het volgende voor: Snelle electrische fiets Camera kijkt naar links (optioneel rechts) met 120-180 graden beeld voorlopig 1204 pixels hor. Snelle GPS logger met 5 locaties per sec Elke 3 seconden een foto Uit de gps track berekenen we koers, snelheid en locaties van de fotos Probleem : sync tussen gps en camera ; tools: statistiek (middelen) en interpolatie Bij 5 m/s hebben we 15 m tussen de fotos, prima base afstand voor triangulatie tot 100-150 m ? Door het aanwijzen van een pixel op 2 foto's (kies afstand tussen fotos 15-30-45 m) waarop een object Gemeenschppelijk is afgebeeld en de eigenschappen van de camera's (pixel versus hoek) kan je een driehoek maken waaruit de locaties van het object kunnen worden vastgesteld. Probleem: wat wordt de nauwkeurigheid, dit vereist wat nader onderzoek. Voordelen: we kunnen over water heen taggen (misschien wel 1 km weg) hoekpunten van gebouwen kan je nooit goed taggen ivm gps problemen, nu wel we hebben georeferenced fotos ala streetview het taggen van objecten kan offline Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Stefan de Konink Verzonden: vrijdag 12 maart 2010 22:33 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Geocalculaties Op 12-03-10 22:04, ce-test, qualified testing bv - Gert Gremmen schreef: Natuurlijk kan dat, jouw extra parameters zijn alleen nodig om de Hor-pixels in een hoek om te zetten. Dat is een kwestie van calibratie van de camera, desnoods met een GEO-driehoek ;)) Begrijp ik goed dat jij het volgende wil doen: GPS locatie + AfstandStereo(Afstand tussen Camera's, Afstand Tussen beeld, Hoek object op de Photo) + Hoek foto Stefan ___ 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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Kassen
of zo: http://wiki.openstreetmap.org/wiki/Proposed_features/greenhouse_horticulture niet dat ik die tag echt goed gekozen vind maar warehouse is volgens mij iets heel anders. het is toch glasshouse of greenhouse? gr, floris F. Heinen wrote: Eens. Op 13 maart 2010 10:22 schreef ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl het volgende: Ik zie dat er flink gemapped wordt in de omgeving van delft. Een van Us (hulde) heeft ook veel kassen gemapped. Ik voindt dat de renderer daar best een altenatief kleurtje voor Mag maken, als de mapper daar tenminste de tag warehouse heeft gebruikt. Ik stel voor een beetje kunstmatig blauwgroen-grijs ??? Gert ___ 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] Kassen
Floris Looijesteijn wrote: of zo: http://wiki.openstreetmap.org/wiki/Proposed_features/greenhouse_horticulture niet dat ik die tag echt goed gekozen vind maar warehouse is volgens mij iets heel anders. het is toch glasshouse of greenhouse? Warehouse is inderdaad iets anders. Grote loodsen voor op- en overslag. Persoonlijk kies ik greenhouse. Ik heb het vorig jaar eens op IRC gevraagd, aan Britten en Amerikanen, en de meerderheid gebruikte/kende toen greenhouse, en niet glasshouse. greenhouse_horticulture is voor de landuse, dus het hele terrein van een kas, inclusief open ruimte, bijgebouwen, loodsen, etc. De kassen zelf zijn building=*. @Gert: Welk gebied rond Delft bedoel je precies? Want richting Pijnacker/Bleiswijk heb ik 3dShapes geïmporteerd. Is er ook nog iemand bezig die tekent vanaf Yahoo? -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Kassen
Floris Looijesteijn wrote: of zo: http://wiki.openstreetmap.org/wiki/Proposed_features/greenhouse_horticultur e niet dat ik die tag echt goed gekozen vind maar warehouse is volgens mij iets heel anders. het is toch glasshouse of greenhouse? Opgelet, landuse=greenhouse_horticulture is niet voor de serres zelf, maar ook voor al het land en de gebouwen errond. Om die reden zal die tag ook hetzelfde renderen als landuse=farm Ikzelf heb al meermaals building=greenhouse gebruikt voor de serre zelf. Voor mij lijkt dit me de enige manier om verschil te maken tussen soorten gebouwen. building=station wordt bvb al anders gerenderd in Mapnik dan building=yes. Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Geocalculaties
Op 13-03-10 10:00, Dick schreef: Wat ik zoek is een 3D modeller waarvoor ik eenvoudig een osm import/export filter kan maken en waarin ik een foto (rechthoek met texture?) kan zetten. Het is appeltje-eitje om OSM data in Blender in te lezen. Wat je voor het gemak even vergeet, is het probleem van Gert; het is namelijk niet appeltje eite om tussen twee fotos die niet EXACT op het zelfde moment zijn genomen (Gert; CHDK kan niets exact doen) stereoinformatie te extracten. Sterker nog, denk maar eens na over het probleem van een 3D cursor, hoe kan die always on top blijven, als de beelden twee planes zijn. Dan kom je dus weer op Bundler en PMVS uit. (PMVS staat op de mirror) Voor OpenStreetPhoto was ik al bezig met een appje wat ala PhotoSynth foto's kan oplijnen in OpenGL, maar ook daar komt het practische probleem weer naar voren dat foto's niet transparent zijn, en dat feitelijk een matrix op 'optellen' in de projectie waar je op dat moment naar kijkt. Gert: http://blogs.elphel.com/2010/03/first-elphel-eyesis-prototype-assembled/ Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] fout in script van openstreetmap.org?
Sinds enkele dagen kan ik op de pagina van openstreetmap.org niet meer in de optie bewerken komen. De knop bekijken werkt wel naar behoren wordt doorgelinkt naar b.v.http://www.openstreetmap.org/?lat=52.4lon=5.5zoom=7layers=B000FTF De knop Bewerken word niet doorgelinkt zou eigelijk zoiets moeten zijn http://www.openstreetmap.org/edit?lat=52.4lon=5.5zoom=7layers=B000FTF Maar ik krijg de foutmelding javascript:alert(i18n(javascripts.site.edit_zoom_alert)); heeft iemand daar ook last van ? __ Information from ESET NOD32 Antivirus, version of virus signature database 4941 (20100313) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[Talk-de] Garmin Europa:all in one karte auf eTrex
Moin! Nachdem ich etwas gebastelt habe, wollte ich mal mein Garmin eTrex nutzen zum Routen don Graz nach Chemnitz zum LinuxTag. Bisher hatte ich die Karte von Computerteddy, dieses mal hab ich die Europa all in one Karte probiert, satte 2.5GB. Mit dem Sendmap kamen nur 2GB auf die Karte, mit dem Kartenleser sind die gesamten 2.5GB auf di 8 GB MicroSDHC gekommen. Und dann: diese Detail-fülle! Auf dem kleinem Display des eTrex ist für mich erst ab der 300m Skalierung etwas sinnvoll zu erkennen - fürs Routen über weite Strecken etwas zu klein. In .at ist auch oft noch das Problem, das viele Tracks nicht korrekt getaggt sind und diese als dicke rote Linien dargestellt werden, die alle anderen Strassen überdecken - man erkennt erst ab 50m Details die Autobahn, auf der man fährt. In .de war das nicht so, da kann man z.B. in Bayern auch bei der 1.2km Stufe alles gut erkennen, die Details sind gut ausgefüllt, auch die Nutzung der Fläche in Wald, wiese, Feld,.. ist hervorragend. Was noch nervt: die Grenzen der Bezirke/Gemeinde/.. werden zu zu dick gezeichnet - stören meist nur beim Routen. Somit: im allgemeinem gut Nutzbar, IMHO ist der eTrex zu blöde, in den Zoomstufen 2km, 5km,... die unwichtigen Daten auszufiltern. MfG, Lars Schimmer -- - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Europa:all in one karte auf eTrex
Lars Schimmer schrieb am 13.03.2010 10:52: IMHO ist der eTrex zu blöde, in den Zoomstufen 2km, 5km,... die unwichtigen Daten auszufiltern. Da wuerde ich dem Etrex keine Schuld geben. Zum einen kann der Bediener bei den Garmin Geraeten irgendwo in den Einstellungen den Detaillevel zu veraendern, womit genau diesem Problem begegnet werden kann. Zum anderen wird bei der Erzeugung der Karten aus den OSM-Daten angegeben, ab welcher Zoomstufe welches Element angezeigt werden soll. Da kann also auch der Etrex nichts dafuer. Nebenbei bemerkt: Ich selber verwende eigentlich nie die 2km, 5km usw Zoomstufen. Meine Nutzung des Etrex spielt sich eigentlich eher im 80m (zu Fuss) bis 300m (Rennrad) Bereich ab. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All in one Garmin Map?Styles?mit?git?versionsverwaltung!
Torsten Leistikow de_m...@gmx.de wrote: Also ich habe eigentlich keine Probleme mit splitter.jar. Christoph hat auf der Fossgis von interessanten Routingartefakten an Kachelgrenzen gesprochen. Gruss Sven -- All bugs added by David S. Miller da...@redhat.com Linux Kernel boot message from /usr/src/linux/net/8021q/vlan.c /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] All in one Garmin Map Styles?mit?git?versionsverwaltung!
Carsten Schwede computerte...@gmx.de wrote: Was wäre denn der beste Ansatzpunkt für eine Zusammenarbeit? Als Betreuer des devservers könnte ich mir vorstellen, dass wir in Zukunft Karten mit verschiedenen Styles erzeugen. Besonders interessant finde ich eigentlich Mashups. Soll heißen ich fände es cool Radrouten, Wanderroute und ÖPNV-Linien in zuschaltbaren Layern zu haben so wie Christoph das schon mit Openstreetbugs etc. macht. Gruss Sven -- Das Internet wird vor allem von Leuten genutzt, die sich Pornografie ansehen, während sie Bier trinken, es ist daher für Wahlen nicht geeignet (Jaroslaw Kaczynski) /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] Openrouteservice als Referenz brauchbar? + Fahrradparken
Hallo, in Jena (besonders Innenstadt) fehlen viele Angaben für unechte Einbahnstraßen (Radfahren in Gegenrichtung erlaubt) und erlaubtes Radfahren in Fußgängerzonen und auf Gehwegen. Eine Korrekturmöglichkeit: die fraglichen Straßen und Wege in einem Editor alle einzeln durchprüfen. Eine andere (durch die ich auf die fehlenden Angaben gestoßen bin): in einem Routingprogramm Testfälle anzeigen, und wo der kürzeste Weg verwendet werden soll, aber nicht angezeigt wird, muss wohl ein bicycle=yes irgendwo fehlen. (Es können auch Ways nicht verbunden sein, ist aber selten.) Damit lassen sich die Fehler m.E. recht gut eingrenzen. Hat das ORS-Programm irgendwelche bekannten Eigenheiten im Algorithmus, dass man es dafür besser nicht verwendet? Bisher habe ich keine feststellen können, aber ich weiß sicher nicht alles... Was anderes: Wird amenity: bicycle_parking von irgendeinem Renderer schon angezeigt oder sonstwie ausgewertet? Ich könnte die größeren Fahrradständer (-anlagen) ergänzen, muss aber nicht sein, wenn sie eh (noch) keiner angezeigt bekommt. -- Viele Grüße, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradparken
Am 13.03.2010 11:36, Thomas Wedekind: Was anderes: Wird amenity: bicycle_parking von irgendeinem Renderer schon angezeigt oder sonstwie ausgewertet? Ich könnte die größeren Fahrradständer (-anlagen) ergänzen, muss aber nicht sein, wenn sie eh (noch) keiner angezeigt bekommt. Oben rechts auf www.openstreetmap.org kannst du auf die Radfahrerkarte umstellen. Diese rendert Fahrradparkplätze. Abgesehen davon lohnt es sich auch dann Daten in die OSM-Datenbank aufzunehmen, wenn sie noch nirgends ausgewertet oder angezeigt werden. Henne - Ei und so... Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All in one Garmin Map Styles?mit?git?versionsverwaltung!
Hi, Am 13.03.2010 11:37, schrieb Sven Geggus: Als Betreuer des devservers könnte ich mir vorstellen, dass wir in Zukunft Karten mit verschiedenen Styles erzeugen. Besonders Das ist eigentlich das geringste Problem. Wenn mein Cutter irgendwann so arbeitet, daß alles in den Kacheln drinbleibt und die herausragenden Wege auch korrekt abgeteilt werden (das ist der nächste Entwicklungsschritt), dann könnten eigentlich alle die gleiche Kachelbasis verwenden und die verschiedenen Karten mit den verschiedenen Styles erzeugen. Hat noch als Nebeneffekt den Vorteil, daß die Kachelnummern fest bleiben und es keine Probleme mit dem gleichzeitigen Verwenden der verschiedenen Karten gibt. (So ähnlich wie ich das bei der Höhenlinienkarte mache z.B.) interessant finde ich eigentlich Mashups. Soll heißen ich fände es cool Radrouten, Wanderroute und ÖPNV-Linien in zuschaltbaren Layern zu haben so wie Christoph das schon mit Openstreetbugs etc. macht. Das wäre sicher sehr interessant. Es könnte sich auch hier jeweils jemand auf eine Sache besser konzentrieren, vorausgesetzt alles ist in gewisser Weise standardisiert. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hallo, Carsten Schwede wrote: Das ist eigentlich das geringste Problem. Wenn mein Cutter irgendwann so arbeitet, daß alles in den Kacheln drinbleibt und die herausragenden Wege auch korrekt abgeteilt werden (das ist der nächste Entwicklungsschritt) Ich hab das jetzt eine Weile nicht verfolgt. Ist Dein Cutter inzwischen veroeffentlicht, so dass andere evtl. bei dem Problem helfen koennen? Als ich damals das osmcut.c geschrieben hab, war Deine Loesung glaube ich im Stadium wird irgendwann vielleicht mal veroeffentlicht oder so. Das ist ja auch ein erhoffter Effekt des dev-Servers, dass man da ein bisschen die Entwicklungskapazitaet buendeln kann und nicht jeder die gleichen Probleme fuer sich selber loesen muss. Ist denn bekannt, welche Anforderungen eine Kachel-Teilung erfuellen muss, damit Routing ueber die Kachelgrenzen hinweg funktioniert? Ich spreche jetzt als Garmin-Karten-Aussenseiter, bitte also um Nachsicht, falls die Frage naiv ist. Wenn ich einen Way A-B-C-D habe, und die Kachelgrenze liegt zwischen B und C, was tun die gaengigen Cutter dann im Moment? Wenn ich nun einen kuenstlichen Node X auf der Kachelgenze zwischen B und C einfuehren wuerde, der in beiden Kacheln enthalten waere, koennte dann ein korrektes Routing erfolgen? Der Splitter muesste vermutlich fuer den kuenstlichen Node X entweder eine negative ID oder eine, die hoeher ist als die hoechste sonst vorkommende, vergeben, richtig? Was geschaehe, wenn ich zwei Kacheln aus verschiedenen Splitter-Laeufen im Garmingeraet miteinander kombinieren wuerde - eine Kachel, in der der Node X die ID -50 bekommen hat, und eine aus einem spaeteren Lauf, in der der Node die ID -298 bekommen hat? Merkt das Garmin-Geraet das ueberhaupt noch, oder geht das nur noch nach der Position des Nodes? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hallo, Am 13.03.2010 12:07, schrieb Frederik Ramm: Ich hab das jetzt eine Weile nicht verfolgt. Ist Dein Cutter inzwischen veroeffentlicht, so dass andere evtl. bei dem Problem helfen koennen? Noch nicht ganz, aber eigentlich kurz davor. Ich habe die letzten Tage auf den Programmierer eingewirkt, es sollte eigentlich kein Problem mehr sein. ich schreib ihm gleich nochmal. Als ich damals das osmcut.c geschrieben hab, war Deine Loesung glaube ich im Stadium wird irgendwann vielleicht mal veroeffentlicht oder so. Ja. :-) Ist denn bekannt, welche Anforderungen eine Kachel-Teilung erfuellen muss, damit Routing ueber die Kachelgrenzen hinweg funktioniert? Ich spreche jetzt als Garmin-Karten-Aussenseiter, bitte also um Nachsicht, falls die Frage naiv ist. Ist nicht naiv. Prinzipiell ist es bekannt wie das geht, auch wenn ich es noch nicht ganz verstanden habe. Es werden auf die abgeschnittenen Wege marker gesetzt. So macht das splitter.jar. Darauf bezieht sich dann mkgmap beim Erzeugen der Routingkarte. Wenn ich einen Way A-B-C-D habe, und die Kachelgrenze liegt zwischen B und C, was tun die gaengigen Cutter dann im Moment? Wenn ich nun einen Mein Cutter übernimmt den kompletten Weg in die Kachel, in der er beginnt, also da wo die erste Node ist. Daher kommen bei mir die langen Äste, die aus den Kacheln ragen. kuenstlichen Node X auf der Kachelgenze zwischen B und C einfuehren wuerde, der in beiden Kacheln enthalten waere, koennte dann ein korrektes Routing erfolgen? Das ist egal, ob man da einen Node hinzufügt. Es muss nur jeweils der Anschluß entsprechend markiert sein. Ist auch glaube ich für eine effektive Kachelung zu rechenaufwändig da einen Node zu berechnen. Der Splitter muesste vermutlich fuer den kuenstlichen Node X entweder eine negative ID oder eine, die hoeher ist als die hoechste sonst vorkommende, vergeben, richtig? Was geschaehe, wenn ich zwei Kacheln aus verschiedenen Splitter-Laeufen im Garmingeraet miteinander kombinieren wuerde - eine Kachel, in der der Node X die ID -50 bekommen hat, und eine aus einem spaeteren Lauf, in der der Node die ID -298 bekommen hat? Merkt das Garmin-Geraet das ueberhaupt noch, oder geht das nur noch nach der Position des Nodes? Das kann ich nicht sagen. Am wichtigsten wäre es wohl erstmal herauszubekommen was genau splitter.jar an dieser Stelle macht und was mkgmap erwartet. Dazu reichen aber meine Englischkenntnisse leider nicht aus um Steve danach zu fragen. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradparken
Hallo, Oben rechts auf www.openstreetmap.org kannst du auf die Radfahrerkarte umstellen. Diese rendert Fahrradparkplätze. Wuff. Danke. Bin ich also der erste, der hier überhaupt sowas einträgt. Man sollte aus der Tatsache, dass in einer 100.000-Einwohner-Stadt ein alltägliches Objekt völlig fehlt, nicht darauf schließen, dass es überhaupt fehlt. Die Erfurter Radstation ist ein schönes Muster. Naja, ham' wir was zu tun (Kapazitäten zählen). Wobei ich felsenfest der Meinung war, dass dieses Objekt im Renderer erst im letzten halben Jahr hinzu gekommen ist... Wobei: Natürlich sollte es schon gerendert werden, damit ich weiß, wo es vorhanden und wo noch einzutragen ist. Der Mensch ist ein Augentier. Vielleicht lässt es sich im JOSM auch ausfiltern, habe ich noch nicht ausprobiert. -- Viele Grüße, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Europa:all in one karte auf eTrex
On 13.03.2010 11:06, Torsten Leistikow wrote: Lars Schimmer schrieb am 13.03.2010 10:52: IMHO ist der eTrex zu blöde, in den Zoomstufen 2km, 5km,... die unwichtigen Daten auszufiltern. Da wuerde ich dem Etrex keine Schuld geben. Zum einen kann der Bediener bei den Garmin Geraeten irgendwo in den Einstellungen den Detaillevel zu veraendern, womit genau diesem Problem begegnet werden kann. Schon, aber die filtert nicht das raus, was für Autos unwichtig ist ;-) Und selbst in der weniger Einstellung sind es noch zuviel. Zum anderen wird bei der Erzeugung der Karten aus den OSM-Daten angegeben, ab welcher Zoomstufe welches Element angezeigt werden soll. Da kann also auch der Etrex nichts dafuer. Ah ja, da ist der Fehler also. Nebenbei bemerkt: Ich selber verwende eigentlich nie die 2km, 5km usw Zoomstufen. Meine Nutzung des Etrex spielt sich eigentlich eher im 80m (zu Fuss) bis 300m (Rennrad) Bereich ab. Viele User, viele Anwendungsfälle. Das eTrex ist auch ned wirklich für auto-navi gedacht, aber als Beifahrer ist es OK. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de MfG, Lars Schimmer -- - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradparken
Am Samstag 13 März 2010 11:44:13 schrieb Claudius: Am 13.03.2010 11:36, Thomas Wedekind: Was anderes: Wird amenity: bicycle_parking von irgendeinem Renderer schon angezeigt oder sonstwie ausgewertet? Ich könnte die größeren Fahrradständer (-anlagen) ergänzen, muss aber nicht sein, wenn sie eh (noch) keiner angezeigt bekommt. gpsdrive hat sowas schon laenger drin, fuer die osm-pois dann vorrausichtlich auch ab dienstag. Abgesehen davon lohnt es sich auch dann Daten in die OSM-Datenbank aufzunehmen, wenn sie noch nirgends ausgewertet oder angezeigt werden. Henne - Ei und so... +1 was ich mich frage: warum gibt's da eigentlich wieder mal ein separates tag? fuer mich gehoert das eindeutig unter amenity=parking. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradparken
Guenther Meyer schrieb: was ich mich frage: warum gibt's da eigentlich wieder mal ein separates tag? fuer mich gehoert das eindeutig unter amenity=parking. Schon mal versucht mit einem Auto auf einem Fahrradparkplatz zu parken? ;-) Unter Parkplatz versteht man in der autofixierten Welt nunmal in erster Linie einen Autoparkplatz. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradparken
Hallo, Guenther Meyer wrote: was ich mich frage: warum gibt's da eigentlich wieder mal ein separates tag? fuer mich gehoert das eindeutig unter amenity=parking. Renderer, die sich nicht um Details kuemmern, machen ein blaues P hin, wenn sie amenity=parking sehen. Das wollte man halt vermeiden. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradparken
Am 13. März 2010 13:15 schrieb Guenther Meyer d@sordidmusic.com: Am Samstag 13 März 2010 11:44:13 schrieb Claudius: Am 13.03.2010 11:36, Thomas Wedekind: Was anderes: Wird amenity: bicycle_parking von irgendeinem Renderer schon angezeigt oder sonstwie ausgewertet? Ich könnte die größeren Fahrradständer (-anlagen) ergänzen, muss aber nicht sein, wenn sie eh (noch) keiner angezeigt bekommt. was ich mich frage: warum gibt's da eigentlich wieder mal ein separates tag? fuer mich gehoert das eindeutig unter amenity=parking. Weil sich die Tags bei OSM meist am Einzelfall entwickelt und da war das Auto mit amenity=parking zuerst da und hat das Tag besetzt. Jetzt kann man nicht mehr ein amenity=parking, parking=bicycle einführen, weil amenity=parking aufgrund seiner Entwicklung schon als amenity=parking, parking=car verstanden wird. Das Prinzip über den eignen Tag-Tellerrand hinaus zu schauen und ein hirarchisches tagging zu ermöglichen setzt sich erst in letzter Zeit mehr und mehr durch. Den bisher schon entstandenen historischen Ballast, müssen wir mit uns herum schleppen. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neue mapgen version 0.12 veröffentli cht
Hallo Gary68, jetzt muß ich doch nochmals nachtarocken. Die Regel fuer die Ways für das Anzeigen der Hausnummern habe ich ja bekapst. Aber bei denen nur ein Node benutzt wird, habe ich so meine Probleme. (Bin also doch nicht so smart). Koenntest Du mir da noch einen Hint geben zB in Form einer solchen Regel fuer den Inode 5566742376? Hike39 Am 11.03.2010 13:00, schrieb Gary G:: so wie ich das sehe, geht das ganz einfach. du musst nur zwei regeln einfügen bzw. die für building (node) ändern. 1.) bei buildings wird im moment der name angezeigt. bei label musst du also statt dessen bzw. zusätzlich (siehe manual) addr:housenumber einfügen 2.) eine regel für ways mit key/tag addr:interpolation und value = *. vielleicht als dünner, grauer strich? evtl auch gestrichelt? ciao und viel erfolg gerhard - original Nachricht Betreff: Re: neue mapgen version 0.12 veröffentlicht Gesendet: Do, 11. Mrz 2010 Von: hike39ho...@hike.de Hallo Gary68, für meine Tracking-Unternehmungen möchte ich als Grundlage Karten nutzen, die ich mittels Deiner Lösung Mapgen erzeuge. Da ich jetzt auch Hausnummern erfassen, wäre es hilfreich, wenn die schon erfaßten auch in der Karte dann angezeigt würden. Gibt es jetzt schon eine Möglichkeit? Ich habe allerdings noch keinen Parameter hierzu gefunden. Danke für Deine Hilfe. Gruß Horst alias hike39 Am 06.03.2010 17:27, schrieb Gary68: v0.12 (rel. March 6th, 2010) * joker für regeln * elemente in der legende nur für benutzte regeln gemäß maßstab * intelligenteres label und icon platzieren * key/value und sub-key/sub-value für regel definition (z.b. amenity=hospital UND hospital=field) * besseres vermeiden von überlappungen * optimierte flächen kacheln * längere labels werden nun auch mehrzeilig, zentriert, links- oder rechtsbündig dargestellt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de --- original Nachricht Ende ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradparken
Am Samstag 13 März 2010 13:33:49 schrieb Falk Zscheile: was ich mich frage: warum gibt's da eigentlich wieder mal ein separates tag? fuer mich gehoert das eindeutig unter amenity=parking. Weil sich die Tags bei OSM meist am Einzelfall entwickelt und da war das Auto mit amenity=parking zuerst da und hat das Tag besetzt. Jetzt kann man nicht mehr ein amenity=parking, parking=bicycle einführen, weil amenity=parking aufgrund seiner Entwicklung schon als amenity=parking, parking=car verstanden wird. ich seh da kein problem: wenn es keine zusatztags gibt, die die art des parkplatzes genauer spezifizieren, wird einfach ein autoparkplatz angenommen. die zeiten, wo eine software nur das haupttag auswerten, und alles andere ignorieren kann, sind vorbei. Das Prinzip über den eignen Tag-Tellerrand hinaus zu schauen und ein hirarchisches tagging zu ermöglichen setzt sich erst in letzter Zeit mehr und mehr durch. na hoffentlich. ansaetze dazu gibt es schon seit mehreren jahren... Den bisher schon entstandenen historischen Ballast, müssen wir mit uns herum schleppen. je nachdem. teilweise kann man durch default-annahmen (wie z.B. hier bei amenity=parking) bestehendes einfach erweitern. auch sehe ich kein problem darin, eindeutige tags in einem veralteten schema automatisch in was neues, besser ausgearbeitetes umzuwandeln. ein problem hier waeren nur schwammige definitionen, die es leider immer noch gibt... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Europa:all in one karte auf eTrex
Lars Schimmer schrieb am 13.03.2010 13:00: Das eTrex ist auch ned wirklich für auto-navi gedacht, aber als Beifahrer ist es OK. Auch in meinem Nuevi im Auto benutze ich eigentlich nie derartig grosse Zoom-Stufen. Damit kann man doch eigentlich nur noch kontrollieren, ob einem das Navi prinzipiell die richtige Autobahn entlang schickt. Wirklich navigieren kann man da doch auch mit dem Auto nicht mehr. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradparken
Am 13.03.2010 12:42, Thomas Wedekind: Wobei: Natürlich sollte es schon gerendert werden, damit ich weiß, wo es vorhanden und wo noch einzutragen ist. Der Mensch ist ein Augentier. Vielleicht lässt es sich im JOSM auch ausfiltern, habe ich noch nicht ausprobiert. In JOSM werden entsprechende Knoten schon seit längerem mit dem Symbol für ein Fahrradparkplatz angezeigt. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hallo, Am 13.03.2010 14:16, schrieb Torsten Leistikow: Nochmal konkret gefragt: Was abgesehen vom Speicherbedarf stoert dich an splitter.jar? Die ungeordneten Kacheln, die damit entstehen, diese Woche kann meine Kachel für einen bestimmten Punkt eine Nummer haben, nächste Woche hat sie eine andere Größe und dann noch eine andere Nummer. Für die automatische Erstellung von Kartenausschnitten ist das sehr hinderlich. (z.B. Haiti und Chileausschnitte). Es gibt auch etliche Leute, die über das Kachelaussuchinterface einzelne Kacheln von irgendwo auf der Welt holen, oder gar direkt durch Angabe einer oder weniger spezieller Kacheln, das kann ich problemlos mit aktuellen Daten hinterlegen, was eben bei Nutzung von splitter nicht so einfach geht. Im Prinzip stammt splitter ja von den selben Leuten wie mkgmap, so dass da schon der Kern des OSM-zu-Garmin-Wissens dahinter steckt. Ja klar. Der Nachteil ist aber hier auch, dass die beiden Programme sehr aufeinander angewiesen sind. Mein Ziel wäre, daß man die Kacheln imemr und überall verwenden kann, also auch für die Erstellung von ganz anderen Karten, nicht nur Garminkarten. Von mir aus kann es gerne mehrere Schnittprogramme geben. Sinnvoller Weise haette dann jedes seine Vor- und Nachteile, wobei ich z.Z. eben nicht sehe, wo dein Programm splitter.jar ueberlegen ist. die Vorteile meines Programmes sind: - festes Raster für die ganze Welt - eindeutige Kachelnummern - keine Doppelungen von Wegen an Schnittgrenzen - keine abgeschnittenen oder verstümmelten Polygone/Wege - keine zusätzlich berechnteten Nodes nötig - geringerer Speicherbedarf auf Kosten der Laufzeit (wobei ich nicht weiss wie lange splitter an der ganzen Welt rechnen würde) Das sollte es soweit sein. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neue mapgen version 0.12 veröffentli cht
hi, habe heute morgen die version 0.13 veröffentlicht, da sind die regeln drin. schau mal da nach. den von dir angegebenen node scheint es nicht zu geben? kann ich also nichts zu sagen... http://www.openstreetmap.org/browse/node/5566742376 ciao gerhard On Sat, 2010-03-13 at 14:08 +0100, hike39 wrote: Hallo Gary68, jetzt muß ich doch nochmals nachtarocken. Die Regel fuer die Ways für das Anzeigen der Hausnummern habe ich ja bekapst. Aber bei denen nur ein Node benutzt wird, habe ich so meine Probleme. (Bin also doch nicht so smart). Koenntest Du mir da noch einen Hint geben zB in Form einer solchen Regel fuer den Inode 5566742376? Hike39 Am 11.03.2010 13:00, schrieb Gary G:: so wie ich das sehe, geht das ganz einfach. du musst nur zwei regeln einfügen bzw. die für building (node) ändern. 1.) bei buildings wird im moment der name angezeigt. bei label musst du also statt dessen bzw. zusätzlich (siehe manual) addr:housenumber einfügen 2.) eine regel für ways mit key/tag addr:interpolation und value = *. vielleicht als dünner, grauer strich? evtl auch gestrichelt? ciao und viel erfolg gerhard - original Nachricht Betreff: Re: neue mapgen version 0.12 veröffentlicht Gesendet: Do, 11. Mrz 2010 Von: hike39ho...@hike.de Hallo Gary68, für meine Tracking-Unternehmungen möchte ich als Grundlage Karten nutzen, die ich mittels Deiner Lösung Mapgen erzeuge. Da ich jetzt auch Hausnummern erfassen, wäre es hilfreich, wenn die schon erfaßten auch in der Karte dann angezeigt würden. Gibt es jetzt schon eine Möglichkeit? Ich habe allerdings noch keinen Parameter hierzu gefunden. Danke für Deine Hilfe. Gruß Horst alias hike39 Am 06.03.2010 17:27, schrieb Gary68: v0.12 (rel. March 6th, 2010) * joker für regeln * elemente in der legende nur für benutzte regeln gemäß maßstab * intelligenteres label und icon platzieren * key/value und sub-key/sub-value für regel definition (z.b. amenity=hospital UND hospital=field) * besseres vermeiden von überlappungen * optimierte flächen kacheln * längere labels werden nun auch mehrzeilig, zentriert, links- oder rechtsbündig dargestellt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de --- original Nachricht Ende ___ 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] Tauchen und die Tauchplätze
Hallo, Es kann immer passieren, dass bestimmte Tauchplätze einen anderen (zweiten) Namen als auf der Landkarte haben. Spontan fallen mir da Wracks und Riffe ein. Wenn du jetzt den bestehenden Knoten mit benutzen möchtest, musst du deinen Namen von dem allgemeinen unterscheiden können. Naja da sehe ich nicht den großen Unterschied zu anderen POIs. Außerdem gibt es ja dafür alt_name u.ä. Das Problem dabei ist, dass ich schon einen Schlüssel brauche, den ich den Tauchplätzen zuordnen kann. Ist alt_name bei einem Wrack jetzt für eine weitere umgangssprachliche Bezeichnung gesetzt worden? Gehört er zu den Seezeichen, die ja teilweise auch eine eigene Bezeichnung haben? Gehört er zu den Tauchplätzen? usw. Beste Grüße Olaf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neue mapgen version 0.12 veröffentlich t
hi, runtergeladen, gestartet und alles so, wie ich es mir vorstelle. Besten Dank! Nun kann ich in der nächsten Zeit anfangen Hausnummern zu erfassen. Weiterhin erspart mir Dein Tool Stunden, die ich ansonsten immer zum Rendern benötigt hätte. Vergleich: früher 5 Stunden, nun eine Minute. ciao hike39 Am 13.03.2010 14:54, schrieb Gary68: hi, habe heute morgen die version 0.13 veröffentlicht, da sind die regeln drin. schau mal da nach. den von dir angegebenen node scheint es nicht zu geben? kann ich also nichts zu sagen... http://www.openstreetmap.org/browse/node/5566742376 ciao gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Carsten Schwede schrieb am 13.03.2010 14:51: Die ungeordneten Kacheln, die damit entstehen, diese Woche kann meine Kachel für einen bestimmten Punkt eine Nummer haben, nächste Woche hat sie eine andere Größe und dann noch eine andere Nummer. Das kannst du ganz einfach verhindern, indem du splitter.jar eine area-list vorgibst. Ueber diese Datei kann man die Eckpunkte sowie den Dateiname fuer jede auszuschneidende Kachel definieren. Einziger Haken an der Sache ist, dass man die Eckpunkte nicht beliebig vorgeben kann, sondern nur als Vielfache von 360 Grad geteilt durch 2 hoch irgendwas. Das liegt aber wohl nicht am Splitter, sondern am Garmin-Koordinatensystem. Ja klar. Der Nachteil ist aber hier auch, dass die beiden Programme sehr aufeinander angewiesen sind. Mein Ziel wäre, daß man die Kacheln imemr und überall verwenden kann, also auch für die Erstellung von ganz anderen Karten, nicht nur Garminkarten. Naja. Ich fuerchte, dass die Kacheln fuer die Garminkartenerzeugung bestimmte Bedingungen erfuellen muessen (vorallem fuer das Routing ueber Kachelgrenzen hinweg, oder fuer das multipolygon-Handling). Insofern wird es wohl noetig sein, dass ein Split-Programm darauf Ruecksicht nimmt und deshalb das Schnittergebnis zwangslaeufig auf einen Einsatzzweck hin optimiert sein muss. (Ich habe mich nie damit beschaeftigt, was fuer das Inter-Tile-Routing notwendig ist, ich vertraue einfach darauf, dass die Autoren von splitter.jar wissen, was sie da machen.) die Vorteile meines Programmes sind: - festes Raster für die ganze Welt - eindeutige Kachelnummern Das kann splitter.jar auch, siehe oben. - keine Doppelungen von Wegen an Schnittgrenzen Das koennte fuers Routing notwendig sein, - keine abgeschnittenen oder verstümmelten Polygone/Wege Sehe ich nicht als Vorteil, ist wohl eher eine Geschmacksfrage. - keine zusätzlich berechnteten Nodes nötig Auch das koennte fuers Routing notwendig sein, - geringerer Speicherbedarf auf Kosten der Laufzeit (wobei ich nicht weiss wie lange splitter an der ganzen Welt rechnen würde) Pah, als ordentlicher Informatiker verschwendet man keine Gedanken an solche Kleinigkeiten ;-) Wobei bei mir bisher immer mkgmap mehr Speicherhunger hatte als splitter, ich schneide meine Karten allerdings auch maximal aus dem Europa-Auszug von Geofabrik. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice als Referenz brauchbar? + Fahrradparken
Thomas Wedekind tom-wedek...@web.de [Sat, Mar 13, 2010 at 11:36:50AM CET]: [...] Eine andere (durch die ich auf die fehlenden Angaben gestoßen bin): in einem Routingprogramm Testfälle anzeigen, und wo der kürzeste Weg verwendet werden soll, aber nicht angezeigt wird, muss wohl ein bicycle=yes irgendwo fehlen. Da gab es doch mal vor einem Jahr die Anregung, dies für Relationen meist über Autobahnen zwischen großen deutschen Städten zu verankern, also ein Server, der alle paar Tage die Entfernung Erfurt -- Saarbrücken abfragt und sich muckst, wenn sie gegenüber letztes Mal um mehr als 5 % gewachsen ist, weil irgendein Experte die Einbahnstraßenrichtung von Fahrstreifen umgekehrt hat oder so. Wurde diese Anregung aufgegriffen? -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur von durch OSM Inspector gefundenen Fehlern
Hi, Torsten Breda schrieb: Durch das Korrigieren von Fehlern in der neuen Routing(skobbler)-Ansicht im OSM-Inspector habe ich folgendes festgestellt: 1. False-positives (dublicate ways) durch gemeinsam genutzte Nodes von normalen Wegen und solchen, mit area=yes (Platz liegt direkt an Straße). - Sollte meiner Meinung nach ignoriert werden. Habe es in der Nacht korrigiert und im aktuellen View des OSMI sollte es jetzt nicht mehr auftreten. Also wenn bei redundanten Waysegmenten, ein Way ein area=yes Tag besitzt, wird es nun nicht mehr als Fehler angezeigt. Wenn jemand dennoch dies irgendwo feststellt, am besten mir eine PM senden. dankegruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice als Referenz brauchbar? + Fahrradparken
Hallo, Thomas Wedekind schrieb: Hallo, ... Hat das ORS-Programm irgendwelche bekannten Eigenheiten im Algorithmus, dass man es dafür besser nicht verwendet? Bisher habe ich keine feststellen können, aber ich weiß sicher nicht alles... Abbiege-Relationen (Einschränkungen, Turn-Restriktions) werden in ORS noch nicht berücksichtigt. Das ist aber eher auf großen Straßen, also für KFZ relevant, weniger für Fahrräder. http://wiki.openstreetmap.org/wiki/OpenRouteService#Route_Service_Comparison_Matrix (Der Hinweis fehlt noch in deutscher Version http://wiki.openstreetmap.org/wiki/DE:OpenRouteService#Route_Service_Vergleichsmatrix) Was anderes: Wird amenity: bicycle_parking von irgendeinem Renderer schon angezeigt oder sonstwie ausgewertet? Ich könnte die größeren Fahrradständer (-anlagen) ergänzen, muss aber nicht sein, wenn sie eh (noch) keiner angezeigt bekommt. OSM ist zunächst mal eine Datenbank. OSM wird inzwischen in vielfältiger Weise benutzt. Die bekannten Darstellungen in Mapnik und Osmarender sind nur zwei unter vielen anderen Anwendungen. OSM wird in GIS-Systeme importiert und für Navigationsgeräte aufbereitet. Es scheint mir, als wenn in der Radkarte ein blauer Punkt an einem P-Symbol auf Radständer hindeutet: http://www.openstreetmap.org/?lat=52.06938lon=8.75496zoom=16layers=00B0FTF http://www.openstreetmap.org/browse/node/263784584 Es macht also auf alle Fälle Sinn, Fahrradständer zu erfassen. -- Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur von durch OSM Inspector gefundenen Fehlern
Hi, Bernd Wurst schrieb: Am Montag 08 März 2010 11:02:52 schrieb Torsten Breda: highway=steps: 2 (In diesem Fall waren es Eingänge zur Tiefgarage, Mir fiel da auch folgendes auf: # # ooo- # # Legende: footway steps unclassified Das Problem war hier, dass die Treppen nur ca. 3-4 Stufen haben und daher nur um die 2 Meter lang sind. Der Footway und die Unclassified sind folglich weniger als 5 Meter auseinander und werden als Fehler markiert. Ich würde darum bitten, wenn eine Verbindung zwischen den Wegen existiert, dass dann kein Fehler erkannt wird, auch wenn der Endnode vom einen nah an einem anderen Weg ist. könntest du das bitte jetzt nochmal überprüfen? Normal dürfte es nun nicht mehr angezeigt werden. pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur von durch OSM Inspector gefundenen Fehlern
Hi, Torsten Breda schrieb: Habe wieder einige Fehler beseitigt und mal mitgeschrieben, was es für welche waren. Vielleicht hilft das ja bei der Vermeidung von False-positives oder bei der Vermeidung von Fehlern. In der Liste sind nur Fehler, die ich lösen konnte und nur Fehler vom Typ unconnected road. Echte Fehler: Unachtsamkeit (Punkt auf Punkt, Punkt auf Straße): 25 Highway an Landuse, statt an Straße: 11 (Siehe auch unter 2.) im Eingangsposting) highway=pedestrian; area=yes nicht mit Straßen verbunden: 2 False-positives: noexit=yes: 4 highway=elevator: 4 highway=steps: 2 (In diesem Fall waren es Eingänge zur Tiefgarage, habe aber auch echte Fehler an highway=steps gefunden) highway=Platform (Ende des Bussteiges): 4 Anderer Grund (zB parallele Straße): 4 danke für den Hinweis mit noexit! Dies war mir bisher nicht bekannt. Es wird jetzt bei der Analyse gesondert behandelt. Aber Achtung: ein Way mit einem noexit-Tag kann trotzdem als Fehler markiert sein, nämlich genau dann wenn er dennoch keine Verbindung zu einer anderen Straße hat. In Berlin kommt dies z.B. 3x mal vor. gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice als Referenz brauchbar? + Fahrradparken
Frank Jäger schrieb: Abbiege-Relationen (Einschränkungen, Turn-Restriktions) werden in ORS noch nicht berücksichtigt. Das ist aber eher auf großen Straßen, also für KFZ relevant, weniger für Fahrräder. Das schafft leider noch keiner der 3 bekannten OSM Online-Router (ORS, CloudMade, YOURS). Des weiteren routet ORS Autos durch Anliegerstraßen, das müsste man einem Referenzrouter auch noch abgewöhnen. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice als Referenz brauchbar? + Fahrradparken
Hallo, Chris-Hein Lunkhusen wrote: Abbiege-Relationen (Einschränkungen, Turn-Restriktions) werden in ORS noch nicht berücksichtigt. Das ist aber eher auf großen Straßen, also für KFZ relevant, weniger für Fahrräder. Das schafft leider noch keiner der 3 bekannten OSM Online-Router (ORS, CloudMade, YOURS). YOURS (also Gosmore) beachtet no_...-Restrictions, wenn das via-Element ein einzelner Node ist. only_...-Restrictions sowie solche, deren via ein komplizierteres Gebilde ist, kann es nicht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neues Proposal für boat_rental
Ich habe diese Woche noch ein neues Proposal für amenity=boat_rental erstellt: http://wiki.openstreetmap.org/wiki/Proposed_features/Boat_Rental car_rental und bike_rental gibt's ja schon. Aber boat_rental leider noch nicht. Und vorallem in Touristengebieten gibt es ja sehr oft Bootsvermietungen, was mE auch in OSM gehört. Für Touristen ist das sicher nicht übel, wenn man die boat_rentals sehen kann. Für zuätzliche Ideen, nötige Anpassungen oder sonstige Komentare, bitte die Diskussion im wiki-Eintrag nutzen. Danke. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Simon Kokolakis glaubte zu wissen: ich fände ein amenity=school school=driving besser, damit die Werte für amenity nicht ausufern, und das ganze eine überschaubare Struktur behält. +1 amentiy=school und dann was für eine. Sonst blickt da nachher keiner mehr durch. flo -- On a Japanese food processor: Not to be used for the other use. Auf einer japanischen Küchenmaschine: Nicht zur anderen Verwendung bestimmt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendern von Seezeichen und Editor
Hallo, Markus wrote: Bei OpenSeaMap steht aber die Darstellung normkonformer Daten im Vordergrund. Entsprechend arbeiten auch die Editoren. Wie wir hier festgestellt haben, gab es voruebergehend das Problem, dass mindestens ein OSeaM-Editor irgendwelche de facto existierenden, aber nicht normkonformen Seezeichen blindlings (und ohne Kenntnis der Realitaet) in normkonforme Seezeichen (die so am angegebenen Ort nicht existieren) umgesetzt hat. Das ist definitiv eine Fehlfunktion in der Software, ich denke, darin sind wir uns alle einig. Wenn irgendwo ein rostiges Benzinfass rumduempelt, dann sollte kein Editor der Welt daraus automatisch ein rostiges Benzinfass mit roter Leuchte drauf machen, bloss weil es nur fuer rostige Benzinfaesser mit roter Leuchte eine Norm gibt. Jan Jesse beschreibt in einem Posting vom 3.3. eine solche offensichtliche Editor-Fehlfunktion: http://www.freietonne.de/index.php?site=126infotyp=1 Ich gehe davon aus, dass solche Fehler inzwischen nicht mehr vorkommen. Ich moechte alle Beteiligten bitten, die Software, falls noch fehlerhaft, entsprechend zu verbessern, bzw. die Verwendung derart fehlerhafter Software umgehend einzustellen. Sollte nach dem 31.3. immer noch derart fehlerbehaftete Software eingesetzt werden, werde ich die betroffenen Accounts einzeln anschreiben und notfalls so lange sperren, bis sie ihre Software dahingehend aktualisiert haben, dass kein versehentliches Um-Taggen, wie es hier beschrieben wird, mehr stattfindet. Ich hoffe aber, dass das nicht noetig sein wird! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues Proposal für boat_rental
car_rental und bike_rental gibt's ja schon. Aber boat_rental leider noch nicht. Vieles andere auch noch nicht und da gibts ne Menge was vermietet werden kann. Das bedeutet in der Form auch drei Trilliarden Hauptschlüssel. Ich wäre streng dafür die bisherigen Rentals zu kippen und unter amenity=rental zu gruppieren. Da kannst du mit rental=* unendlich weitere hinzufügen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues Proposal für boat_rental
car_rental und bike_rental gibt's ja schon. Aber boat_rental leider noch nicht. Vieles andere auch noch nicht und da gibts ne Menge was vermietet werden kann. Das bedeutet in der Form auch drei Trilliarden Hauptschlüssel. Ich wäre streng dafür die bisherigen Rentals zu kippen und unter amenity=rental zu gruppieren. Da kannst du mit rental=* unendlich weitere hinzufügen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Genau dies ist auch der eine Punkt in der Diskussion. Mal schauen, was sich da dann ergibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues Proposal für boat_rental
Hallo, Mirko Küster wrote: Ich wäre streng dafür die bisherigen Rentals zu kippen und unter amenity=rental zu gruppieren. Da kannst du mit rental=* unendlich weitere hinzufügen. Klingt gut, ich denke, man kann dann geeignete rental-Werte fuer Videoverleihe und Laufhaeuser einsetzen ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am 13.03.2010 19:59, schrieb Florian Gross: Simon Kokolakis glaubte zu wissen: ich fände ein amenity=school school=driving besser, damit die Werte für amenity nicht ausufern, und das ganze eine überschaubare Struktur behält. +1 amentiy=school und dann was für eine. Sonst blickt da nachher keiner mehr durch. Wir haben hier doch schon mehrfach schmerzhaft lernen müssen, daß eine Erweiterung einer bisher recht klaren Definition einfach Scheiße ist. Wieso lernen wir nichts daraus? Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendern von Seezeichen und Editor
Hallo, Jan Jesse beschreibt in einem Posting vom 3.3. eine solche offensichtliche Editor-Fehlfunktion: bevor jetzt hier irgend etwas großes passiert kurz ein Update: Ich hatte die betreffende Seite eingestellt, um ein Problem zu benennen, zu dem ich keinen Ansprechpartner hatte. Es hat sich inzwischen herausgestellt, daß dies ein Zeitproblem der anderen Seite war. Ich bin also etwas voreilig und nicht hinreichend gelassen an die Sache herangegangen. Inzwischen besteht ein Mailkontakt, und ich bin ziemlich optimistisch, daß wir das Problem im Sinne der Projektziele gut lösen. Denn es geht ja beiden Seiten tatsächlich darum, die inzwischen in der DB befindlichen Seekartendaten weiter zu qualifizieren, zu vermehren , und auch auf allen Plattformen darzustellen. Beste Grüße aus Berlin JJ Als Zeichen des Friedens verzichte ich auf eine Signatur :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Fri, 12 Mar 2010 23:01:06 +0100 hat Simon Kokolakis simon.kokola...@gmx.de geschrieben: Nils Heuermann schrieb: amenity=school school=driving halte ich für unpassend, da eine Fahrschule nun mal keine Schule im herkömmlichen Sinne ist, auch wenn sie so heißt. Sonst könnte/müsste man auch den Segelclub, bei dem es eine Segelschule gibt, als amenity=school taggen; oder ein Tauchschule, Surfschule, Yogaschule, ... Was definierst du denn als Schule im herkömmlichen Sinne?... Wo soll man deines Erachtens die Grenze setzen? Stichwort Volkshochschule, private Förderschulen, Internate in freier Trägerschaft. Die Grenze ist m.E. fließend. amenity=school sehe ich als allgemeinbildende Schule. Eben alles, wo man fürs Leben lernt: Grundschule, weiterführende Schulen, aber auch Internate (falls es da nicht sowieso einen eigenen Tag gibt) oder private Schulen, die Allgemeinwissen vermitteln. Man muss ja nicht für alles andere ein eigenes amenity=xyz_school machen, sondern könnte da evtl. den Typ extra angeben. Wobei man dann auch Sachen, die überhaupt nichts miteinander zu tun haben - außer dass man irgendwas dort lernen kann -, in einen Topf schmeißt; man muss also den Typ ohnehin auswerten, um was sinnvolles rauszubekommen... Auf jeden Fall - wie Ulf bereits schrieb - einen ziemlich eindeutigen Tag nachträglich zu erweitern, ist ungünstig. Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
ich fände ein amenity=school school=driving besser, damit die Werte für amenity nicht ausufern, und das ganze eine überschaubare Struktur behält. +1 amentiy=school und dann was für eine. Sonst blickt da nachher keiner mehr durch. -1 Wir müssen die Legacy[1]-Tags respektieren. Sonst taucht die Fahrschule, Flugschule, Rückenschule mit dem ABC-Symbol in den Karten auf, das ist lächerlich. (Wir taggen nicht gegen die Renderer!) Eine Fahr-, Rücken-, Flugschule sind keine Schule, sondern ein Gewerbe. Und eine Volkshochschule ist keine Schule sondern eine öffentliche Einrichtung. Wenn dich einer auf der Straße nach der nächsten Schule fragt, fragst du dann zurück: Äh, meinen Sie eine Fahrschule oder eine Hundeschule?. Nein, du wirst eine Grund-, Haupt-, Real-, Berufs-, Walldorf-, ...-, Gesamtschule oder ein Gymnasium nennen - oder? Ähnliches gilt auch für Kliniken: eine Tierklinkik ist nun mal kein hospital sonder höchstens ein animal_hospital. jm2c -fri- [1] Altlast ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues Proposal für boat_rental
Fred Jelk wakef...@gmail.com [Sat, Mar 13, 2010 at 07:55:59PM CET]: Ich habe diese Woche noch ein neues Proposal für amenity=boat_rental erstellt: http://wiki.openstreetmap.org/wiki/Proposed_features/Boat_Rental Bitte harmonisieren mit http://wiki.openstreetmap.org/wiki/Proposed_features/Canoe Danke. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Samstag 13 März 2010 20:50:28 schrieb Ulf Lamping: Am 13.03.2010 19:59, schrieb Florian Gross: Simon Kokolakis glaubte zu wissen: ich fände ein amenity=school school=driving besser, damit die Werte für amenity nicht ausufern, und das ganze eine überschaubare Struktur behält. +1 amentiy=school und dann was für eine. Sonst blickt da nachher keiner mehr durch. Wir haben hier doch schon mehrfach schmerzhaft lernen müssen, daß eine Erweiterung einer bisher recht klaren Definition einfach Scheiße ist. wer hat wo was lernen muessen?!? schmeiss bitte nicht mit solchen unbegruendeten pauschalisierungen um dich! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Samstag 13 März 2010 21:23:46 schrieb Friedhelm Schmidt: Wir müssen die Legacy[1]-Tags respektieren. Sonst taucht die Fahrschule, Flugschule, Rückenschule mit dem ABC-Symbol in den Karten auf, das ist lächerlich. (Wir taggen nicht gegen die Renderer!) wir taggen auch nicht fuer den renderer! nur weil diese bestimmte neue dinge falsch darstellen koennten, soll man sich jedes mal ein komplett neues tag aus den fingern saugen, anstatt bestehendes zu erweitern?!? Eine Fahr-, Rücken-, Flugschule sind keine Schule, sondern ein Gewerbe. Und eine Volkshochschule ist keine Schule sondern eine öffentliche Einrichtung. eine fahrschule ist wie eine tauch/flug/volkshoch/grund/haupt-schule eine einrichtung, die dazu da ist, etwas zu lernen. deshalb gehoert das auch zusammen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Samstag 13 März 2010 21:09:41 schrieb Nils Heuermann: Am Fri, 12 Mar 2010 23:01:06 +0100 hat Simon Kokolakis simon.kokola...@gmx.de geschrieben: Nils Heuermann schrieb: amenity=school school=driving halte ich für unpassend, da eine Fahrschule nun mal keine Schule im herkömmlichen Sinne ist, auch wenn sie so heißt. Sonst könnte/müsste man auch den Segelclub, bei dem es eine Segelschule gibt, als amenity=school taggen; oder ein Tauchschule, Surfschule, Yogaschule, ... Was definierst du denn als Schule im herkömmlichen Sinne?... Wo soll man deines Erachtens die Grenze setzen? Stichwort Volkshochschule, private Förderschulen, Internate in freier Trägerschaft. Die Grenze ist m.E. fließend. amenity=school sehe ich als allgemeinbildende Schule. Eben alles, wo man fürs Leben lernt: Grundschule, weiterführende Schulen, aber auch Internate (falls es da nicht sowieso einen eigenen Tag gibt) oder private Schulen, die Allgemeinwissen vermitteln. wo man fuers leben lernt... das thema waere eine eigene diskussion wert, die uns aber hier nicht weiterbringt... - eine fahrschule kann man auch fuers leben brauchen. - in der volkshochschule gibt's auch allgemeinbildung. - weiterfuehrende schulen: berufsschulen, private lehrinstitute, wo ziehst du die grenze? - was ist mit nachhilfeunterricht? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Guenther Meyer schrieb am 13.03.2010 22:09: wer hat wo was lernen muessen?!? Das Problem bei so einer sinnveraendernden Erweiterung ist, dass all die Auswerteprogramme (Renderer usw.) das nicht automatisch mitbekommen. Die sehen dann nur amenity=school und denken: Prima, das kenne ich. Fuer sie ist das also erstmal eine ganz normale Schule. Dass da noch irgendwelche Tags bei sind, die man nicht erkennt, ist bei OSM ja normal. Wenn man also eine derartig gekennzeichnete Fahrschule in die OSM-Datenbank eintraegt, dann wird der Eintrag von den Auswerteprogrammen falsch interpretiert. Da ist es deutlich besser, wenn ein neues Tag erfunden wird, dass vom Auswerteprogramm gar nicht erkannt wird. Das Prinzip ist eigentlich ganz einfach, aber trotzdem tauchen immer wieder Vorschlaege auf, die das nicht beruecksichtigen. Und natuerlich gibt es jedes Mal die gleichen Probleme. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Guenther Meyer schrieb am 13.03.2010 22:16: nur weil diese bestimmte neue dinge falsch darstellen koennten, soll man sich jedes mal ein komplett neues tag aus den fingern saugen, anstatt bestehendes zu erweitern?!? Sie koennten in diesem Fall die neuen Eintrage nicht falsch darstellen, sondern es wird zwangslaeufig so kommen. Und natuerlich kann man auch bestehende Tags erweitern, man muss halt nur dabei darauf achten, dass das zu keinen Konflikten fuehrt, wenn die Erweiterung nicht erkannt wird. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice als Referenz brauchbar? + Fahrradparken
Am 13.03.2010 11:36, schrieb Thomas Wedekind: [..] Zum Betreff: Nein wirklich keine Referenz, denn ORS unterstützt keine Turn-Restrictions. Da kann man besser noch mit dem Rotuer von Google-Maps vergleichen, der berücksichtig zumindest die Abbiegebeschränkungen, die er kennt. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tauchen und die Tauchplätze
Das Problem dabei ist, dass ich schon einen Schlüssel brauche, den ich den Tauchplätzen zuordnen kann. Was machst Du denn wenn ein Node name=name 1 und scuba_divin:name=name2 hat? Ich wüßte nicht wofür das sinnvoll sein soll. Aber egal, solange ich nur einen Namen setze wird es ja so gerendert wie ich es will. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice als Referenz brauchbar? + Fahrradparken
Am 13.03.2010 19:42, schrieb Frederik Ramm: via-Element ein einzelner Node ist. only_...-Restrictions sowie Wobei Only das einzige sinnvoll Tagging ist, bei Kreuzungen von Straßen mit getrennten Richtungsfahrspuren, bei denen Linksabbiegen untersagt ist. Denn dort no turn left an die jeweiligen Ecken zu mappen ist zwar technisch nicht falsch, da turn right sich wg. Einbahnstraßenverletzung von selbst verbietet. Trotzdem ist die Kartendarstellung damit hinrissig. only straight ist da wirklich das Schild der Wahl. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Sat, 13 Mar 2010 22:23:40 +0100 hat Guenther Meyer d@sordidmusic.com geschrieben: Am Samstag 13 März 2010 21:09:41 schrieb Nils Heuermann: amenity=school sehe ich als allgemeinbildende Schule. Eben alles, wo man fürs Leben lernt: Grundschule, weiterführende Schulen, aber auch Internate (falls es da nicht sowieso einen eigenen Tag gibt) oder private Schulen, die Allgemeinwissen vermitteln. - eine fahrschule kann man auch fuers leben brauchen. - in der volkshochschule gibt's auch allgemeinbildung. - weiterfuehrende schulen: berufsschulen, private lehrinstitute, wo ziehst du die grenze? - was ist mit nachhilfeunterricht? zusätzlich könnte man vielleicht noch als Definition hinzunehmen, dass man regelmäßig und über einen längeren Zeitraum dort hingeht. Ja, das ist bei der Volkshochschule auch so, aber da ist der Kurs i. d. R. mittelfristig beendet. Und eine Schule ist nunmal etwas anderes als ein Verein etc., der Nachhilfeunterricht oder andere Lehrangebote durchführt. Aber ich muss dir hier sicher nicht erzählen, was eine *Schule* ist - das weißt du schließlich selber. Nur kann man halt nicht alles, was mit Schule und Lernern *zu tun hat* als Schule in die Karte^W Datenbank eintragen - zumindest nicht mehr jetzt, wo amenity=school schon belegt ist; da schließe ich mit Torstens Mails an. Würde ich den Schulungsraum, in dem hier der Stenoverein Kurse anbietet, ansonsten auch als school taggen? Da lernt man auch was. Eigentlich lernt man doch überall was :) Aber nicht alles ist amenity=school Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Samstag 13 März 2010 22:25:59 schrieb Torsten Leistikow: Das Problem bei so einer sinnveraendernden Erweiterung ist, dass all die Auswerteprogramme (Renderer usw.) das nicht automatisch mitbekommen. osm entwickelt sich weiter und veraendert sich staendig; als entwickler muss man da eben am ball bleiben. das heisst natuerlich nicht, dass man jedes tag das sich irgendjemand ausgedacht hat, gleich unterstuetzen muss, nur weil es dreimal vorkommt. aber die handhabung unbekannter erweiterungen fuer bestehende tags sollte inzwischen durchaus moeglich sein, und auch gemacht werden. Die sehen dann nur amenity=school und denken: Prima, das kenne ich. Fuer sie ist das also erstmal eine ganz normale Schule. Dass da noch irgendwelche Tags bei sind, die man nicht erkennt, ist bei OSM ja normal. eben, zusaetzliche tags sind bei osm normal. dann sollte man als entwickler ach darauf ruecksicht nehmen. Wenn man also eine derartig gekennzeichnete Fahrschule in die OSM-Datenbank eintraegt, dann wird der Eintrag von den Auswerteprogrammen falsch interpretiert. dann muessen die auswerteprogramme das eben lernen. Da ist es deutlich besser, wenn ein neues Tag erfunden wird, dass vom Auswerteprogramm gar nicht erkannt wird. das sehe ich anders. sowas foerdert nur den wildwuchs an immer neuen tags, und vergroessert das chaos. die daten sollten richtig sein, da gehoert fuer mich dazu, dass man zusammenfasst, was zusammengehoert. fuer eine bestimmte art der anwendung zu taggen, kann nicht sinn der sache sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Samstag 13 März 2010 22:31:22 schrieb Torsten Leistikow: Guenther Meyer schrieb am 13.03.2010 22:16: nur weil diese bestimmte neue dinge falsch darstellen koennten, soll man sich jedes mal ein komplett neues tag aus den fingern saugen, anstatt bestehendes zu erweitern?!? Sie koennten in diesem Fall die neuen Eintrage nicht falsch darstellen, sondern es wird zwangslaeufig so kommen. das ist reine definitionssache... ;-) Und natuerlich kann man auch bestehende Tags erweitern, man muss halt nur dabei darauf achten, dass das zu keinen Konflikten fuehrt, wenn die Erweiterung nicht erkannt wird. und wie willst du das als mapper sicherstellen? jede moegliche anwendung selbst anzupassen, ist nicht wirklich moeglich, und auch nicht sinnvoll. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
lächerlich. (Wir taggen nicht gegen die Renderer!) wir taggen auch nicht fuer den renderer! Sry - Mein ! hätte besser ein Smily sein sollen. Also: (Wir taggen nicht gegen die Renderer ;-) ) Inhaltlich gehe ich aber keinen Schritt zurück: eine fahrschule ist wie eine tauch/flug/volkshoch/grund/haupt-schule eine einrichtung, die dazu da ist, etwas zu lernen. deshalb gehoert das auch zusammen. Das mag ja sein, aber dafür ist es jetzt zu spät. Wer bestehende Tags um neue Bedeutungen erweitern will, soll besser neue Tags einführen. Sonst macht er nämlich bestehende Information in der Datenbank kaputt, indem er der bestehenden Information eine Bedeutung zuweisst, die sie nie haben sollte. -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tauchen und die Tauchplätze
Hallo Dimitri, Das Problem dabei ist, dass ich schon einen Schlüssel brauche, den ich den Tauchplätzen zuordnen kann. Was machst Du denn wenn ein Node name=name 1 und scuba_divin:name=name2 hat? ich würde name1 schreiben, da du bei scuba_divin:name=name2 das g vergessen hast ;-). Im Ernst würde ich wenn scuba_diving:name=name2 vorhanden ist name2 darstellen. Fehlt dieser Schlüssel würde ich schauen ob name=name1 vorhanden ist. Ist dies der Fall, würde ich name1 darstellen. Aber egal, solange ich nur einen Namen setze wird es ja so gerendert wie ich es will. Jupp, in sofern kein Problem. Beste Grüße Olaf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Samstag 13 März 2010 22:48:44 schrieb Nils Heuermann: Am Sat, 13 Mar 2010 22:23:40 +0100 hat Guenther Meyer d@sordidmusic.com geschrieben: Am Samstag 13 März 2010 21:09:41 schrieb Nils Heuermann: amenity=school sehe ich als allgemeinbildende Schule. Eben alles, wo man fürs Leben lernt: Grundschule, weiterführende Schulen, aber auch Internate (falls es da nicht sowieso einen eigenen Tag gibt) oder private Schulen, die Allgemeinwissen vermitteln. - eine fahrschule kann man auch fuers leben brauchen. - in der volkshochschule gibt's auch allgemeinbildung. - weiterfuehrende schulen: berufsschulen, private lehrinstitute, wo ziehst du die grenze? - was ist mit nachhilfeunterricht? zusätzlich könnte man vielleicht noch als Definition hinzunehmen, dass man regelmäßig und über einen längeren Zeitraum dort hingeht. Ja, das ist bei der Volkshochschule auch so, aber da ist der Kurs i. d. R. mittelfristig beendet. Und eine Schule ist nunmal etwas anderes als ein Verein etc., der Nachhilfeunterricht oder andere Lehrangebote durchführt. na gut, nach der definition gehoeren dann aber auch alle arten von hochschulen dazu. ebenso oeffentliche und private berufsschulen und lehrinstitute. warum aber soll dann die vhs und die fahrschule ausgenommen sein? wegen der kurzen dauer? dann gehoert die fos auch nicht dazu, schliesslich habe ich damals auch in einem jahr abgeschlossen... Aber ich muss dir hier sicher nicht erzählen, was eine *Schule* ist - das weißt du schließlich selber. Nur kann man halt nicht alles, was mit Schule und Lernern *zu tun hat* als Schule in die Karte^W Datenbank eintragen - zumindest nicht mehr jetzt, wo amenity=school schon belegt ist; da schließe ich mit Torstens Mails an. warum nicht? ich definiere schule als unterricht, evtl. ueber einen laengeren zeitraum. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Samstag 13 März 2010 22:59:39 schrieb Friedhelm Schmidt: Inhaltlich gehe ich aber keinen Schritt zurück: eine fahrschule ist wie eine tauch/flug/volkshoch/grund/haupt-schule eine einrichtung, die dazu da ist, etwas zu lernen. deshalb gehoert das auch zusammen. Das mag ja sein, aber dafür ist es jetzt zu spät. Wer bestehende Tags um neue Bedeutungen erweitern will, soll besser neue Tags einführen. Sonst macht er nämlich bestehende Information in der Datenbank kaputt, indem er der bestehenden Information eine Bedeutung zuweisst, die sie nie haben sollte. wer macht denn informationen kaputt? das bestehende tag ohne zusatzinformation hat weiterhin seine bekannte bedeutung... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Guenther Meyer schrieb: wer macht denn informationen kaputt? das bestehende tag ohne zusatzinformation hat weiterhin seine bekannte bedeutung... Wenn wir heute sagen: amenity=school + school=driving ist eine Fahrschule, dann haben wir die ursprüngliche Bedeutung (Schule im herkömmlichen Sinne) kaputt gemacht und alle Applikationen müssen umprogrammiert werden. Hingegen wäre eine Spezialisierung (school=Hauptschule/Grundschule/Gymnasium) vollkommen in Ordnung. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Postgis Datenbank, Größe des Index
Hallo zusammen, mir ist aufgefallen, dass die Datenbank ziemlich viel Platz belegt für einen kleineren extract. Habe dann mal genauer hingesehen. Der Index ist ziemlich groß. Ist das normal, dass er 4 mal so groß ist wie die eigentlichen Daten? VACUUM FULL und REINDEX haben nichts geändert. Table statistics planet_osm_ways Table Size 408 MB Toast Table Size30 MB Indexes Size1635 MB Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Samstag 13 März 2010 23:30:46 schrieb Chris-Hein Lunkhusen: Guenther Meyer schrieb: wer macht denn informationen kaputt? das bestehende tag ohne zusatzinformation hat weiterhin seine bekannte bedeutung... Wenn wir heute sagen: amenity=school + school=driving ist eine Fahrschule, dann haben wir die ursprüngliche Bedeutung (Schule im herkömmlichen Sinne) kaputt gemacht und alle Applikationen müssen umprogrammiert werden. wie bereits geschrieben: applikationen sollten mit sowas umgehen koennen. das wird einmal implementiert, dann muss man da nix mehr umprogrammieren. abgesehen davon sind sowie staendig anpassungen noetig... Hingegen wäre eine Spezialisierung (school=Hauptschule/Grundschule/Gymnasium) vollkommen in Ordnung. und eine fahrschule ist keine spezialisierung? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Torsten Leistikow glaubte zu wissen: Guenther Meyer schrieb am 13.03.2010 22:09: wer hat wo was lernen muessen?!? Das Problem bei so einer sinnveraendernden Erweiterung ist, dass all die Auswerteprogramme (Renderer usw.) das nicht automatisch mitbekommen. Die sehen dann nur amenity=school und denken: Prima, das kenne ich. Fuer sie ist das also erstmal eine ganz normale Schule. Dass da noch irgendwelche Tags bei sind, die man nicht erkennt, ist bei OSM ja normal. Wenn man also eine derartig gekennzeichnete Fahrschule in die OSM-Datenbank eintraegt, dann wird der Eintrag von den Auswerteprogrammen falsch interpretiert. Da ist es deutlich besser, wenn ein neues Tag erfunden wird, dass vom Auswerteprogramm gar nicht erkannt wird. Ich tagge eigentlich für die Datenbank und nicht für irgendwelche Auswerteprogramme, die zum jetzigen Zeitpunkt etwas nicht können, das aber später mal beherrschen können. Was kommt als nächstes? Ein extra Tag für eine LKW- Fahrschule, weil bei Fahrschule jeder an PKW denkt? Ich bleib dabei: Eine Fahrschule ist eine Schule. Und wenn man den Namen Fahrschule $Irgendwas einträgt, sollte der angezeigt werden und keinem ein Problem bereiten. flo -- Wer kann mir ein Thema für eine Facharbeit in Deutsch vorschlagen ??? Ansatz einer Analyse der Zusammenhänge zwischen der Anzahl der in einem Interrogativsatz enthaltenen Fragezeichen, der Dringlichkeit der Frage und der psychisch-emotionalen Auswirkungen auf den Leser [Berk Binay und Volker Gringmuth in desd] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Friedhelm Schmidt glaubte zu wissen: ich fände ein amenity=school school=driving besser, damit die Werte für amenity nicht ausufern, und das ganze eine überschaubare Struktur behält. +1 amentiy=school und dann was für eine. Sonst blickt da nachher keiner mehr durch. -1 Wir müssen die Legacy[1]-Tags respektieren. Sonst taucht die Fahrschule, Flugschule, Rückenschule mit dem ABC-Symbol in den Karten auf, das ist lächerlich. Nö. Überall geht man zum lernen hin, es heißt nicht umsonst Schule. Ich hätte da kein Problem damit. Wie soll denn eine Flugschule, Rückenschule, Fahrschule... ... auf der Karte aussehen, damit man auch noch was damit anfangen kann? Bei dem ABC- Symbol und Fahrschule BREMS! weiß jeder, was es sein soll. (Wir taggen nicht gegen die Renderer!) ... und auch nicht für die Renderer. Wir taggen für die Datenbank. Ich seh den Sinn nicht, ein neues tag einzuführen, nur weil ein oder mehrere Renderer nicht mit einer Erweiterung eines tags zurechtkommt. Taggen wir am Ende für jeden Renderer einzeln? Sowas wie OpenSeaMap und Freie Tonne mal X? Eine Fahr-, Rücken-, Flugschule sind keine Schule, sondern ein Gewerbe. Dann müßte ich jetzt die Privatschulen in der Gegend umtaggen, da mit denen auch Geld verdient wird? Und eine Volkshochschule ist keine Schule sondern eine öffentliche Einrichtung. Wenn dich einer auf der Straße nach der nächsten Schule fragt, fragst du dann zurück: Äh, meinen Sie eine Fahrschule oder eine Hundeschule?. Nein, du wirst eine Grund-, Haupt-, Real-, Berufs-, Walldorf-, ...-, Gesamtschule oder ein Gymnasium nennen - oder? Nein, ich frage ihn, was für eine Schule er denn sucht. Ähnliches gilt auch für Kliniken: eine Tierklinkik ist nun mal kein hospital sonder höchstens ein animal_hospital. Eine Ampel oder ein Stopschild ist auch keine Straße oder ein Weg, warum wird das trotzdem mit highway= getaggt? flo -- Eine Wildsau stand am Strassenrand, Wusch sich den Arsch mit Silbersand. Das war ein selten blödes Schwein. Das kann nur ein Dau gewesen sein. [WoKo in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
2010/3/13 Torsten Leistikow de_m...@gmx.de - keine Doppelungen von Wegen an Schnittgrenzen Das koennte fuers Routing notwendig sein, ja das ist notwendig. jeder weg muss mindestens einen node ausserhalb der kachel haben. mkgmap generiert dann exakt auf der Grenze einen boundary node - keine abgeschnittenen oder verstümmelten Polygone/Wege Sehe ich nicht als Vorteil, ist wohl eher eine Geschmacksfrage. seh ich auch so wozu sollte der Rest gut sein. Deshalb wird ja in Kacheln aufgeteilt damit eben der ganze Rest weg ist. - keine zusätzlich berechnteten Nodes nötig Auch das koennte fuers Routing notwendig sein, splitter generiert keine nodes. mkgmap muss das machen - geringerer Speicherbedarf auf Kosten der Laufzeit (wobei ich nicht weiss wie lange splitter an der ganzen Welt rechnen würde) Die aktuelle splitter version ist sehr schnell braucht relative wenig speicher und kann bei knappem speicher ein komplettes planet files in mehreren iterationen splitten. ___ 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] Fahrschule
Friedhelm Schmidt fschm...@extend.de [Sat, Mar 13, 2010 at 10:59:39PM CET]: [...] macht er nämlich bestehende Information in der Datenbank kaputt, indem er der bestehenden Information eine Bedeutung zuweisst, die sie nie haben sollte. Das klingt so, als sei die Bedeutung ein für allemal festgelegt. Dafür ist das Datenmodell doch zu dynamisch, auch wenn man solche Bedeutungserweiterungen natürlich vorsichtig diskutieren sollte. Wenn eine weiterführende Schule mit einem ABC-Icon nahelegt, sie sei für ABC-Schützen, sieht das auch komisch aus. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
