[talk-ph] Accu-map's GPS maps
Hi guys, Accu-map is the mapping division of Asiatype which creates those beautiful Metro Manila Citiatlas maps. Last year, they partnered with AVT ( http://www.avt.ph/ ) to bring routable GPS navigation for cars and released their P18.5k Navigator A800 product early this year. Anyway, check out Accu-maps forums (http://www.accu-map.com/forum/index.php) where the AVT users talk about the map data provided by Accu-map. Register and check out all the interesting threads. The Bugs Fixes thread under the Metro Manila sub-forum is an eye-opener in particular since users are pointing out weird routings and the like. I think it's because the users paid P18.5k for this so that's why they are passionate (and sometimes irritated) when they get suboptimal (or even illegal) routing. I really think we can learn a thing or two from the forums there. Two advantages of OSM is that 1) we're free (so users lower their expectations) and 2) they can help fix the data themselves instead of just filing bug reports. :-) Eugene / seav -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Accu-map's GPS maps
On Mon, Jul 13, 2009 at 12:42 AM, Eugene Alvin Villarsea...@gmail.com wrote: weird routings and the like. I think it's because the users paid P18.5k for this so that's why they are passionate (and sometimes irritated) when they get suboptimal (or even illegal) routing. I really think we can learn a thing or two from the forums there. GPS routing particularly in the Philippines (as I myself discovered from bug reports in our OSM-PH GPS map) will always give some weird results. This is partly due to lack of data and routing algorithms (at least for Garmins) is not really optimal within the Philippine context. Some people expect the GPS to route them to their favorite driving route, because its the fastest, shortest and walang huli. Auto-routing is dumb (that's why I don't always follow it) unless you explicitly tell them what to do. I guess I'll lurk around the avt forums to learn a thing or two. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] GPS reservation request
Hmmm a mapping party in Pampanga? Anyone? On Sun, Jul 12, 2009 at 11:23 PM, Ronny Ager-Wick - Develo Ltd.r...@develo.ltd.uk wrote: Hi guys, We're planning a trip to the Phils and thought it would be a good idea to use the opportunity to do some traces at the same time. It'll be mostly around Magalang, Pampanga, but also in the neighboring towns like Angeles, Dau and hopefully a trip to Mt. Pinatubo (into the crater). I hope to be able to map some unmapped territory while I'm there. I put a reservation request here: http://wiki.openstreetmap.org/wiki/WikiProject_Philippines/GPStogo_program#Reservation_requests A GPS logger with car charger would be preferable, unless they have battery life of up to two-three days. Please let me know if any are available. I assume you can use these things with Linux (Ubuntu)? The davao guys murlwe and smackcode used the gpstogo units with tangogps: http://mapping.ideacampdavao.com/2009/06/diy-gps-navigation-rig.html @ murlwe and smackcode, Is it possible to use the cyclemap instead of the the default osm map within tangogps? That would be a better map to use in pinatubo. ___ 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
[talk-ph] finally met murlwe last friday and some thoughts we discussed
As the subject says, I met murlwe last Friday, he returned one of the gpstogo units (which will be lent to ronny by august). We had a very interesting conversation I would like to share to the group. * Expanding the gpstogo program - gps loggers (for example navman) are now very cheap. You can get a blue-tooth enabled unit for less than 2K PHP. Most phones have a bluetooth. Won't get into the details but I think you get the idea. Plutocrat has this rig: http://epsg4253.wordpress.com/2009/07/01/plutocrat-osm-ph-mapper/ If we can raise some cash let's say 20K PHP, we can buy 20 data loggers and lend them to more mappers. Jim (from one of his mails) suggested to make it a competition. If the mapper can gather X number of traces with the loaned unit, the mapper can own the gps. Now the question is, how can we raise the funds? * OSM-PH mini-conference - murlwe and the rest of the Davao mappers is very much interested in this. Their ideacamp-davao spurred a lot of interest for OSM down south. I think the ideacamp format (similar to unconference/bar-camp event) can be adopted here. He suggested we need about 6 months lead time to get this rolling. It doesn't have to be in Manila, btw. If anyone can sponsor the event in any place I think everyone is OK with that. * Neuraltech - is developing really cool things around OSM data (address geocoding, routing, etc.) which is of particular interest to some of you. I'll leave it to murlwe and smackcode to share them to us. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] finally met murlwe last friday and some thoughts we discussed
one more to add. Palawan import - murlwe proposes we import the data as way/node without tags (probably just a note=FIXME) and then allow Palawan mappers to correct position and add tags base on GPS and local knowledge. On 7/13/09, maning sambale emmanuel.samb...@gmail.com wrote: As the subject says, I met murlwe last Friday, he returned one of the gpstogo units (which will be lent to ronny by august). We had a very interesting conversation I would like to share to the group. * Expanding the gpstogo program - gps loggers (for example navman) are now very cheap. You can get a blue-tooth enabled unit for less than 2K PHP. Most phones have a bluetooth. Won't get into the details but I think you get the idea. Plutocrat has this rig: http://epsg4253.wordpress.com/2009/07/01/plutocrat-osm-ph-mapper/ If we can raise some cash let's say 20K PHP, we can buy 20 data loggers and lend them to more mappers. Jim (from one of his mails) suggested to make it a competition. If the mapper can gather X number of traces with the loaned unit, the mapper can own the gps. Now the question is, how can we raise the funds? * OSM-PH mini-conference - murlwe and the rest of the Davao mappers is very much interested in this. Their ideacamp-davao spurred a lot of interest for OSM down south. I think the ideacamp format (similar to unconference/bar-camp event) can be adopted here. He suggested we need about 6 months lead time to get this rolling. It doesn't have to be in Manila, btw. If anyone can sponsor the event in any place I think everyone is OK with that. * Neuraltech - is developing really cool things around OSM data (address geocoding, routing, etc.) which is of particular interest to some of you. I'll leave it to murlwe and smackcode to share them to us. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] invitation by bmw club
Seav blogged about our OSM evangelization with BMW car owners: http://vaes9.codedgraphic.com/posts/osm_bmw_meetup On 6/29/09, maning sambale emmanuel.samb...@gmail.com wrote: On 6/18/09, maning sambale emmanuel.samb...@gmail.com wrote: I just got an invitation for a breakfast meeting with the bmw club. They are interested in our project mostly for gps navigation. They want to know more about OSM-PH especially how to use garmin nuvis and mapsource and other osm tools. If anybody wants to join (I can probably insist to bring along 2 OSMers) and help me share OSM love to these guys, let me know. It will be this sunday 9AM at the fort. (btw, it's fathers day) -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- hi, Yesterday was our talk with bmw car club about OSM (the pronounced it as awesome!) and GPS. Thanks to Rally and Eugene for joining and sharing their experiences. Here's what they have to say about us: http://www.bmwcarclub.org.ph/forum/showthread.php?p=20677#post20677 See post 38 onwards -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- 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
[OSM-talk] touristic car routes
Just noticed a marked scenic route for cars. Any suggestions for the route tag fort the relation that could mark this kind of routes? name=..., type=route, route=car ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM TrustPoints
Fixing subway stations in Rome wouldn't be prohibited to newcomers if they limit themselves for that day to Rome, encouraging them to focus on an area rather than jumping around the globe changing things (True value of OSM is _local_ knowledge!). They could be first only allowed to map within some kilometers around their home, but that might be too restrictive and demotivating. As for number of daily affected nodes the number shouldn't be too low, but low enough to prevent moving or deleting whole cities (whether accidental or malicious) or importing some data without consulting the community (about legal and technical issues) and having some help from experienced members. I personally often travel along some long route (100-200 km in my case), then I start adding POIs and other stuff I saw along the route once I get home. And there are people travelling much longer routes (long road routes across US/australia or even flights - one user in one day can easily add some details on road to some european airport and then another details on road from one airport in south america to nearest city centre for example) I don't think we should put any hard limits on the bbox. Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM TrustPoints
--- On Sun, 12/7/09, MP singular...@gmail.com wrote: (long road routes across US/australia or even flights - one user in Even the current limits make it time consuming downloading multiple areas to cover drives in rural areas I've taken in the last month alone. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help getting webkit up on vista 64?
I'm using JOSM on Vista64 with Yahoo imagery. Am 12.07.2009 00:15, David Carmean: Not sure if this is inappropriate, but I want to use Yahoo imagery with JOSM. I can't figure out how to get webkit-image built. 1.) Make sure that both JOSM and the WMS plugin are up to date. 2.) Check the WMS section in JOSM settings. The Yahoo Sat-entry should look like this: html:http://josm.openstreetmap.de/wmsplugin/YahooDirect.html? 3.) Download webkit-image.zip [2] 4.) Unzip it 5.) Move the contents so that the DLL files and the EXE file are somewhere on your system path. The best way to achieve this might be to place them alongside josm-latest.jar Make sure to keep the 'imageformats' subfolder structure intact when unzipping. For further reference see [1] Claudius [1] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/WMSPlugin [2] http://josm.openstreetmap.de/download/windows/webkit-image.zip ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help getting webkit up on vista 64?
Am 12.07.2009 06:00, David Carmean: On Sun, Jul 12, 2009 at 01:55:17AM +, John Smith wrote: --- On Sat, 11/7/09, David Carmeand...@halibut.com wrote: Not sure if this is inappropriate, but I want to use Yahoo imagery with JOSM. I can't figure out how to get webkit-image built. You no longer need to, the latest version pulls yahoo imagery from a JOSM server. So it does! However, in my neighborhood, JOSM shows a very pixellated image at high zoom, while the yahoo web interface shows aerial photos at what must be about 0.1m resolution. Yahoo's resolution inside JOSM depends on the zoom level inside JOSM that is active when you click on activating (!) the WMS layer. So if you have a scale of 100m in JOSM and click on WMS - Yahoo Sat you get higher resolution images opposed to clicking on it with a scale of 1000m Claudius ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Error loading data with osm2pgsql
Thanks for your help Jon. Yes, I'm using Windows and as you can tell, I'm a newbie at this map stuff. I've managed to get Postgres installed with PostGIS extensions and I've got GeoServer set up as well. I tried downloading the osm2pgsql from the link you gave me and it appears to download a 1.7Mb file but when I try to unzip it, the unzip software tells me the file is empty. Jon Burgess-2 wrote: On Fri, 2009-07-10 at 13:32 -0700, trossachs wrote: Ah. Thanks. The error message was a bit general. I was trying to import the UK osm and I'm running an Intel Core 2 Quad with 4Gb of RAM. I tried a small osm file (1.7Mb zipped) and it loaded ok. I re-tried with the uk osm file using the --slim option but it now says that --slim is not an option I'm using osm2pgsql_latest.exe OK, so your using Windows The --slim option should be supported by the latest code @ http://tileserv.openstreetmap.org/osm2pgsql.zip I retried it with osm2pgsql and the -s option but it fell over with an AddGeometryColumns() - invalid SRID error. Try adding the 900913.sql into your DB, it should be in the osm2pgsql.zip Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- View this message in context: http://www.nabble.com/Error-loading-data-with-osm2pgsql-tp24418427p24448428.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Error loading data with osm2pgsql
On Sun, 2009-07-12 at 05:59 -0700, trossachs wrote:
Thanks for your help Jon.
Yes, I'm using Windows and as you can tell, I'm a newbie at this map stuff.
I've managed to get Postgres installed with PostGIS extensions and I've got
GeoServer set up as well.
I tried downloading the osm2pgsql from the link you gave me and it appears
to download a 1.7Mb file but when I try to unzip it, the unzip software
tells me the file is empty.
The file should be 1.8MB (1850788 bytes exactly)
The file works for me, the example below was just done using Linux
tools:
$ wget http://tileserv.openstreetmap.org/osm2pgsql.zip
--2009-07-12 14:19:13-- http://tileserv.openstreetmap.org/osm2pgsql.zip
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 1850788 (1.8M) [application/zip]
Saving to: `osm2pgsql.zip'
100%[=]
1,850,788 --.-K/s in 0.07s
2009-07-12 14:19:13 (25.7 MB/s) - `osm2pgsql.zip' saved [1850788/1850788]
[jburg...@shark tmp]$ unzip osm2pgsql.zip
Archive: osm2pgsql.zip
creating: osm2pgsql/
inflating: osm2pgsql/zlib1.dll
inflating: osm2pgsql/bz2-1.dll
inflating: osm2pgsql/900913.sql
inflating: osm2pgsql/libiconv-2.dll
inflating: osm2pgsql/default.style
inflating: osm2pgsql/README.txt
inflating: osm2pgsql/libxml2-2.dll
inflating: osm2pgsql/libpq.dll
inflating: osm2pgsql/osm2pgsql.exe
[jburg...@shark tmp]$ osm2pgsql/osm2pgsql.exe
osm2pgsql SVN version 0.55-20081113 $Rev: 10464 $
Usage:
osm2pgsql.exe [options] planet.osm
osm2pgsql.exe [options] planet.osm.{gz,bz2}
osm2pgsql.exe [options] file1.osm file2.osm file3.osm
This will import the data from the OSM file(s) into a PostgreSQL database
suitable for use by the Mapnik renderer
Options:
-a|--append Add the OSM file into the database without removing
existing data.
-b|--bboxApply a bounding box filter on the imported data
Must be specified as: minlon,minlat,maxlon,maxlat
e.g. --bbox -0.5,51.25,0.5,51.75
-c|--create Remove existing data from the database. This is the
default if --append is not specified.
-d|--databaseThe name of the PostgreSQL database to connect
to (default: gis).
-l|--latlong Store data in degrees of latitude longitude.
-m|--mercStore data in proper spherical mercator (default)
-M|--oldmerc Store data in the legacy OSM mercator format
-E|--proj numUse projection EPSG:num
-u|--utf8-sanitize Repair bad UTF8 input data (present in planet
dumps prior to August 2007). Adds about 10% overhead.
-p|--prefix Prefix for table names (default planet_osm)
-s|--slimStore temporary data in the database. This greatly
reduces the RAM usage but is much slower.
-S|--style Location of the style file. Defaults to ./default.style
-C|--cache Only for slim mode: Use upto this many MB for caching
nodes
Default is 800
-U|--usernamePostgresql user name.
-W|--passwordForce password prompt.
-H|--hostDatabase server hostname or socket location.
-P|--portDatabase server port.
-h|--helpHelp information.
-v|--verbose Verbose output.
Add -v to display supported projections.
Use -E to access any espg projections (usually in /usr/share/proj/epsg)
Jon
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Error loading data with osm2pgsql
My first download must have got corrupted, somehow, and Windows cached it in
my Temporary Internet files folder. I deleted this and re-tried the download
and this time it was successful.
I ran the 900193.sql script and then ran the osm2pgsql with the -s option
and it's busy reading the osm file and loading up the database!
Happy days!
Thanks again for your help.
I'll try and repay the favour to any newbs having problems on Windows
Jon Burgess-2 wrote:
On Sun, 2009-07-12 at 05:59 -0700, trossachs wrote:
Thanks for your help Jon.
Yes, I'm using Windows and as you can tell, I'm a newbie at this map
stuff.
I've managed to get Postgres installed with PostGIS extensions and I've
got
GeoServer set up as well.
I tried downloading the osm2pgsql from the link you gave me and it
appears
to download a 1.7Mb file but when I try to unzip it, the unzip software
tells me the file is empty.
The file should be 1.8MB (1850788 bytes exactly)
The file works for me, the example below was just done using Linux
tools:
$ wget http://tileserv.openstreetmap.org/osm2pgsql.zip
--2009-07-12 14:19:13-- http://tileserv.openstreetmap.org/osm2pgsql.zip
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 1850788 (1.8M) [application/zip]
Saving to: `osm2pgsql.zip'
100%[=]
1,850,788 --.-K/s in 0.07s
2009-07-12 14:19:13 (25.7 MB/s) - `osm2pgsql.zip' saved [1850788/1850788]
[jburg...@shark tmp]$ unzip osm2pgsql.zip
Archive: osm2pgsql.zip
creating: osm2pgsql/
inflating: osm2pgsql/zlib1.dll
inflating: osm2pgsql/bz2-1.dll
inflating: osm2pgsql/900913.sql
inflating: osm2pgsql/libiconv-2.dll
inflating: osm2pgsql/default.style
inflating: osm2pgsql/README.txt
inflating: osm2pgsql/libxml2-2.dll
inflating: osm2pgsql/libpq.dll
inflating: osm2pgsql/osm2pgsql.exe
[jburg...@shark tmp]$ osm2pgsql/osm2pgsql.exe
osm2pgsql SVN version 0.55-20081113 $Rev: 10464 $
Usage:
osm2pgsql.exe [options] planet.osm
osm2pgsql.exe [options] planet.osm.{gz,bz2}
osm2pgsql.exe [options] file1.osm file2.osm file3.osm
This will import the data from the OSM file(s) into a PostgreSQL database
suitable for use by the Mapnik renderer
Options:
-a|--append Add the OSM file into the database without
removing
existing data.
-b|--bboxApply a bounding box filter on the imported data
Must be specified as: minlon,minlat,maxlon,maxlat
e.g. --bbox -0.5,51.25,0.5,51.75
-c|--create Remove existing data from the database. This is
the
default if --append is not specified.
-d|--databaseThe name of the PostgreSQL database to connect
to (default: gis).
-l|--latlong Store data in degrees of latitude longitude.
-m|--mercStore data in proper spherical mercator (default)
-M|--oldmerc Store data in the legacy OSM mercator format
-E|--proj numUse projection EPSG:num
-u|--utf8-sanitize Repair bad UTF8 input data (present in planet
dumps prior to August 2007). Adds about 10%
overhead.
-p|--prefix Prefix for table names (default planet_osm)
-s|--slimStore temporary data in the database. This greatly
reduces the RAM usage but is much slower.
-S|--style Location of the style file. Defaults to
./default.style
-C|--cache Only for slim mode: Use upto this many MB for
caching nodes
Default is 800
-U|--usernamePostgresql user name.
-W|--passwordForce password prompt.
-H|--hostDatabase server hostname or socket location.
-P|--portDatabase server port.
-h|--helpHelp information.
-v|--verbose Verbose output.
Add -v to display supported projections.
Use -E to access any espg projections (usually in /usr/share/proj/epsg)
Jon
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
:-D
--
View this message in context:
http://www.nabble.com/Error-loading-data-with-osm2pgsql-tp24418427p24448994.html
Sent from the OpenStreetMap -
Re: [OSM-talk] touristic car routes
On Sun, 12 Jul 2009 12:14:45 +0200 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com wrote: Just noticed a marked scenic route for cars. Any suggestions for the route tag fort the relation that could mark this kind of routes? name=..., type=route, route=car I have been using: tag k=route v=road/ tag k=type v=route/ for example http://wiki.openstreetmap.org/wiki/Canada:Alberta#Tourist.2FScenic_Trails which are 'official' tourist trails around Alberta, Canada. Simon. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] touristic car routes
Simon Wood wrote: On Sun, 12 Jul 2009 12:14:45 +0200 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com wrote: Just noticed a marked scenic route for cars. Any suggestions for the route tag fort the relation that could mark this kind of routes? name=..., type=route, route=car I have been using: tag k=route v=road/ tag k=type v=route/ That would work, if it wasn't the case that those tags are now in use for road number routes, so all E-roads in Europe have a route=road relation for example, and several countries have them for many more road numbers. This is something completely different obviously. I'd say route=motorcar would be a good option (to be consistent with existing route=bicycle and route=foot for cycle and walking routes). Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] touristic car routes
On Sun, 12 Jul 2009 19:20:51 +0200 Ben Laenen benlae...@gmail.com wrote: Simon Wood wrote: On Sun, 12 Jul 2009 12:14:45 +0200 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com wrote: Just noticed a marked scenic route for cars. Any suggestions for the route tag fort the relation that could mark this kind of routes? name=..., type=route, route=car I have been using: tag k=route v=road/ tag k=type v=route/ That would work, if it wasn't the case that those tags are now in use for road number routes, so all E-roads in Europe have a route=road relation for example, and several countries have them for many more road numbers. This is something completely different obviously. I'd say route=motorcar would be a good option (to be consistent with existing route=bicycle and route=foot for cycle and walking routes). Ben It is still a route through (several?) roads though. The 'network' key allows you to differentiate between E-roads, tourists routes, other country route numbers, etc. -- Joseph Booker signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] touristic car routes
Joseph Booker wrote: It is still a route through (several?) roads though. The 'network' key allows you to differentiate between E-roads, tourists routes, other country route numbers, etc. With that argument you should also tag bus, cycle and walking routes with route=road. I don't want to get into a discussion arguing why road numbers aren't a route, but I hope you can see that road numbers are a completely different concept compared to the concepts of touristic car routes, or bicycle routes, or bus routes, etc. So while I still think it shouldn't even be type=route, since it's in use now for road numbers, it should at least have a different route tag. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Upload of mass data
Hi all I have a lot of data that I now want to upload onto OSM. The data includes Roads, streets, rivers, parks. All data is in shp format. Any suggestions Andre ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Upload of mass data
We have now a bulk_upload/import mailinglist for this (just created today), maybe go and ask there. Jonas Am 12.07.2009 um 20:47 schrieb Andre Schoonbee andre...@iway.na: Hi all I have a lot of data that I now want to upload onto OSM. The data includes Roads, streets, rivers, parks. All data is in shp format. Any suggestions Andre ___ 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] Street lines aren't rendering for me in my own Planet - PostGIS - mapnik map
Hi there, I'm trying to set up my own rendering with mapnik but the resulting images/tiles don't show streets/polygons normally, see: The OSM map: http://www.flickr.com/photos/avarab/3713947443/ My map: http://www.flickr.com/photos/avarab/3714745132/ And some tiles I generated with generate_tiles.py: http://openstreetmap.is/not-rendering-correctly/ When you zoom in the streets are actually there, they just don't have their normal colored casing. This is what I did to import the database: http://www.mediawiki.org/wiki/Extension:SlippyMap/Mapnik The database itself looks fine as far as I can tell, it has ways in that area at least: gis= select osm_id, name from planet_osm_line where osm_id = 32669907; osm_id | name --+- 32669907 | Hornbrekkuvegur (1 row) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Street lines aren't rendering for me in my own Planet - PostGIS - mapnik map
On Sun, Jul 12, 2009 at 10:58 PM, Ævar Arnfjörð
Bjarmasonava...@gmail.com wrote:
Hi there, I'm trying to set up my own rendering with mapnik but the
resulting images/tiles don't show streets/polygons normally, see:
The OSM map: http://www.flickr.com/photos/avarab/3713947443/
My map: http://www.flickr.com/photos/avarab/3714745132/
And some tiles I generated with generate_tiles.py:
http://openstreetmap.is/not-rendering-correctly/
When you zoom in the streets are actually there, they just don't have
their normal colored casing.
This is what I did to import the database:
http://www.mediawiki.org/wiki/Extension:SlippyMap/Mapnik
The database itself looks fine as far as I can tell, it has ways in
that area at least:
Actually I get this in the pgsql error log:
2009-07-12 23:29:17 GMT ERROR: function asbinary() does not exist at
character 8
2009-07-12 23:29:17 GMT HINT: No function matches the given name and
argument types. You might need to add explicit type casts.
2009-07-12 23:29:17 GMT STATEMENT: select asbinary() as
geom,military,name,waterway,way_area from
(select way,amenity,military,way_area,waterway,name
from planet_osm_polygon
where name is not null
order by z_order,way_area desc
) as text
where setSRID('BOX3D(-2078059.694145257
9895070.006294288,-2073879.013716863
9898363.641982334)'::box3d,-1218672940)
That function exists in the gis DB:
gis= \df asbinary
List of functions
Schema | Name | Result data type | Argument data types
+--+--+-
public | asbinary | bytea| geometry
public | asbinary | bytea| geometry, text
(2 rows)
But it's a bit odd, I'm getting roads-text, turning circles,
leisure=pitch, and some other small stuff, but nothing else basically.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Street lines aren't rendering for me in my own Planet - PostGIS - mapnik map
On Sun, Jul 12, 2009 at 11:31 PM, Ævar Arnfjörð
Bjarmasonava...@gmail.com wrote:
On Sun, Jul 12, 2009 at 10:58 PM, Ævar Arnfjörð
Bjarmasonava...@gmail.com wrote:
Hi there, I'm trying to set up my own rendering with mapnik but the
resulting images/tiles don't show streets/polygons normally, see:
The OSM map: http://www.flickr.com/photos/avarab/3713947443/
My map: http://www.flickr.com/photos/avarab/3714745132/
And some tiles I generated with generate_tiles.py:
http://openstreetmap.is/not-rendering-correctly/
When you zoom in the streets are actually there, they just don't have
their normal colored casing.
This is what I did to import the database:
http://www.mediawiki.org/wiki/Extension:SlippyMap/Mapnik
The database itself looks fine as far as I can tell, it has ways in
that area at least:
Actually I get this in the pgsql error log:
2009-07-12 23:29:17 GMT ERROR: function asbinary() does not exist at
character 8
2009-07-12 23:29:17 GMT HINT: No function matches the given name and
argument types. You might need to add explicit type casts.
2009-07-12 23:29:17 GMT STATEMENT: select asbinary() as
geom,military,name,waterway,way_area from
(select way,amenity,military,way_area,waterway,name
from planet_osm_polygon
where name is not null
order by z_order,way_area desc
) as text
where setSRID('BOX3D(-2078059.694145257
9895070.006294288,-2073879.013716863
9898363.641982334)'::box3d,-1218672940)
That function exists in the gis DB:
gis= \df asbinary
List of functions
Schema | Name | Result data type | Argument data types
+--+--+-
public | asbinary | bytea | geometry
public | asbinary | bytea | geometry, text
(2 rows)
But it's a bit odd, I'm getting roads-text, turning circles,
leisure=pitch, and some other small stuff, but nothing else basically.
Ldp on IRC helped me out with this, I was running mapnik
0.5.1-3ubuntu2 but 6.0 is required. I didn't think it was because it's
not mentioned in the wiki documentation.
But the wiki is always out of date eh:)
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Potlach revisited
Aloha, Sinds lange tijd heb ik weer wat met OSM gedaan (te druk met allerlei andere zaken). Maar wat een verschil zeg de huidige potlach met de potlach van 2 jaar (?) geleden... Werkt echt een stuk fijner. Ik heb nog niet echt de neiging om JOSM (als dat er nog is) te downen, terwijl ik dat toendertijd wel erg snel deed. Achter de help knop zou het handig zijn om bij 'read more' een directe link naar de mogelijke tags: http://wiki.openstreetmap.org/wiki/Map_Features En ik weet niet of die pagina er is, maar een pagina met veel voorkomende tags-vragen zou handig zijn (alhoewel dat is natuurlijk weer erg landenspecifiek). Groets, Jaap-Andre, zitten toch wel rare dingen in de AND-data. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] keep right issue
++ 11/07/09 21:39 +0200 - Rejo Zenger: ++ 11/07/09 20:10 +0200 - Hans van Wijk: Ik denk dat je gelijk hebt; bij highway-waterway checks heb ik al vaker gemerkt dat het niet goed gaat. Ik heb de developer inmiddels een mail gestuurd erover. Specifiek hierover? Een zelfde issue speelt hier: http://keepright.ipax.at/report_map.php?zoom=18lat=52.37642lon=4.82389layers=B0Tch30=1ch40=1ch50=1ch60=1ch70=1ch90=1ch100=1ch110=1ch120=1ch130=1ch150=1ch160=1ch170=1ch180=1ch190=1ch191=1ch192=1ch193=1ch194=1ch200=1ch201=1ch202=1ch203=1ch204=1ch210=1ch220=1show_ign=1show_tmpign=1 -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] keep right issue
2009/7/11 Rejo Zenger osm-talk...@subs.krikkit.nl: Hi, Kan iemand mij vertellen waarom Keep Right voor het voetgangerspad een issue aangeeft: http://keepright.ipax.at/report_map.php?zoom=18lat=52.37542lon=4.84341layers=B0Tch30=1ch40=1ch50=1ch60=1ch70=1ch90=1ch100=1ch110=1ch120=1ch130=1ch150=1ch160=1ch170=1ch180=1ch190=1ch191=1ch192=1ch193=1ch194=1ch200=1ch201=1ch202=1ch203=1ch204=1ch210=1ch220=1show_ign=1show_tmpign=1 De history van die way staat hier: http://www.openstreetmap.org/browse/way/35957936/history Ik denk zelf dat het een fout van Keep Right is, maar ik wilde graag een third opinion. :) Zou het niet kunnen zijn dat de database van Keepright wat achterloopt, en de fout slaat op de versie van dmarinus? -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] keep right issue
++ 12/07/09 12:17 +0200 - Andre Engels: Zou het niet kunnen zijn dat de database van Keepright wat achterloopt, en de fout slaat op de versie van dmarinus? Nee, de laatste update van KR was van na de tweede wijziging (die van stroet34). Overigens is de error nu niet meer in beeld. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] keep right issue
Milo van der Linden wrote: http://osmose.openstreetmap.fr/ Leuke tool, wellicht (deels) te adopteren/integreren met keepright I wrote: Ik heb derhalve hem ook gewezen op deze site en gevraagd of een aantal checks in de toekomst ook bruikbaar zouden kunnen zijn in keepright. Reactie van Harald (developer keepright): Die site is gemaakt door Etienne en hij heeft, voor hij begon, toestemming gevraagd in the source van keepright te grasduinen. Harald heeft het grootste deel van de checks van Etienne op zijn ToDo list gezet voor implementatie in keepright. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] Adopt-an-area
While most of OSM contributors are students and poor, some OSM contributors, especially here, are not... I'm making a suggestion for those who are not poor (students can ignore this) that we could pick developing countries with mappers on the ground and provide some assistance - advice on the map, help with data loggers and any other sort of help. I found one group had one GPS enabled phone between them and were running a competition on how many edits to see who got the GPS next. That group has accepted my offer of a data logger and one of the solar powered i-Blue PS-757 units will go over there - not a large cost to me but i think it will be a bonus to them. I know there is a complex UK administered gps loans system, and I could have donated to that, but I'd rather adopt-an-area in a more personal way. Liz ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Adopt-an-area
--- On Sun, 12/7/09, Liz ed...@billiau.net wrote: I'm making a suggestion for those who are not poor (students can ignore this) that we could pick developing countries with mappers on the ground and provide some assistance - advice on the map, help with data loggers and any other sort of help. While this is very laudable, when ever I start pondering about this I keep coming back to how under mapped Australia is. It's quite frustrating, a lot of those countries have people willing and able, but lack the technology to do something about it, and we lack in people that are willing and able. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] validator plugin updates
Pretty much all my patches have been incorporated into the current build, I have come across some extra things that need to be added to the ignore list, such as: cuisine=coffee_shop cuisine=fish_and_chips cuisine=pie Anyone else know of any that should also be listed showing up as warnings? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Orchards
Greetings List, In the North Coast region there are a lot of fruit/nut plantations and I think it would be great to be able to differentiate between farmland which is used to graze cattle and farmland which is mostly orchards or sugar cane. I've read through the discussion about the landuse=vinyard tag (http://wiki.openstreetmap.org/wiki/Proposed_features/Vineyard) and the general consensus seems to be that landuse=farm, produce=blah is the best approach. Anyway, just opening this up for debate in the hope that an Australian convention can be decided on. Brent ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Orchards
--- On Sun, 12/7/09, b.schulz...@scu.edu.au b.schulz...@scu.edu.au wrote: I've read through the discussion about the landuse=vinyard tag (http://wiki.openstreetmap.org/wiki/Proposed_features/Vineyard) and the general consensus seems to be that landuse=farm, produce=blah is the best approach. No idea on the best approach, although that seems reasonable, and instead of grazing you could have produce=beef|sheep|goat|dairy. Although how finely do you want to do this, for example near Moree they grow a lot of cotton, but they also have a pecan nut farm, would it be produce nut or pecan_nut? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Adopt-an-area
Fiji is my adopted country. I traced a fair bit of the roads to hopefully inspire a local to start naming streets. There is finally at least one active mapper there armed with a GPS and uploading GPX files and naming streets, with another guy naming everything in Suva. I have been mainly mentoring the mapper to assit with getting the edits right. Won't be sending any equipment, but are happy to assist in this way. 2009/7/12 John Smith delta_foxt...@yahoo.com --- On Sun, 12/7/09, Liz ed...@billiau.net wrote: I'm making a suggestion for those who are not poor (students can ignore this) that we could pick developing countries with mappers on the ground and provide some assistance - advice on the map, help with data loggers and any other sort of help. While this is very laudable, when ever I start pondering about this I keep coming back to how under mapped Australia is. It's quite frustrating, a lot of those countries have people willing and able, but lack the technology to do something about it, and we lack in people that are willing and able. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Adopt-an-area
On Mon, 13 Jul 2009, Greg Harper wrote: Fiji is my adopted country. I traced a fair bit of the roads to hopefully inspire a local to start naming streets. There is finally at least one active mapper there armed with a GPS and uploading GPX files and naming streets, with another guy naming everything in Suva. I have been mainly mentoring the mapper to assit with getting the edits right. Won't be sending any equipment, but are happy to assist in this way. Sounds great - mentoring is very worthwhile. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Orchards
On Sun, 12 Jul 2009, b.schulz...@scu.edu.au wrote: I've read through the discussion about the landuse=vinyard tag (http://wiki.openstreetmap.org/wiki/Proposed_features/Vineyard) and the general consensus seems to be that landuse=farm, produce=blah is the best approach. Anyway, just opening this up for debate in the hope that an Australian convention can be decided on. This is one of those things that makes the difference between the cheap maps and the expensive ones. It certainly adds to the map, but living in an intensively farmed area I find it a bit frightening that I would have to mark vineyards / orchards / etc Landuse is the tag which gets rendered as the nice symbols or colours on the map. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Oodnadatta Track
It looks like the Oodnadatta Track hasn't been drawn yet. I will be driving along this in September, and visiting a few of the national parks. I can get access to an etrex legend GPS. I'll be taking a Windows netbook with me. Is there someone who wants to work with me, to take the GPS traces and upload them? Depending on internet access (Telstra NextG), I might be able to upload some information while still in the field. Russell Lang gsv...@ghostgum.com.au Ghostgum Software Pty Ltd http://www.ghostgum.com.au/ ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Oodnadatta Track
Hi Russell, Yes, the track itself has been done. The southern half, Marree to the Coober Pedy turnoff had been done a little while ago; I finished the northern half in June. It's the road to the west of Lake Eyre: http://www.openstreetmap.org/?lat=-28.31lon=136.21zoom=8layers=0B00FTF There are plenty other roads nearby though; I planned to do the Painted Desert road, for exmaple, but ran out of time. The track to the east of Lake Eyre is the Birdsville Track, then east again is the Strzelecki Track. There's no NextG access (though when I did the Strzelecki Track I was surprised to find that NextG is now available at Moomba). Happy travelling. Gordon On Mon, Jul 13, 2009 at 7:23 AM, Russell Lang gsv...@ghostgum.com.auwrote: It looks like the Oodnadatta Track hasn't been drawn yet. I will be driving along this in September, and visiting a few of the national parks. I can get access to an etrex legend GPS. I'll be taking a Windows netbook with me. Is there someone who wants to work with me, to take the GPS traces and upload them? Depending on internet access (Telstra NextG), I might be able to upload some information while still in the field. Russell Lang gsv...@ghostgum.com.au Ghostgum Software Pty Ltd http://www.ghostgum.com.au/ ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- Gordon Smith http://las.new-england.net.au/ http://blog.macalba.net/ ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Hauptwege auf Friedhöfen
um es nochmal zu detaileren. es geht um wege die auch von behinderten befahren werden dürfen - nicht nur vom f-gärtner. gruß Jan :-) Sven Geggus schrieb: Jan Tappenbeck o...@tappenbeck.net wrote: wie würdet Ihr Hauptwege auf einem Friedhof, die mit einem PKW befahrbar sind taggen ??? SERVICE ist sehr prägnant !!! http://www.tappenbeck.net/osm/maps/deu/maps4osm.php?id=22zoom=16lat=53.89336lon=10.66236layers=B00TT Ja sicher, aber das ist ein renderingproblem. Die Wege sind genau das, ein Serviceweg. Wir mappen ja nicht für die Renderer :) http://geggus.net/gmaps/myfsmap.html?zoom=16lat=49.01716lon=8.43381layers=B000F Selbes in grün. Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
highway = service hat für mich den Hintergedanken, dass PKW/LKW wirklich öfter dort lang fahren. Ich würde dies daher nur für Straßen innerhalb des Friedhofs anwenden. Da die Wege aber einfach breiter sind und die Hauptnutzer Fussgänger sind, aber auch mal vom ansässigen Gärtner oder Friedhofsbetreiber benutzt werden können, sehe ich highway = track als die beste Variante. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeinden und Samtgemeinden über 10. 000 Einwohner
On Sat, Jul 11, 2009 at 12:04:46AM +0200, Tirkon wrote: Maxspeed durch Flaeche ist quatsch IMHO .. Da ist viel zu viel fehlerpotential vorhanden - wo wir behaupten etwas erfasst zu haben aber im zweifelsfalle niemand da war ... Ich habe noch nicht expizit nachgelesen, wie maxspeed in geschlossenen Ortschaften gemappt wird. Ich hatte mal angenommen, dass dies durch Flächen geschieht, da es mir naheliegend erscheint. Die Fläche ergibt sich durch die Ortseingangsschilder. In Deutschland gilt dann innerhalb dieser Flöche 50km/h, sofern maxspeed nicht explizit angegeben. Was spricht denn dagegen? Gemeinden koennen durchaus entscheiden die geschwindigkeit innerhalb geschlossener ortschaften anheben - Es gibt durchaus strecken wo man auch innerhalb geschlossener ortschaften dann 70 fahren darf ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] WMS am MAC - warum funktioniert das bei mir nicht besonders?
Hallo, ich versuche unter MAC OS 10.4.11 mit JOSM (früher tested und jetzt latest z.Zt. 1758) seit geraumer Zeit das WMS Plugin zu betreiben. Leider habe ich damit nur wenig erfolg. Meist bekomme ich den roten Hintergrund mit der FEHLER Meldung. Nur bei Landsat bekomme ich ein farbiges Bild, das so Schemenhaft ist, dass damit nichts anzufangen ist. - Bearbeiteter Bereich: Schweinfurt und Unterfranken (Nordbayern) - ich arbeite meist mit einer sehr hohen Auflösung, da ich einige Fußwege und Straßen um Wohnbereich bearbeite. - An den Einstellungen wurde nichts verändert (d.h. JOSM installiert (512MB) - Plugin installiert - los) - http://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/WMSPlugin#Verwenden_des_Plugins kenne ich. aber da steht zum MAC reichlich wenig... Hat jemand eine IDEE die wie ich das zum Laufen bekomme? Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
André Riedel schrieb: highway = service hat für mich den Hintergedanken, dass PKW/LKW wirklich öfter dort lang fahren. Ich würde dies daher nur für Straßen innerhalb des Friedhofs anwenden. Dies gilt auch für highway=track, besonders für trackgrade=1 (Wirtschaftswege Co) Da die Wege aber einfach breiter als was? auf allen Friedhöfen? sind und die Hauptnutzer Fussgänger sind, aber auch mal vom ^^ ansässigen Gärtner oder Friedhofsbetreiber benutzt werden können, sehe ich highway = track als die beste Variante. Ich nicht. Du sagst selbst: Hauptnutzer=Fußgänger Warum nicht highway=footway benutzen? diese sind normalerweise auch für Rollstuhlfahrer benutzbar. Die Oberflächenbeschaffenheit kann man mit surface=* angeben, die Breite mit width=* mit access kannst du angeben, wer/ws sich auf den Wegen bewegen darf. Ich kann mir nicht vorstellen, dass jemand, der auf dem Friedhof mit einem Kfz herumfahren muss, nicht weiß, ob dies möglich ist. Wenn ein Bestatter wirklich eine Fernfahrt mit Ziel=Friedhof erledigen muss, wird er auch wegen anderer Sachen mit den lokalen Verantwortlichen Kontakt aufnehmen müssen. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Hallo. Am Samstag, 11. Juli 2009 schrieb Sven Geggus: Hintergrund ist, dass inzwischen tendenziell alle Freiflächen als landuse=farm getaggt werden und das IMO unvorteilhaft gerendert wird. Ich habe noch nie irgendeine normale Karte (!=OSM) gesehen in denen zwischen Freifläche und Farmland unterschieden wird. Zur Klarstellung: landuse=farm hat sich so derbe in zwei Sichtweisen verfahren, dass wir hier lieber über landuse=farmland diskutieren sollten. landuse=farm kann keiner ernsthaft auswerten, weil es zu lange parallel für verschiedene Dinge benutzt wurde. Aber ansonsten: Ja, bitte, weg von den normalen Renderern. Ich frage mich immer: Was ist denn ein farmland? Landwirtschaftliche Flächen unterscheiden sich je nach Jahreszeit, nach Region, nach Fruchtfolge, ... Es gibt keine typische landwirtschaftliche Fläche die überregional gelten würde. Und schon gar keine Farbe, die man dem Dingen geben kann Oft sind es (überspitzt gesagt) irgendwelche Stadtkinder, die dieses Tag überall dran kleben wo keine Häuser und keine Bäume stehen. Kaum einer macht sich die Mühe, auch mal beim Bauern nachzufragen, ob das bewirtschaftetes Gebiet ist. Vielleicht ist es ja Brachland (wird oft auch einmal im Jahr gemäht)? Zudem muss jedem, der dieses Tag verwendet, klar sein, dass es sich ungleich schwieriger aktuell halten lässt. Es gibt eine Menge Leute, die das total sinnlos finden und es ändert sich auch zu oft. Es gibt viele Wiesen, die nach 3 Jahren mal rumgedreht werden und dann 2 Jahre Acker sind. D.h. wenige Idealisten müssen das Tagging sehr oft ändern. Rendert man alles in einem grünen Einheitsbrei, taugt das IMHO überhaupt nicht. Bei braunem Einheitsbrei ebenfalls nicht. Ergo: In den aktuell verbreiteten Abstufungen und bei so vielen Leuten die das nur inkonsequent machen, ist das Tagging für Freiflächen sinnlos. Gruß, Bernd -- Fachbegriffe der Informatik (#367): Patentverhandlungen Beide Firmen drucken ihre Patente aus und legen die Stapel nebeneinander. Der mit dem höheren Stapel hat gewonnen. (Rainer Zocholl zitiert einen Patentanwalt) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Hallo! Sven Geggus schrieb: ich weiss, dass dieses Posting das Zeug hat einen Flamewar auszulösen, aber ich empfinde es ehrlich gesagt als Blödsinn alle Felder als landuse=farm zu taggen! Ich bin ganz Deiner Meinung. Es ist der Normalfall in Deutschland und somit keine sonderlich wertvolle Information. Außerdem veraltet die Information sehr schnell und müßte zweimal jährlich geprüft und upgedated werden, da sich die Nutzung Feld/Gras ständig verändert. Hintergrund ist, dass inzwischen tendenziell alle Freiflächen als landuse=farm getaggt werden und das IMO unvorteilhaft gerendert wird. Auch das sehe ich genauso. Durch die ganzen Agrarflächen wird die Karte unübersichtlich, der Kontrast geht völlig verloren und die Wege sind schlechter erkennbar. Das ist interessant für eine Bodennutzungskarte, aber auf einer Straßenkarte hat das absolut nichts verloren, da will ich die Wegeverbindungen möglichst schnell und klar erkennen. Meiner Ansicht nach wären zwei Dinge nötig: - Allgemeine Straßen/Wegekarten sollten farm/farmland und grass nicht rendern. Meine Topokarte ignoriert diese Tags bereits konsequent. - JOSM sollte in der Lage sein, Areas auszublenden bzw. in einer getrennten Layer darzustellen, damit eine Gegend trotz flächendeckender Polygone noch editierbar bleibt. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-WMS-Problem (mal wieder)
Peter Herison schrieb: Hast Du mal laenger gewartet? So 2-5 Minuten? Auch nach 10 Minuten tut sich bei meinem Rechner nichts. Irgendwas habe ich offensichtlich kaputtgespielt, nur leider weiss sich z.Z. nicht mal, ob es an JOS, WMS,Gnome-Web-Photo oder allgemein an den Systemeinstellungen liegt. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Hi! Mirko Küster schrieb: Ich habe noch nie irgendeine normale Karte (!=OSM) gesehen in denen zwischen Freifläche und Farmland unterschieden wird. Und deswegen sollten wir auch nicht? Ich sehe das eher als riesen Vorteil. Es hat schlichtweg einen Sinn, daß sowas auf keiner Straßenkarte auftaucht. Der Nutzen für die Orientierung ist wegen der großen Anzahl an Feldern praktisch gleich null, aber die Übersichtlichkeit und der Kontrast der Karte leidet enorm darunter. Wenn es für jede existierende Straßenkarte besser ist, keine Äcker und Wiesen darzustellen, warum sollte es dann für eine OSM Karte anders sein? * Du renderst dir eine eigene Karte ohne Farmland. Oder sinnvoller: Trennung in Straßenkarte ohne und Flächennutzungkarte mit Farmland anstatt eierlegender Wollmilchkarte, auf der gar nix mehr klar zu erkennen ist. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Hi! Karl Eichwalder schrieb: Solange wir noch dabei sind, die grunddaten zu erheben, ist es sehr sinnvoll, diese farm-flächen explizit darzustellen. Nur so kann man das vor ort kontrollieren. Das macht Sinn - aber dann sollten diese Flächen in einer FIXME-Layer dargestellt werden, so wie unnamed Streets, nicht in der Hauptstraßenkarte. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Moin, Nop schrieb: Außerdem veraltet die Information sehr schnell und müßte zweimal jährlich geprüft und upgedated werden, da sich die Nutzung Feld/Gras ständig verändert. Interessant finde ich die Entwicklung, dass von vielen Leuten inzwischen offensichtlich farm (bzw. farmland) ausschliesslich fuer Aecker und Felder angedacht ist. Meinem Verstaendniss nach war das vor ca. einem Jahr noch so, dass jede Art der Landwirtschaftlichen Nutzung unter farm zusammengefasst war, also auch Wiesen und Weideflaechen. Wenn man das so versteht, dann aendert sich da auch nicht zwei mal jaehrlich das Tag. Wenn an da aber eine genauere Unterscheidung drunter versteht, dann ist das offensichtlich ein selbstgemachtes Leiden. - Allgemeine Straßen/Wegekarten sollten farm/farmland und grass nicht rendern. Da spricht aus meiner Sicht nichts gegen. Nur denke ich nicht, dass man die klassischen OSM-Renderer als reine Strassen/Wegekarten sehen sollte. Sonst mueste man da noch viel mehr Elemente aus der Darstellung rausnehmen. Meine Topokarte ignoriert diese Tags bereits konsequent. Also auf einer Topokarte moechte ich schon die Information haben, wie eine Gegend in etwa aussieht. Aber zum Glueck muessen wir uns ja nicht auf eine einzige Kartenansicht einigen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Torsten Leistikow de_m...@gmx.de writes: Interessant finde ich die Entwicklung, dass von vielen Leuten inzwischen offensichtlich farm (bzw. farmland) ausschliesslich fuer Aecker und Felder angedacht ist. Meinem Verstaendniss nach war das vor ca. einem Jahr noch so, dass jede Art der Landwirtschaftlichen Nutzung unter farm zusammengefasst war, also auch Wiesen und Weideflaechen. Wenn man das so versteht, dann aendert sich da auch nicht zwei mal jaehrlich das Tag. Eben. Und jetzt rennt die meute entweder in die nächste sackgasse oder an die nächste klippe... Wenn an da aber eine genauere Unterscheidung drunter versteht, dann ist das offensichtlich ein selbstgemachtes Leiden. Wobei man vielleicht gerechterweise einräumen sollte, das die akteure, die das eingebrockt haben, nicht unbedingt mit denen identisch sind, die das nun versuchen auszulöffeln ;) -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man Boyen, Tonnen, Leuchtfeuer, und alles andere was für eine Seekarte und andere intereesant werden könnte/sollte erfasst werden soll. Ich bin an einer OSM basierten Seekarte sehr interessiert, aber ich kann bis auf die Erfassung einiger Seezeichen wenig beitragen. Jan, Markus und Olaf (in alphabetischer Reihenfolge, ohne Wertung) haben sehr viel mehr geleistet, so dass ihnen das Vorschlagsrecht zusteht. Ich werde trotzdem mal meine Ideen zum Tagging der Seezeichen äußern. Vielleicht ist der eine oder andere Gedanke ja nützlich. Eine gute Definition der Tags ist wichtig. Unvollständige Wiki-Texte führen zu Mißverständnissen und später zu Streit. Irgendwann wird dann ein OSM-User behaupten, jedes schwimmende, algenbewachsene Objekt sei eine Lateraltonne grün. Namen sind Schall und Rauch. Ob eine Lateraltonne als buoy_lateral oder lateral_buoy definiert wird, ist zweitrangig. Wichtig ist, dass es eine eindeutige Beschreibung des Seezeichens bzw. der Ge- und Verbote eines Gewässerteils gibt. Dass das OSM-Datenschema mit der Norm IHO-S-57 korrespondiert, finde ich richtig. Die OSM-Tags müssen nicht exakt den IHO-Konventionen folgen. Eine eindeutige Zuordnung genügt. Sprechende OSM-Namen (buoy_lateral) finde ich besser als Abkürzungen (BOYLAT). Die Tags sollten nicht unnötig lang sein. Alle Seezeichen sollten mit jedem OSM-Editor ohne Zusatzprogramme editierbar sein. Die Wiki-Beschreibung oder eine Kopie eines ähnlichen Objekts sollten als Vorlage genügen (eine evangelische Kirche kann ich auch nicht ohne Hilfe korrekt eingeben). Für Leuchttürme mit Sektorenfeuer, die nicht sehr zahlreich sind, kann anderes gelten. Bereits vorhandene OSM-Tags (Fähre, boat, motorboat) sollten weiterbenutzt werden. Das DE:Tonne/Datenmodell von Olaf unter http://wiki.openstreetmap.org/wiki/DE:Tonne/Datenmodell gefällt mir recht gut. Die Tagnamen finde ich unnötig lang. Statt seamark:buoy_cardinal:name würde auch seamark:name genügen. OSM kommt sonst mit einem universellen name=* aus. Der lange Name ist umständlich zu tippen, passt möglicherweise nicht in jedes Textfeld, benötigt zusätzliche Abfragen in Renderern und Auswerteprogrammen. Zudem kann es zu Inkonsistenzen führen, wenn man ein seamark=buoy_safewater mit seamark:buoy_cardinal:name kombiniert. Ich würde Redundanz vermeiden. Wenn seamark=buoy_isolated_danger nur mir seamark:topmark:shape=2 spheres zu kombinieren ist, würde ein seamark:topmark=yes genügen. Zu Jans Vorschlägen unter http://www.freietonne.de/index.php?site=31infotyp=1printable=1 habe ich mich schon geäußert. Hauptkritikpunkt war, dass er strecken- oder flächenbezogene Verbote als Punktobjekte der Verbotsschilder taggen will. Er hat seine Konvention, in welcher Richtung ein Schild zu lesen ist, noch nicht erläutert. Häfen sind nicht einfach zu erfassen. Auf Übersichtskarten möchte man wahrscheinlich die wichtigen Handel-, Fähr und Militärhäfen als Punkt sehen, im mittleren Maßstab auch die Fischerei- und Yachthäfen und auf Detailkarten stört ein Hafenmittelpunkt. Dort möchte man die eher einzelnen Liegeplätze für die Großschiffahrt mit ihren Parametern sehen. Mir fehlen noch Tags für Markierungsbojen der Schwimmerbereiche (weißer Ball mit gelbem Kreuz), evtl. Nichtschwimmerbereichsbojen, Ankerbojen und dauerhafte Regattabojen. Ein Tag für Lichtsignalanlagen (typisch bei Schleusen, Klappbrücken, Kanalausweichstellen) wäre nützlich. Sehr wichtig ist ein Schema für Sperrgebiete, Warngebiete, Verbotszonen (keine Schwimmer, Kitesurfen verboten, etc.) und Beschränkungszonen (Geschwindigkeit, Tiefgang, etc) sowohl für Wasserflächen als auch für Kanal- und Flussabschnitte Für Seezeichen wäre eine Angabe der Positionsgenauigkeit (von der vorbeifahrenden Fähre geschätzt bis aus amtlicher Quelle übernommen) nützlich. Soweit zu meinen Vorstellungen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Von AVG überprüft - www.avg.de Version: 8.5.387 / Virendatenbank:
Re: [Talk-de] WMS am MAC - warum funktioniert das bei mir nicht?
Hallo Christian,
WMS auf dem Mac ist gar nich so schwer, habe aber auch mehrere Anläufe
gebraucht. Leider habe ich es noch nicht geschafft die gute Englische Anleitung
auch auf der deutschen Wikiseite verfügbar zu machen:
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/WMSPlugin#Configuration
Also einfach Intel Binary von
http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r45754.dmg
herunter laden, evtl brauchst du noch das QT Framework
http://get.qtsoftware.com/qt/source/qt-mac-cocoa-opensource-4.5.2.dmg
Theoretisch kann JOSM den Pfad zum Webkit aus der PATH Variable lesen, als ich
das installiert habe musste man den im JOSM in den WMS Einstellungen noch
selbst angeben. yahoo:///Users/stb/josm/webkit-image {0} Wichtig dabei sind die
drei '/' und das Leerzeichen vor '{0}'. Allerdings sollte das mit den neuen
Versionen von JOSM und wmsplugin nicht mehr nötig sein.
Hoffe mit diesen Hinweisen klappt es, wenn ja notiere die aktuell nötige
Vorgehensweise doch auf der deutschen Wiki-Seite. Die englische scheint
für die aktuellen Versionen auf dem neuesten Stand zu sein.
Gruß Christian
Message: 5
Date: Sun, 12 Jul 2009 10:16:04 +0200
From: UMAX974 umax...@googlemail.com
Subject: [Talk-de] WMS am MAC - warum funktioniert das bei mir nicht
besonders?
To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Message-ID: 4a599bc4.6020...@googlemail.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hallo,
ich versuche unter MAC OS 10.4.11 mit JOSM (fr?her tested und jetzt
latest z.Zt. 1758) seit geraumer Zeit das WMS Plugin zu betreiben.
Leider habe ich damit nur wenig erfolg. Meist bekomme ich den roten
Hintergrund mit der FEHLER Meldung. Nur bei Landsat bekomme ich ein
farbiges Bild, das so Schemenhaft ist, dass damit nichts anzufangen ist.
- Bearbeiteter Bereich: Schweinfurt und Unterfranken (Nordbayern)
- ich arbeite meist mit einer sehr hohen Aufl?sung, da ich einige
Fu?wege und Stra?en um Wohnbereich bearbeite.
- An den Einstellungen wurde nichts ver?ndert (d.h. JOSM installiert
(512MB) - Plugin installiert - los)
-
http://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/WMSPlugin#Verwenden_des_Plugins
kenne ich. aber da steht zum MAC reichlich wenig...
Hat jemand eine IDEE die wie ich das zum Laufen bekomme?
Christian
--
__
Christian Berreth
mail: christian.berr...@web.de
--
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Hi! Torsten Leistikow schrieb: - Allgemeine Straßen/Wegekarten sollten farm/farmland und grass nicht rendern. Da spricht aus meiner Sicht nichts gegen. Nur denke ich nicht, dass man die klassischen OSM-Renderer als reine Strassen/Wegekarten sehen sollte. Sonst mueste man da noch viel mehr Elemente aus der Darstellung rausnehmen. Willst Du damit behaupten, es _gibt_ noch gar keine Straßenkarte für OSM? Meine Topokarte ignoriert diese Tags bereits konsequent. Also auf einer Topokarte moechte ich schon die Information haben, wie eine Gegend in etwa aussieht. Aber zum Glueck muessen wir uns ja nicht auf eine einzige Kartenansicht einigen. Dann wirst Du Dir wohl Deine eigene rendern müssen. Ich will defintiv die Wege und die Höhenunterschiede sehen - und nicht die Äcker, die ich sowieso nicht betreten darf. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status update on the OpenStreetMap - Wikimedia project
Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: Things like authoring tools will be easier later once we have that and there'll be more motivation (and hopefully more people working on it) once the basic stuff is exposed to end users. I think, that the feature of embedded maps is the most important one for OSM in Wikipedia. The best advertising for OSM there would be, if the box-templates of articles like towns, villages, rivers, streets etc. will have got the OSM-bullet-point, together with a dummy-explanation how to use it. Possibly the coordinates, which are available in every box (in the german Wikipedia), could be used to show the embedded map automaticly in a standard-zoom, which can be fine-tuned with the help of a permalink by the editors of the article. Thus the OSM-map will show up in many geographic articles and the project would be rubbed under the nose of many Wikipedia users. The bad state of the map outside of metropolisis - in particular rural areas - will be thorn in the flesh of the committed and dedicated article-editors and thus help to win mappers and herewith coders there. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Moin, ich weiss, dass dieses Posting das Zeug hat einen Flamewar auszulösen, aber ich empfinde es ehrlich gesagt als Blödsinn alle Felder als landuse=farm zu taggen! Zumindest in Deutschland gibt es nunmal keine wirklich ungenutzen Flächen. Selbst die Ausweisung als Naturschutzgebiet kann man als Nutzung verstehen. ich empfinde es nicht unbedingt als Blödsinn, wenn eine Wiese, ein Feld oder ein Naturschutzgebiet als solches gemappt wird. Sonst könnten wir ja auch alle Wälder oder Wasserflächen wieder wegwerfen. Hintergrund ist, dass inzwischen tendenziell alle Freiflächen als landuse=farm getaggt werden und das IMO unvorteilhaft gerendert wird. Ersteres ist natürlich nicht im Sinne des Erfinders, aber IMO gibt sich das schon noch. Wir haben ja auch mit den Waldflächen eher grobschlächtig begonnen und verfeinern das schrittweise. Ich habe noch nie irgendeine normale Karte (!=OSM) gesehen in denen zwischen Freifläche und Farmland unterschieden wird. Hier stellt sich natürlich die Frage, ob die osmarender-Karten eher dazu da sind, den Mappern die Kontrolle ihrer Arbeit zu ermöglichen, oder eine schöne Karte zu haben. IMO eher ersteres. Ich sehe zwei Lösungen: * Die Renderer ignorieren in Zukunft landuse=farm außer für bestimmte landwirtschaftliche Spezialkarten oder sowas ;) * wir erfinden ein neues tag, das nicht gerendert wird Was denkt ihr? Auf einer Autokarte wird es wohl kaum jemanden interessieren, dass da Farmland oder so ist. Auf einer Radwanderkarte interessiert es mich aber schon, ob ich durch ein Braunkohleabbaugebiet, eine Industrielandschaft oder durch Grünland fahre. Und es ist die Information, die ich auf Google-Karten vermisse. Man könnte als Kompromiss die verschiedenen Grünflächen in osmarender so dezent halten, dass sie kaum auffallen, also ohne Rand und mit hoher Transparenz oder so. -- Beste Grüße, Best regards, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man Boyen, Tonnen, Leuchtfeuer, und alles andere was für eine Seekarte und andere intereesant werden könnte/sollte erfasst werden soll. Ich bin an einer OSM basierten Seekarte sehr interessiert, aber ich kann bis auf die Erfassung einiger Seezeichen wenig beitragen. Jan, Markus und Olaf (in alphabetischer Reihenfolge, ohne Wertung) haben sehr viel mehr geleistet, so dass ihnen das Vorschlagsrecht zusteht. Ich werde trotzdem mal meine Ideen zum Tagging der Seezeichen äußern. Vielleicht ist der eine oder andere Gedanke ja nützlich. Eine gute Definition der Tags ist wichtig. Unvollständige Wiki-Texte führen zu Mißverständnissen und später zu Streit. Irgendwann wird dann ein OSM-User behaupten, jedes schwimmende, algenbewachsene Objekt sei eine Lateraltonne grün. Namen sind Schall und Rauch. Ob eine Lateraltonne als buoy_lateral oder lateral_buoy definiert wird, ist zweitrangig. Wichtig ist, dass es eine eindeutige Beschreibung des Seezeichens bzw. der Ge- und Verbote eines Gewässerteils gibt. Dass das OSM-Datenschema mit der Norm IHO-S-57 korrespondiert, finde ich richtig. Die OSM-Tags müssen nicht exakt den IHO-Konventionen folgen. Eine eindeutige Zuordnung genügt. Sprechende OSM-Namen (buoy_lateral) finde ich besser als Abkürzungen (BOYLAT). Die Tags sollten nicht unnötig lang sein. Alle Seezeichen sollten mit jedem OSM-Editor ohne Zusatzprogramme editierbar sein. Die Wiki-Beschreibung oder eine Kopie eines ähnlichen Objekts sollten als Vorlage genügen (eine evangelische Kirche kann ich auch nicht ohne Hilfe korrekt eingeben). Für Leuchttürme mit Sektorenfeuer, die nicht sehr zahlreich sind, kann anderes gelten. Bereits vorhandene OSM-Tags (Fähre, boat, motorboat) sollten weiterbenutzt werden. Das DE:Tonne/Datenmodell von Olaf unter http://wiki.openstreetmap.org/wiki/DE:Tonne/Datenmodell gefällt mir recht gut. Die Tagnamen finde ich unnötig lang. Statt seamark:buoy_cardinal:name würde auch seamark:name genügen. OSM kommt sonst mit einem universellen name=* aus. Der lange Name ist umständlich zu tippen, passt möglicherweise nicht in jedes Textfeld, benötigt zusätzliche Abfragen in Renderern und Auswerteprogrammen. Zudem kann es zu Inkonsistenzen führen, wenn man ein seamark=buoy_safewater mit seamark:buoy_cardinal:name kombiniert. Ich würde Redundanz vermeiden. Wenn seamark=buoy_isolated_danger nur mir seamark:topmark:shape=2 spheres zu kombinieren ist, würde ein seamark:topmark=yes genügen. Zu Jans Vorschlägen unter http://www.freietonne.de/index.php?site=31infotyp=1printable=1 habe ich mich schon geäußert. Hauptkritikpunkt war, dass er strecken- oder flächenbezogene Verbote als Punktobjekte der Verbotsschilder taggen will. Er hat seine Konvention, in welcher Richtung ein Schild zu lesen ist, noch nicht erläutert. Häfen sind nicht einfach zu erfassen. Auf Übersichtskarten möchte man wahrscheinlich die wichtigen Handel-, Fähr und Militärhäfen als Punkt sehen, im mittleren Maßstab auch die Fischerei- und Yachthäfen und auf Detailkarten stört ein Hafenmittelpunkt. Dort möchte man die eher einzelnen Liegeplätze für die Großschiffahrt mit ihren Parametern sehen. Mir fehlen noch Tags für Markierungsbojen der Schwimmerbereiche (weißer Ball mit gelbem Kreuz), evtl. Nichtschwimmerbereichsbojen, Ankerbojen und dauerhafte Regattabojen. Ein Tag für Lichtsignalanlagen (typisch bei Schleusen, Klappbrücken, Kanalausweichstellen) wäre nützlich. Sehr wichtig ist ein Schema für Sperrgebiete, Warngebiete, Verbotszonen
Re: [Talk-de] JOSM-WMS-Problem (mal wieder)
Torsten Leistikow schrieb: Peter Herison schrieb: Hast Du mal laenger gewartet? So 2-5 Minuten? Auch nach 10 Minuten tut sich bei meinem Rechner nichts. Irgendwas habe ich offensichtlich kaputtgespielt, nur leider weiss sich z.Z. nicht mal, ob es an JOS, WMS,Gnome-Web-Photo oder allgemein an den Systemeinstellungen liegt. Klappt denn ein echter wms-layer, wie bspw. landsat? Wenn das funktioniert, liegt das Problem im yahoo-Bereich (gnome-web-photo/webkit/yahoodirect.html). Wenn das nicht geht, ist irgendwas mit dem wmsplugin nicht in Ordnung. Falls du mit wireshark (früher ethereal) halbwegs umgehen kannst, kannst du damit mal die Kommunikation mit dem Server anschauen. Dann siehst du schon mal, ob überhaupt eine Anfrage rausgeht oder ob es schon da klemmt. Grüße ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Haltestellen in ÖPNV-Relationen
Hallo zusammen, nachdem man auf der ÖPNV-Karte nun schon eine Weile die Haltestellen anklicken kann (ab Zoom 15) und ein Popup mit den dort haltenden Verkehrsmitteln sieht, Enthält dieses Popup nun auch Links zu Details der Linien, mit Haltestellenrteihenfolge. Dadurch erkennt man nun sehr schnell, dass die Haltestellenreihenfolge in den Relationen nur in seltenen Fällen korrekt ist. Ich vermute das liegt daran, dass man die Reihenfolge bisher nur in JOSM festlegen kann. Weis jemand ob sowas für die anderen Editoren in Entwicklung ist? Vielleicht bessert sich die Situation jetzt auch, wenn die Ergebnisse der Sortierung Sichtbar sind... Übrigens wenn man die Platformen mit in die Relationen aufnimmt verrät ein Klick darauf sogar welche Linien explizit auf diesem Gleis/Bussteig abfahren. Dann aber auf die Rollenvergabe achten, damit der Linienweg und die Plattformen auseinander zu halten sind (siehe http://wiki.openstreetmap.org/wiki/%C3%96pnvkarte#Rollen_der_Mitglieder) Gruß, Melchior ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Hi! Christoph Eckert schrieb: ich empfinde es nicht unbedingt als Blödsinn, wenn eine Wiese, ein Feld oder ein Naturschutzgebiet als solches gemappt wird. Sonst könnten wir ja auch alle Wälder oder Wasserflächen wieder wegwerfen. Der Vergleich hinkt. Wälder und Wasserflächen sind signifikante Landmarken und üblicherweise auf Karten enthaltne, Felder und Wiesen sind der wesentlich weniger signifikante Standard-Fall. Ich habe noch nie irgendeine normale Karte (!=OSM) gesehen in denen zwischen Freifläche und Farmland unterschieden wird. Hier stellt sich natürlich die Frage, ob die osmarender-Karten eher dazu da sind, den Mappern die Kontrolle ihrer Arbeit zu ermöglichen, oder eine schöne Karte zu haben. IMO eher ersteres. Für diesen Zwecke enthält sie wieder viel zu wenig Informationen. Auf der anderen Seite: Wenn es die Mapnik/Osmarender karten nciht sind: Wo ist dann die erste brauchbare Straßenkarte für OSM? Auf einer Autokarte wird es wohl kaum jemanden interessieren, dass da Farmland oder so ist. Auf einer Radwanderkarte interessiert es mich aber schon, ob ich durch ein Braunkohleabbaugebiet, eine Industrielandschaft oder durch Grünland fahre. Und es ist die Information, die ich auf Google-Karten vermisse. Das siehst Du ja auch: Wälder, Wasser, Steinbrüche, Tagebau, Industrie, Wohngebiete sind eingezeichnet. Wenn nix eingezeichnet ist, bist Du im Grünen. Man könnte als Kompromiss die verschiedenen Grünflächen in osmarender so dezent halten, dass sie kaum auffallen, also ohne Rand und mit hoher Transparenz oder so. Yep. Gar nicht rendern, oder so dezent daß es nicht stört. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
Hallo, Jan Tappenbeck o...@tappenbeck.net writes: um es nochmal zu detaileren. es geht um wege die auch von behinderten befahren werden dürfen - nicht nur vom f-gärtner. hier in der Stadt sind die Wege auch noch mit access=destination versehen: http://www.openstreetmap.org/browse/way/4045490 Da dürfen allerdings alle die auf den Friedhof wollen fahren, nicht nur Personen mit eingeschränktem Gehvermögen. Deshalb handelt es sich auch nicht direkt um eine Service-Straße. Viele Grüße Sebastian Waschik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Am 12.07.2009 11:53, Nop: Hi! Mirko Küster schrieb: Ich habe noch nie irgendeine normale Karte (!=OSM) gesehen in denen zwischen Freifläche und Farmland unterschieden wird. Und deswegen sollten wir auch nicht? Ich sehe das eher als riesen Vorteil. Es hat schlichtweg einen Sinn, daß sowas auf keiner Straßenkarte auftaucht. Der Nutzen für die Orientierung ist wegen der großen Anzahl an Feldern praktisch gleich null, aber die Übersichtlichkeit und der Kontrast der Karte leidet enorm darunter. Wenn es für jede existierende Straßenkarte besser ist, keine Äcker und Wiesen darzustellen, warum sollte es dann für eine OSM Karte anders sein? Weil ich bisher noch keine OSM-Straßenkarte kenne :) Wenn die jemand macht wird er/sie sicher etwas rumprobieren uund eventuell zu dem Ergebnis kommen, dass er farmland dabei nicht rendert. Mapnik ist jedenfalls keine Straßenkarte. Ich finde die Darstellung dort aber alles andere als unübersichtlich. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WMS am MAC - warum funktioniert das bei mir nicht?
Danke für den Tipp,
WebKit läuft an meinem MAC.
Aber QuickTime läuft in der Version nur bei Intel MAC mit OS 10.5
so modern bin ich noch nicht. meiner ist ein G4 mit OS 10.4.11 - gibt es
da auch eine Lösung?
Christian
Am 12.07.2009 12:45 Uhr, schrieb Christian Berreth:
Hallo Christian,
WMS auf dem Mac ist gar nich so schwer, habe aber auch mehrere Anläufe
gebraucht. Leider habe ich es noch nicht geschafft die gute Englische
Anleitung auch auf der deutschen Wikiseite verfügbar zu machen:
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/WMSPlugin#Configuration
Also einfach Intel Binary von
http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r45754.dmg
herunter laden, evtl brauchst du noch das QT Framework
http://get.qtsoftware.com/qt/source/qt-mac-cocoa-opensource-4.5.2.dmg
Theoretisch kann JOSM den Pfad zum Webkit aus der PATH Variable lesen,
als ich das installiert habe musste man den im JOSM in den WMS
Einstellungen noch selbst angeben.
yahoo:///Users/stb/josm/webkit-image {0} Wichtig dabei sind die drei
'/' und das Leerzeichen vor '{0}'. Allerdings sollte das mit den neuen
Versionen von JOSM und wmsplugin nicht mehr nötig sein.
Hoffe mit diesen Hinweisen klappt es, wenn ja notiere die aktuell
nötige Vorgehensweise doch auf der deutschen Wiki-Seite. Die englische
scheint für die aktuellen Versionen auf dem neuesten Stand zu sein.
Gruß Christian
Message: 5
Date: Sun, 12 Jul 2009 10:16:04 +0200
From: UMAX974 umax...@googlemail.com
Subject: [Talk-de] WMS am MAC - warum funktioniert das bei mir nicht
besonders?
To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Message-ID: 4a599bc4.6020...@googlemail.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hallo,
ich versuche unter MAC OS 10.4.11 mit JOSM (fr?her tested und jetzt
latest z.Zt. 1758) seit geraumer Zeit das WMS Plugin zu betreiben.
Leider habe ich damit nur wenig erfolg. Meist bekomme ich den roten
Hintergrund mit der FEHLER Meldung. Nur bei Landsat bekomme ich ein
farbiges Bild, das so Schemenhaft ist, dass damit nichts anzufangen
ist.
- Bearbeiteter Bereich: Schweinfurt und Unterfranken (Nordbayern)
- ich arbeite meist mit einer sehr hohen Aufl?sung, da ich einige
Fu?wege und Stra?en um Wohnbereich bearbeite.
- An den Einstellungen wurde nichts ver?ndert (d.h. JOSM installiert
(512MB) - Plugin installiert - los)
-
http://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/WMSPlugin#Verwenden_des_Plugins
kenne ich. aber da steht zum MAC reichlich wenig...
Hat jemand eine IDEE die wie ich das zum Laufen bekomme?
Christian
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - landuse=farmland
Am 12.07.2009 11:11, Bernd Wurst: Ich frage mich immer: Was ist denn ein farmland? Landwirtschaftliche Flächen unterscheiden sich je nach Jahreszeit, nach Region, nach Fruchtfolge, ... Es gibt keine typische landwirtschaftliche Fläche die überregional gelten würde. Und schon gar keine Farbe, die man dem Dingen geben kann Irgendwie antwortest du auf deine offenbar rhetorisch gemeinte Frage selber mit dem Eingeständnis, dass es eben doch so etwas wie landwirtschaftlich genutzte Flächen gibt, die sich im Detail unterscheiden. Ich finde landuse=farmland aber dennoch wichtig um festzuhalten, dass dort über Jahre hinweg eine landwirtschaftliche Nutzung stattfindet, es also eben nicht dauerhaft ungenutztes Land ist. In Deutschland ist Letzteres seeehr wenig zu finden (kenne aber beispielsweise solche Flächen rund um Eichstätt). In Iran ist aber beispielsweise ein Großteil der Landesfläche eben nicht durch Landwirtschaft in Anspruch genommen, sondern... einfach... Land. Gerade dafür ist das Tag sehr sinnvoll. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Am 12.07.2009 11:45, Nop: Ich bin ganz Deiner Meinung. Es ist der Normalfall in Deutschland und somit keine sonderlich wertvolle Information. Außerdem veraltet die Information sehr schnell und müßte zweimal jährlich geprüft und upgedated werden, da sich die Nutzung Feld/Gras ständig verändert. Aber ist beides (Ackerbau, Zwischenfrüchte und Wiese als Erholungsfläche [oder wie auhc immer der Agrarwirt dazu sagt] zwischen den Jahren) nicht eine landwirtschaftliche Nutzung und damit landuse=farmland? Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hi Mario Leider ist mir nicht bekannt ob du Seemann bist oder nicht. Wenn ja solltest du bedenken das wir Seemänner später einmal nach diesen Eingaben navigieren wollen. Dazu sollten die Angaben so sicher und vollständig wie möglich sein. Das wird durch vollständige Abfragen in einem Editor sicherlich leichter erreicht. Ich kann eigentlich nicht vertreten wenn vom Schema der S-57 abgegangen wird. Mir geht hier nicht um meiner ist besser oder länger sondern um Qualität. Da die Infos schwierig einzugeben sind findest du bei OSeaM auch noch keine Flächendecken Daten. Gruß Rolf Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man Boyen, Tonnen, Leuchtfeuer, und alles andere was für eine Seekarte und andere intereesant werden könnte/sollte erfasst werden soll. Ich bin an einer OSM basierten Seekarte sehr interessiert, aber ich kann bis auf die Erfassung einiger Seezeichen wenig beitragen. Jan, Markus und Olaf (in alphabetischer Reihenfolge, ohne Wertung) haben sehr viel mehr geleistet, so dass ihnen das Vorschlagsrecht zusteht. Ich werde trotzdem mal meine Ideen zum Tagging der Seezeichen äußern. Vielleicht ist der eine oder andere Gedanke ja nützlich. Eine gute Definition der Tags ist wichtig. Unvollständige Wiki-Texte führen zu Mißverständnissen und später zu Streit. Irgendwann wird dann ein OSM-User behaupten, jedes schwimmende, algenbewachsene Objekt sei eine Lateraltonne grün. Namen sind Schall und Rauch. Ob eine Lateraltonne als buoy_lateral oder lateral_buoy definiert wird, ist zweitrangig. Wichtig ist, dass es eine eindeutige Beschreibung des Seezeichens bzw. der Ge- und Verbote eines Gewässerteils gibt. Dass das OSM-Datenschema mit der Norm IHO-S-57 korrespondiert, finde ich richtig. Die OSM-Tags müssen nicht exakt den IHO-Konventionen folgen. Eine eindeutige Zuordnung genügt. Sprechende OSM-Namen (buoy_lateral) finde ich besser als Abkürzungen (BOYLAT). Die Tags sollten nicht unnötig lang sein. Alle Seezeichen sollten mit jedem OSM-Editor ohne Zusatzprogramme editierbar sein. Die Wiki-Beschreibung oder eine Kopie eines ähnlichen Objekts sollten als Vorlage genügen (eine evangelische Kirche kann ich auch nicht ohne Hilfe korrekt eingeben). Für Leuchttürme mit Sektorenfeuer, die nicht sehr zahlreich sind, kann anderes gelten. Bereits vorhandene OSM-Tags (Fähre, boat, motorboat) sollten weiterbenutzt werden. Das DE:Tonne/Datenmodell von Olaf unter http://wiki.openstreetmap.org/wiki/DE:Tonne/Datenmodell gefällt mir recht gut. Die Tagnamen finde ich unnötig lang. Statt seamark:buoy_cardinal:name würde auch seamark:name genügen. OSM kommt sonst mit einem universellen name=* aus. Der lange Name ist umständlich zu tippen, passt möglicherweise nicht in jedes Textfeld, benötigt zusätzliche Abfragen in Renderern und Auswerteprogrammen. Zudem kann es zu Inkonsistenzen führen, wenn man ein seamark=buoy_safewater mit seamark:buoy_cardinal:name kombiniert. Ich würde Redundanz vermeiden. Wenn seamark=buoy_isolated_danger nur mir seamark:topmark:shape=2 spheres zu kombinieren ist, würde ein seamark:topmark=yes genügen. Zu Jans Vorschlägen unter http://www.freietonne.de/index.php?site=31infotyp=1printable=1 habe ich mich schon geäußert. Hauptkritikpunkt war, dass er strecken- oder flächenbezogene Verbote als Punktobjekte der Verbotsschilder taggen will. Er hat seine Konvention, in welcher Richtung ein Schild zu lesen ist, noch nicht erläutert. Häfen sind nicht einfach zu erfassen. Auf Übersichtskarten möchte man wahrscheinlich die wichtigen Handel-, Fähr und
Re: [Talk-de] Hauptwege auf Friedhöfen
Am 12.07.2009 09:13, Jan Tappenbeck: um es nochmal zu detaileren. es geht um wege die auch von behinderten befahren werden dürfen - nicht nur vom f-gärtner. Dann erst Recht highway=service, da damit ja die Funktion als Zufahrtsweg betont wird. Ansonsten würde ich für die abzweigenden Wirtschaftswege die eigentlich ausschließlich von Fahrzeugen der Friedhofsgärtnerei verwendet werden auch als highway=track taggen wie andere hier im Thread auch schon anmerkten. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] down?
Am 12.07.2009 04:43, Tirkon: Claudiusclaudiu...@gmx.de wrote: Währenddessen könnt ihr Frederiks Präsentation State of the Map in Germany: Krautsorcing 2.0 Beta im Livestream anschauen: http://www.ustream.tv/channel/state-of-the-map Kann man irgendwo Aufzeichnungen der Vorträge von der SotM abrufen? Alle Vorträge wurden aufgezeichnet und werden nach der Konferenz online gestellt. (So jedenfalls das Versprechen. Hoffentlich gibt's keine technischen Probleme und alle Bänder sind leer :P ) Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Nop ekkeh...@gmx.de wrote: Es hat schlichtweg einen Sinn, daß sowas auf keiner Straßenkarte auftaucht. Der Nutzen für die Orientierung ist wegen der großen Anzahl an Feldern praktisch gleich null, aber die Übersichtlichkeit und der Kontrast der Karte leidet enorm darunter. Eben! Ich nehme mal an Du hast Das bei der Wanderkarte bewußt weggelassen. Mit Weinbergen und Obstplantagen sieht das schon anders aus, daran kann man sich orientieren. Sven -- Software patents are the software project equivalent of land mines: Each design decision carries a risk of stepping on a patent, which can destroy your project. (Richard M. Stallman) /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] landuse=farm - Tonne
Es hat schlichtweg einen Sinn, daß sowas auf keiner Straßenkarte auftaucht. Der Nutzen für die Orientierung ist wegen der großen Anzahl an Feldern praktisch gleich null, aber die Übersichtlichkeit und der Kontrast der Karte leidet enorm darunter. Wenn es für jede existierende Straßenkarte besser ist, keine Äcker und Wiesen darzustellen, warum sollte es dann für eine OSM Karte anders sein? * Du renderst dir eine eigene Karte ohne Farmland. Oder sinnvoller: Trennung in Straßenkarte ohne und Flächennutzungkarte mit Farmland anstatt eierlegender Wollmilchkarte, auf der gar nix mehr klar zu erkennen ist. Dann lassen es die Straßen bzw. Garminkarten raus und fertig. In der Hauptkarte tummeln sich inzwischen eine Menge Dinge die so eigentlich auf keiner Straßenkarte zu finden sind. Da müsste so einiges fliegen. Die Übersichtlichkeit krankt auch so an vielen Darstellungsproblemen die nunmal zu einer Karte gehören. Siehe z.B. bei Osmarender die fetten alles überdeckenden Wegwürste im Dammbereich. Oder die sich verdrängenden oder überlappenden Namen oder POIs. Da sind Äcker neben der Straße derzeit wirklich das kleinste Problem. BTW Bevor du das nächste mal ein Massenumtagging von Burgen betreibst, recherchiere bitte vorher um was es sich da eigentlich handelt. Die waren nach deiner Aktion in meiner Ecke fast sämtlichst falsch. Feinere Tags sind natürlich zu begrüßen, aber nur wenn es auch die richtigen sind. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSMTransport - ÖPNV-Karte
Konkurrenz belebt das Geschäft: Bei OsmTransport [1] kann man ein (Stadt-)Gebiet auswählen, dessen ÖPNV-Relationen (bisher leider nur nach dem alten Routenstandard) dann visualisiert werden. Einige Gebiete sind schon vorgerendert. Besonderheit des Angebots: Der color-Wert der Relation wird ausgewertet. Claudius [1] http://3liz.fr/public/osmtransport/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Torsten Leistikow de_m...@gmx.de wrote: Also auf einer Topokarte moechte ich schon die Information haben, wie eine Gegend in etwa aussieht. Die Topokarte von Nop ist IMO eine der besten Karten die wir haben und die Übersichtlichkeit würde IMO deutlich schlechter werden, wenn man landuse=farm(land) irgendwie rendern würde. Sven -- /* * Wirzenius wrote this portably, Torvalds fucked it up :-) */(taken from /usr/src/linux/lib/vsprintf.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] OSM Straßenkarte (war: landuse=far m - Tonne)
Am 12.07.2009 12:57, Nop: Torsten Leistikow schrieb: - Allgemeine Straßen/Wegekarten sollten farm/farmland und grass nicht rendern. Da spricht aus meiner Sicht nichts gegen. Nur denke ich nicht, dass man die klassischen OSM-Renderer als reine Strassen/Wegekarten sehen sollte. Sonst mueste man da noch viel mehr Elemente aus der Darstellung rausnehmen. Willst Du damit behaupten, es _gibt_ noch gar keine Straßenkarte für OSM? Der Stil Fresh auf den Cloudmade-Karten kommt einer Straßenkarte schon sehr nah: http://maps.cloudmade.com/?lat=51.406059lng=12.242546zoom=12styleId=997 Wer da noch Verbesserungen anbringen will kann einfach einen neuen Stil bauen und die Regeln von Fresh kopieren. Freue mich schon auf den ersten ADAC-Stil. Bitte hier posten. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
Am 12. Juli 2009 10:22 schrieb malenki o...@malenki.ch: André Riedel schrieb: highway = service hat für mich den Hintergedanken, dass PKW/LKW wirklich öfter dort lang fahren. Ich würde dies daher nur für Straßen innerhalb des Friedhofs anwenden. Dies gilt auch für highway=track, besonders für trackgrade=1 (Wirtschaftswege Co) Bei service stelle ich mir vor, dass da mehre PKW täglich langfahren und auch dürfen. Bei einem track stelle ich mir über das Jahr gesehen fast keinen Verkehr pro Tag vor, zumindest von der gesetzlich legalen Seite her. Da die Wege aber einfach breiter als was? auf allen Friedhöfen? sind und die Hauptnutzer Fussgänger sind, aber auch mal vom ^^ ansässigen Gärtner oder Friedhofsbetreiber benutzt werden können, sehe ich highway = track als die beste Variante. Ich nicht. Du sagst selbst: Hauptnutzer=Fußgänger Warum nicht highway=footway benutzen? diese sind normalerweise auch für Rollstuhlfahrer benutzbar. Die Oberflächenbeschaffenheit kann man mit surface=* angeben, die Breite mit width=* mit access kannst du angeben, wer/ws sich auf den Wegen bewegen darf. Ja das geht natürlich auch, beschreibt aber nicht, dass dort auch der Friedhofsgärtner mit seinem kleinen LKW langfahren kann. Mann kann dies nur mit motorcar = private umschreiben, aber in meiner Tag-Nutzung ist ein footway bzw. path nie oder nur in äußersten Ausnahmen mit PKW/LKW befahrbar. Desweiteren lässt sich dadurch eine gute Hierarchie zwischen Hauptwegen (track) und Wegen zu einzelnen Gräbern (path) abbilden. Ich kann mir nicht vorstellen, dass jemand, der auf dem Friedhof mit einem Kfz herumfahren muss, nicht weiß, ob dies möglich ist. Wenn ein Bestatter wirklich eine Fernfahrt mit Ziel=Friedhof erledigen muss, wird er auch wegen anderer Sachen mit den lokalen Verantwortlichen Kontakt aufnehmen müssen. Ich dachte bei highway = service auch eher an mehere km^2 große Friedhöfe, welche man vornehmlich in den USA findet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hi Rolf. Wer behauptet denn, dass ich vom Schema der S-57 abweiche? Ihr solltet nur vor lauter kompliziertem Beschreibungskatalog nicht vergessen es auch einfach/logisch/nachvollziehbar zu halten. Klar kann man Details mit beliebig vielen Tags beschreiben, und das ist auch richtig so. Aber wenn nicht auch schon minimalste Infos eine Aussage haben, dann nützt das Schema nicht viel. Mit buoy=lateral_port kann man z.B. einer Tonne eine eindeutige Funktion geben ohne auch nur ein Detail zu kennen. Gruß Mario Rolf Meyerhof schrieb: Hi Mario Leider ist mir nicht bekannt ob du Seemann bist oder nicht. Wenn ja solltest du bedenken das wir Seemänner später einmal nach diesen Eingaben navigieren wollen. Dazu sollten die Angaben so sicher und vollständig wie möglich sein. Das wird durch vollständige Abfragen in einem Editor sicherlich leichter erreicht. Ich kann eigentlich nicht vertreten wenn vom Schema der S-57 abgegangen wird. Mir geht hier nicht um meiner ist besser oder länger sondern um Qualität. Da die Infos schwierig einzugeben sind findest du bei OSeaM auch noch keine Flächendecken Daten. Gruß Rolf Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man Boyen, Tonnen, Leuchtfeuer, und alles andere was für eine Seekarte und andere intereesant werden könnte/sollte erfasst werden soll. Ich bin an einer OSM basierten Seekarte sehr interessiert, aber ich kann bis auf die Erfassung einiger Seezeichen wenig beitragen. Jan, Markus und Olaf (in alphabetischer Reihenfolge, ohne Wertung) haben sehr viel mehr geleistet, so dass ihnen das Vorschlagsrecht zusteht. Ich werde trotzdem mal meine Ideen zum Tagging der Seezeichen äußern. Vielleicht ist der eine oder andere Gedanke ja nützlich. Eine gute Definition der Tags ist wichtig. Unvollständige Wiki-Texte führen zu Mißverständnissen und später zu Streit. Irgendwann wird dann ein OSM-User behaupten, jedes schwimmende, algenbewachsene Objekt sei eine Lateraltonne grün. Namen sind Schall und Rauch. Ob eine Lateraltonne als buoy_lateral oder lateral_buoy definiert wird, ist zweitrangig. Wichtig ist, dass es eine eindeutige Beschreibung des Seezeichens bzw. der Ge- und Verbote eines Gewässerteils gibt. Dass das OSM-Datenschema mit der Norm IHO-S-57 korrespondiert, finde ich richtig. Die OSM-Tags müssen nicht exakt den IHO-Konventionen folgen. Eine eindeutige Zuordnung genügt. Sprechende OSM-Namen (buoy_lateral) finde ich besser als Abkürzungen (BOYLAT). Die Tags sollten nicht unnötig lang sein. Alle Seezeichen sollten mit jedem OSM-Editor ohne Zusatzprogramme editierbar sein. Die Wiki-Beschreibung oder eine Kopie eines ähnlichen Objekts sollten als Vorlage genügen (eine evangelische Kirche kann ich auch nicht ohne Hilfe korrekt eingeben). Für Leuchttürme mit Sektorenfeuer, die nicht sehr zahlreich sind, kann anderes gelten. Bereits vorhandene OSM-Tags (Fähre, boat, motorboat) sollten weiterbenutzt werden. Das DE:Tonne/Datenmodell von Olaf unter http://wiki.openstreetmap.org/wiki/DE:Tonne/Datenmodell gefällt mir recht gut. Die Tagnamen finde ich unnötig lang. Statt seamark:buoy_cardinal:name würde auch seamark:name genügen. OSM kommt sonst mit einem universellen name=* aus. Der lange Name ist umständlich zu tippen, passt möglicherweise nicht in jedes Textfeld, benötigt zusätzliche Abfragen in Renderern und Auswerteprogrammen. Zudem kann es zu Inkonsistenzen führen, wenn man ein seamark=buoy_safewater mit seamark:buoy_cardinal:name kombiniert. Ich würde Redundanz vermeiden. Wenn
Re: [Talk-de] WMS am MAC - warum funktioniert das bei mir nicht?
Am 12.07.2009 13:55, UMAX974: Danke für den Tipp, WebKit läuft an meinem MAC. Aber QuickTime läuft in der Version nur bei Intel MAC mit OS 10.5 so modern bin ich noch nicht. meiner ist ein G4 mit OS 10.4.11 - gibt es da auch eine Lösung? Christian Ohne Selbstkompilat des Webkit klappt es leider nicht. Da ich auch Tiger nutze sitze ich ebenso wie du auf dem Mac ohne Yahoo WMS da :( Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
André Riedel schrieb: Am 12. Juli 2009 10:22 schrieb malenki o...@malenki.ch: André Riedel schrieb: highway = service hat für mich den Hintergedanken, dass PKW/LKW wirklich öfter dort lang fahren. Ich würde dies daher nur für Straßen innerhalb des Friedhofs anwenden. Dies gilt auch für highway=track, besonders für trackgrade=1 (Wirtschaftswege Co) Bei service stelle ich mir vor, dass da mehre PKW täglich langfahren und auch dürfen. Bei einem track stelle ich mir über das Jahr gesehen fast keinen Verkehr pro Tag vor, zumindest von der gesetzlich legalen Seite her. Da die Wege aber einfach breiter als was? auf allen Friedhöfen? sind und die Hauptnutzer Fussgänger sind, aber auch mal vom ^^ ansässigen Gärtner oder Friedhofsbetreiber benutzt werden können, sehe ich highway = track als die beste Variante. Ich nicht. Du sagst selbst: Hauptnutzer=Fußgänger Warum nicht highway=footway benutzen? diese sind normalerweise auch für Rollstuhlfahrer benutzbar. Die Oberflächenbeschaffenheit kann man mit surface=* angeben, die Breite mit width=* mit access kannst du angeben, wer/ws sich auf den Wegen bewegen darf. Ja das geht natürlich auch, beschreibt aber nicht, dass dort auch der Friedhofsgärtner mit seinem kleinen LKW langfahren kann. Mann kann dies nur mit motorcar = private umschreiben, aber in meiner Tag-Nutzung ist ein footway bzw. path nie oder nur in äußersten Ausnahmen mit PKW/LKW befahrbar. Desweiteren lässt sich dadurch eine gute Hierarchie zwischen Hauptwegen (track) und Wegen zu einzelnen Gräbern (path) abbilden. Ich kann mir nicht vorstellen, dass jemand, der auf dem Friedhof mit einem Kfz herumfahren muss, nicht weiß, ob dies möglich ist. Wenn ein Bestatter wirklich eine Fernfahrt mit Ziel=Friedhof erledigen muss, wird er auch wegen anderer Sachen mit den lokalen Verantwortlichen Kontakt aufnehmen müssen. Ich dachte bei highway = service auch eher an mehere km^2 große Friedhöfe, welche man vornehmlich in den USA findet. also bei uns sind die asphaltierten Wege (oft 6m und mehr breit) service, die breiteren Schotterwege track und die kleineren Wege path. Bei einem Serviceweg zu einem Bauernhof fahren doch auch nicht täglich Autos lang. Finde deine Definition also etwas schwammig. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WMS am MAC - warum funktioniert das bei mir nicht?
On Sun, 12 Jul 2009, Claudius wrote: Am 12.07.2009 13:55, UMAX974: Danke für den Tipp, WebKit läuft an meinem MAC. Aber QuickTime läuft in der Version nur bei Intel MAC mit OS 10.5 so modern bin ich noch nicht. meiner ist ein G4 mit OS 10.4.11 - gibt es da auch eine Lösung? Ohne Selbstkompilat des Webkit klappt es leider nicht. Da ich auch Tiger nutze sitze ich ebenso wie du auf dem Mac ohne Yahoo WMS da :( Was gibt es an der kompilierten Version im JOSM-MacOS-Downloadverzeichnis auszusetzen? Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
highway = service hat für mich den Hintergedanken, dass PKW/LKW wirklich öfter dort lang fahren. Ich würde dies daher nur für Straßen innerhalb des Friedhofs anwenden. Dies gilt auch für highway=track, besonders für trackgrade=1 (Wirtschaftswege Co) Bei service stelle ich mir vor, dass da mehre PKW täglich langfahren und auch dürfen. Bei einem track stelle ich mir über das Jahr gesehen fast keinen Verkehr pro Tag vor, zumindest von der gesetzlich legalen Seite her. also bei uns sind die asphaltierten Wege (oft 6m und mehr breit) service, die breiteren Schotterwege track und die kleineren Wege path. Bei einem Serviceweg zu einem Bauernhof fahren doch auch nicht täglich Autos lang. Finde deine Definition also etwas schwammig. Ja leider hat das Tagging-Schema da seine Lücken und Probleme, jedoch bin ich damit immer sehr gut ausgekommen. Achja der Weg zum Bauernhof wird wahrscheinlich nicht nur von Fussgängern benutzt und der Bauer/die Bäuerin werden wahrscheinlich auch öfters mit ihrem PKW darüber fahren. Für diese service-Wege gibt es übrigens noch das Attribut service = driveway also Zufahrt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [Hamburg] Treffen - September
Hallo an alle Hamburger, da ich diesen September mehrere Tage in Hamburg bin, würde ich gerne die Leute kennenlernen die die grandiose Abdeckung von Hamburg ermöglicht haben. Dummerweise ist der Stammtisch am 8.Sep und ich fahre erst am 8ten am Abend mit den Nachtzug aus Wien weg (am 14ten am Abend geht's wieder zurück). Hätte der eine oder andere Hamburger-Mapper Zeit/Lust (bei einem Glas Bier oä) mir etwas über die Hamburger-OSM-Community zu erzählen (damit ich beim nächsten wiener Treffen was zum Berichten habe ;) ). mfg, Florian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm - Tonne
Die Topokarte von Nop ist IMO eine der besten Karten die wir haben und die Übersichtlichkeit würde IMO deutlich schlechter werden, wenn man landuse=farm(land) irgendwie rendern würde. Das gelbe vom Ei ist es trotzdem nicht. Äcker sind da wiklich das kleinste Problem. Auch kann ich nicht nachvollziehen das einige ein Optisches Problem haben Straßen von Äckern zu unterscheiden. Die Wanderkarte wird bei mir aber nur bis z15 angezeigt. Die Folge ist das die Übersichtlichkeit in dicht gemappten Orten auch ohne die draußen liegenden Äcker leidet. Da sind ganze Teile unter POIs und Namen begraben. Ist das übersichtlicher nur weil man Wiesen und Äcker einfach nur grau darstellt http://topo.geofabrik.de/?zoom=15lat=51.29832lon=11.43475layers=BT, was teilweise auch noch mögliche Abkürzungen sugeriert die es garnicht gibt? Wenn ich da noch mehr Micromapping betreibe, sieht man in der bisher endenden Zommstufe bald garnichts mehr. Flächenverbote fehlen auch. Bis auf die Benutzer des Radfernweges und Schäfer sind die eingedeichten Flussbereiche als ganzes auf Thüringer Seite Tabu für Fahrzeuge und Reiter. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
André Riedel schrieb: highway = service hat für mich den Hintergedanken, dass PKW/LKW wirklich öfter dort lang fahren. Ich würde dies daher nur für Straßen innerhalb des Friedhofs anwenden. Dies gilt auch für highway=track, besonders für trackgrade=1 (Wirtschaftswege Co) Bei service stelle ich mir vor, dass da mehre PKW täglich langfahren und auch dürfen. Bei einem track stelle ich mir über das Jahr gesehen fast keinen Verkehr pro Tag vor, zumindest von der gesetzlich legalen Seite her. also bei uns sind die asphaltierten Wege (oft 6m und mehr breit) service, die breiteren Schotterwege track und die kleineren Wege path. Bei einem Serviceweg zu einem Bauernhof fahren doch auch nicht täglich Autos lang. Finde deine Definition also etwas schwammig. Ja leider hat das Tagging-Schema da seine Lücken und Probleme, jedoch bin ich damit immer sehr gut ausgekommen. Achja der Weg zum Bauernhof wird wahrscheinlich nicht nur von Fussgängern benutzt und der Bauer/die Bäuerin werden wahrscheinlich auch öfters mit ihrem PKW darüber fahren. Für diese service-Wege gibt es übrigens noch das Attribut service = driveway also Zufahrt. Ich weiß nicht, wie frequentiert eure Friedhöfe sind, aber bei uns wird von Angehörigen aber eben auch von externen Gärtnern die Friedhöfe mit PKWs befahren um zu den entsprechenden Anliegen zu kommen. Diese Wege haben eindeutig einen service-Charakter. Nur muss man eben ggf. einen Schlagbaum passieren. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hi Mario Genau das ist der Denkfehler. Lieber keine Tonne, als eine Falsche oder unvollständig bezeichnete. Du verstehst nicht dass ein Editor, es eigentlich leichter macht, weil man diesen komplizierten Beschreibungsteil durch den Editor ausgefüllt bekommt. Und wo bleibt bei deinem Beispiel das mögliche Nebelhorn , das Leuchtfeuer und die Tonnengeometrie. Die werden doch dann nicht erfasst. Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Mario Salvini Gesendet: Sonntag, 12. Juli 2009 14:46 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Hi Rolf. Wer behauptet denn, dass ich vom Schema der S-57 abweiche? Ihr solltet nur vor lauter kompliziertem Beschreibungskatalog nicht vergessen es auch einfach/logisch/nachvollziehbar zu halten. Klar kann man Details mit beliebig vielen Tags beschreiben, und das ist auch richtig so. Aber wenn nicht auch schon minimalste Infos eine Aussage haben, dann nützt das Schema nicht viel. Mit buoy=lateral_port kann man z.B. einer Tonne eine eindeutige Funktion geben ohne auch nur ein Detail zu kennen. Gruß Mario Rolf Meyerhof schrieb: Hi Mario Leider ist mir nicht bekannt ob du Seemann bist oder nicht. Wenn ja solltest du bedenken das wir Seemänner später einmal nach diesen Eingaben navigieren wollen. Dazu sollten die Angaben so sicher und vollständig wie möglich sein. Das wird durch vollständige Abfragen in einem Editor sicherlich leichter erreicht. Ich kann eigentlich nicht vertreten wenn vom Schema der S-57 abgegangen wird. Mir geht hier nicht um meiner ist besser oder länger sondern um Qualität. Da die Infos schwierig einzugeben sind findest du bei OSeaM auch noch keine Flächendecken Daten. Gruß Rolf Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man Boyen, Tonnen, Leuchtfeuer, und alles andere was für eine Seekarte und andere intereesant werden könnte/sollte erfasst werden soll. Ich bin an einer OSM basierten Seekarte sehr interessiert, aber ich kann bis auf die Erfassung einiger Seezeichen wenig beitragen. Jan, Markus und Olaf (in alphabetischer Reihenfolge, ohne Wertung) haben sehr viel mehr geleistet, so dass ihnen das Vorschlagsrecht zusteht. Ich werde trotzdem mal meine Ideen zum Tagging der Seezeichen äußern. Vielleicht ist der eine oder andere Gedanke ja nützlich. Eine gute Definition der Tags ist wichtig. Unvollständige Wiki-Texte führen zu Mißverständnissen und später zu Streit. Irgendwann wird dann ein OSM-User behaupten, jedes schwimmende, algenbewachsene Objekt sei eine Lateraltonne grün. Namen sind Schall und Rauch. Ob eine Lateraltonne als buoy_lateral oder lateral_buoy definiert wird, ist zweitrangig. Wichtig ist, dass es eine eindeutige Beschreibung des Seezeichens bzw. der Ge- und Verbote eines Gewässerteils gibt. Dass das OSM-Datenschema mit der Norm IHO-S-57 korrespondiert, finde ich richtig. Die OSM-Tags müssen nicht exakt den IHO-Konventionen folgen. Eine eindeutige Zuordnung genügt. Sprechende OSM-Namen (buoy_lateral) finde ich besser als Abkürzungen (BOYLAT). Die Tags sollten nicht unnötig lang sein. Alle Seezeichen sollten mit jedem OSM-Editor ohne Zusatzprogramme editierbar sein. Die Wiki-Beschreibung oder eine Kopie eines ähnlichen Objekts sollten als Vorlage genügen (eine evangelische Kirche kann ich auch nicht ohne Hilfe korrekt eingeben). Für Leuchttürme mit Sektorenfeuer, die nicht sehr zahlreich sind, kann
Re: [Talk-de] Hauptwege auf Friedhöfen
Ich weiß nicht, wie frequentiert eure Friedhöfe sind, aber bei uns wird von Angehörigen aber eben auch von externen Gärtnern die Friedhöfe mit PKWs befahren um zu den entsprechenden Anliegen zu kommen. Diese Wege haben eindeutig einen service-Charakter. Nur muss man eben ggf. einen Schlagbaum passieren. Also wenn die Straßen/Wege auch von PKWs der Angehörigen befahren werden, finde ich es mehr als angebracht diese auch als highway = service zu deklarieren. Jedoch werden diese PKW nicht auf deinen genannten Schotterwegen weiterfahren. Dort wird man nur noch den Gärtner antreffen, oder? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Der Denkfehler liegt aber dann bei euch. Denn OSM basiert darauf, dass der Detailgrad kontinuierlich gesteigert werden kann, aber auch schon die Basisinfo eine klare Aussage hat. Proprietäre Elitesysteme sind eigentlich nicht unser aller Ziel. Was ist bitte daran besser keine Tonne an einer Stelle zu haben als eine Tonne, die vielleicht noch nicht im Deatil beschrieben ist, aber trotzdem eine klare Aussage hat? Ich hab zum Navigieren doch lieber z.B. eine buoy=cardinal_north in der Karte als keine, nur weil noch kein Leuchtfeuer oder Topmark eingezeichnet ist... Wie gesagt. Details wie Form, Topmark und weitere aktive Signale sind auch wichtig zu erfassen. Ändern aber ja nix an der Richtigkeit der Grundfunktion. Aber um deine Frage zu beantworten. Hier ein Paar Beispiele:. foghorn=yes oder foghorn=horn oder foghorn=bell topmark=yes oder z.B. topmark=cylinder mit topmark:color=red light=yes oder light=red + light:category=quick (für z.B. Funkelfeuer) Das versteht jeder beschreibt den Sachverhalt und kann auch jeder wenns hart auf hart kommt manuel erfassen (ohne spezielle Editoren) Gruß Mario Rolf Meyerhof schrieb: Hi Mario Genau das ist der Denkfehler. Lieber keine Tonne, als eine Falsche oder unvollständig bezeichnete. Du verstehst nicht dass ein Editor, es eigentlich leichter macht, weil man diesen komplizierten Beschreibungsteil durch den Editor ausgefüllt bekommt. Und wo bleibt bei deinem Beispiel das mögliche Nebelhorn , das Leuchtfeuer und die Tonnengeometrie. Die werden doch dann nicht erfasst. Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Mario Salvini Gesendet: Sonntag, 12. Juli 2009 14:46 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Hi Rolf. Wer behauptet denn, dass ich vom Schema der S-57 abweiche? Ihr solltet nur vor lauter kompliziertem Beschreibungskatalog nicht vergessen es auch einfach/logisch/nachvollziehbar zu halten. Klar kann man Details mit beliebig vielen Tags beschreiben, und das ist auch richtig so. Aber wenn nicht auch schon minimalste Infos eine Aussage haben, dann nützt das Schema nicht viel. Mit buoy=lateral_port kann man z.B. einer Tonne eine eindeutige Funktion geben ohne auch nur ein Detail zu kennen. Gruß Mario Rolf Meyerhof schrieb: Hi Mario Leider ist mir nicht bekannt ob du Seemann bist oder nicht. Wenn ja solltest du bedenken das wir Seemänner später einmal nach diesen Eingaben navigieren wollen. Dazu sollten die Angaben so sicher und vollständig wie möglich sein. Das wird durch vollständige Abfragen in einem Editor sicherlich leichter erreicht. Ich kann eigentlich nicht vertreten wenn vom Schema der S-57 abgegangen wird. Mir geht hier nicht um meiner ist besser oder länger sondern um Qualität. Da die Infos schwierig einzugeben sind findest du bei OSeaM auch noch keine Flächendecken Daten. Gruß Rolf Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man Boyen, Tonnen, Leuchtfeuer, und alles andere was für eine Seekarte und andere intereesant werden könnte/sollte erfasst werden soll. Ich bin an einer OSM basierten Seekarte sehr interessiert, aber ich kann bis auf die Erfassung einiger Seezeichen wenig beitragen. Jan, Markus und Olaf (in alphabetischer Reihenfolge, ohne Wertung) haben sehr viel mehr geleistet, so dass ihnen das Vorschlagsrecht zusteht. Ich werde trotzdem mal meine Ideen zum Tagging
Re: [Talk-de] Hauptwege auf Friedhöfen
André Riedel schrieb: Ich weiß nicht, wie frequentiert eure Friedhöfe sind, aber bei uns wird von Angehörigen aber eben auch von externen Gärtnern die Friedhöfe mit PKWs befahren um zu den entsprechenden Anliegen zu kommen. Diese Wege haben eindeutig einen service-Charakter. Nur muss man eben ggf. einen Schlagbaum passieren. Also wenn die Straßen/Wege auch von PKWs der Angehörigen befahren werden, finde ich es mehr als angebracht diese auch als highway = service zu deklarieren. Jedoch werden diese PKW nicht auf deinen genannten Schotterwegen weiterfahren. Dort wird man nur noch den Gärtner antreffen, oder? also die Leute fahren natürlich auch auf den breiteren Schotterwegen... oft direkt bis vors Grab. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
moin, und dann gibt es ja auch Buslinien aus dem Friedhof SCNR Jörk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hallo Rolf, Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Natürlich ist unsers einfacher, weil wir nur einen Klick brauchen, und unsere Zeichen direkt im GPS schon genau getaggd werden. Mit dem GPS nach Hausse kommen, *.gpx hochladen, fertig :-) Spaß beiseite. Stephan hat doch hier eine ganz andere Frage gestellt. Wenn ich ihn recht verstehe, geht es um eine Vereinfachung des Tagging-Schemas, und hier hilft der Glaubenskrieg FreieTonne ./. Openseamap nicht weiter. Achte bitte darauf, daß sogar die Bezeichnung des Threads versucht, Neutralität zu gewährleisten. Im eigentlichen Thema, dem Tagging-Schema hat besagter Glaubenskrieg übrigens ebenfalls nichts verloren, die verwendeten Tags von Olaf und uns sind identisch, Olaf war so freundlich, seine Vorstellungen bei uns einzutragen. Also halte Dich bitte ans Thema, oder eröffne einen neuen Thread. Ich selbst halte Stephans Beitrag übrigens für gut, auch wenn wir nicht allen seinen Anforderungen gerecht werden. Ich würde es bedauern, wenn der Flamewar auch hier stattfindet. Wir als FreieTonne sind nämlich gar nicht an einem bestimmten Schema interessiert. Nur dasjenige, was auch wir derzeit benutzen, scheint uns auf lange Sicht nicht zu tragen, und sowohl technisch, als auch aus der Sicht der Les- / Lern- und Anwendbarkeit durch den Mapper zu kompliziert und fehlerträchtig. Insofern unterstützen wir mal ins unreine: - bereits anderweitig genutzte Tags sollten nicht verändert oder aufgeblasen werden (leisure=marina) - Tags sollten kurz, genau und einprägsam sein - Seezeichen sollten in Etagen beschrieben werden (so von unten nach oben, was nicht da ist, fällt weg) Ich bin dafür, in die Richtung mal wirklich zu denken. Beste Grüße vom Seddinsee JJ www.freietonne.de - Was ägert eigentlich OpenSeamap an unserer Existenz, daß sie uns so fertigmachen (***heul***)? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hi Mario Es steht dir ja frei alles von Hand zu erfassen. Ich wünsche mir lieber ein Werkzeug das grobe Fehler verhindert. Das spricht für mich für einen Editor. Bye Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Mario Salvini Gesendet: Sonntag, 12. Juli 2009 16:31 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Der Denkfehler liegt aber dann bei euch. Denn OSM basiert darauf, dass der Detailgrad kontinuierlich gesteigert werden kann, aber auch schon die Basisinfo eine klare Aussage hat. Proprietäre Elitesysteme sind eigentlich nicht unser aller Ziel. Was ist bitte daran besser keine Tonne an einer Stelle zu haben als eine Tonne, die vielleicht noch nicht im Deatil beschrieben ist, aber trotzdem eine klare Aussage hat? Ich hab zum Navigieren doch lieber z.B. eine buoy=cardinal_north in der Karte als keine, nur weil noch kein Leuchtfeuer oder Topmark eingezeichnet ist... Wie gesagt. Details wie Form, Topmark und weitere aktive Signale sind auch wichtig zu erfassen. Ändern aber ja nix an der Richtigkeit der Grundfunktion. Aber um deine Frage zu beantworten. Hier ein Paar Beispiele:. foghorn=yes oder foghorn=horn oder foghorn=bell topmark=yes oder z.B. topmark=cylinder mit topmark:color=red light=yes oder light=red + light:category=quick (für z.B. Funkelfeuer) Das versteht jeder beschreibt den Sachverhalt und kann auch jeder wenns hart auf hart kommt manuel erfassen (ohne spezielle Editoren) Gruß Mario Rolf Meyerhof schrieb: Hi Mario Genau das ist der Denkfehler. Lieber keine Tonne, als eine Falsche oder unvollständig bezeichnete. Du verstehst nicht dass ein Editor, es eigentlich leichter macht, weil man diesen komplizierten Beschreibungsteil durch den Editor ausgefüllt bekommt. Und wo bleibt bei deinem Beispiel das mögliche Nebelhorn , das Leuchtfeuer und die Tonnengeometrie. Die werden doch dann nicht erfasst. Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Mario Salvini Gesendet: Sonntag, 12. Juli 2009 14:46 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Hi Rolf. Wer behauptet denn, dass ich vom Schema der S-57 abweiche? Ihr solltet nur vor lauter kompliziertem Beschreibungskatalog nicht vergessen es auch einfach/logisch/nachvollziehbar zu halten. Klar kann man Details mit beliebig vielen Tags beschreiben, und das ist auch richtig so. Aber wenn nicht auch schon minimalste Infos eine Aussage haben, dann nützt das Schema nicht viel. Mit buoy=lateral_port kann man z.B. einer Tonne eine eindeutige Funktion geben ohne auch nur ein Detail zu kennen. Gruß Mario Rolf Meyerhof schrieb: Hi Mario Leider ist mir nicht bekannt ob du Seemann bist oder nicht. Wenn ja solltest du bedenken das wir Seemänner später einmal nach diesen Eingaben navigieren wollen. Dazu sollten die Angaben so sicher und vollständig wie möglich sein. Das wird durch vollständige Abfragen in einem Editor sicherlich leichter erreicht. Ich kann eigentlich nicht vertreten wenn vom Schema der S-57 abgegangen wird. Mir geht hier nicht um meiner ist besser oder länger sondern um Qualität. Da die Infos schwierig einzugeben sind findest du bei OSeaM auch noch keine Flächendecken Daten. Gruß Rolf Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man
Re: [Talk-de] Hauptwege auf Friedhöfen
Hallo, Jörk jo...@jhamburger.de writes: und dann gibt es ja auch Buslinien aus dem Friedhof Ja gibt es. Und? Das kann man doch ganz einfach eintragen. Viele Grüße Sebastian Waschik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSeaM vs. freie Tonne
moin zusammen, kann es sein, daß hier teilweise aneinandervorbeigeredet wird? Ich verstehe es so, daß die FT im Binnenbereich angefangen hat, wo die BinSchStrO gilt, die etwas anders ist, als SeeSchStrO. Jetzt trifft man sich an den Küsten und da gelten dann etwas andere Regeln. das macht die FT doch nicht Schlechter. Übrigens ist NAVIGATION nach nicht offiziellen Karten immer noch lebensgefährlich! (da schrieb neulich jemand, daß er das macht) VG Jörk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
Jörk schrieb: moin, und dann gibt es ja auch Buslinien aus dem Friedhof SCNR Ja, da gibt es auch, siehe Hamburg, Friedhof Ohlsdorf. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hallo Jan Wie du weisst beteilige ich mich erst seit kurzem an OSeaM. Ich habe auch schon verstanden was Mario möchte. Meine Entscheidung ist für OSeaM gefallen weil ich das für bessere System halte.Auch wenn Du schneller warst. Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Jan Jesse Gesendet: Sonntag, 12. Juli 2009 17:00 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de]Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Hallo Rolf, Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Natürlich ist unsers einfacher, weil wir nur einen Klick brauchen, und unsere Zeichen direkt im GPS schon genau getaggd werden. Mit dem GPS nach Hausse kommen, *.gpx hochladen, fertig :-) Spaß beiseite. Stephan hat doch hier eine ganz andere Frage gestellt. Wenn ich ihn recht verstehe, geht es um eine Vereinfachung des Tagging-Schemas, und hier hilft der Glaubenskrieg FreieTonne ./. Openseamap nicht weiter. Achte bitte darauf, daß sogar die Bezeichnung des Threads versucht, Neutralität zu gewährleisten. Im eigentlichen Thema, dem Tagging-Schema hat besagter Glaubenskrieg übrigens ebenfalls nichts verloren, die verwendeten Tags von Olaf und uns sind identisch, Olaf war so freundlich, seine Vorstellungen bei uns einzutragen. Also halte Dich bitte ans Thema, oder eröffne einen neuen Thread. Ich selbst halte Stephans Beitrag übrigens für gut, auch wenn wir nicht allen seinen Anforderungen gerecht werden. Ich würde es bedauern, wenn der Flamewar auch hier stattfindet. Wir als FreieTonne sind nämlich gar nicht an einem bestimmten Schema interessiert. Nur dasjenige, was auch wir derzeit benutzen, scheint uns auf lange Sicht nicht zu tragen, und sowohl technisch, als auch aus der Sicht der Les- / Lern- und Anwendbarkeit durch den Mapper zu kompliziert und fehlerträchtig. Insofern unterstützen wir mal ins unreine: - bereits anderweitig genutzte Tags sollten nicht verändert oder aufgeblasen werden (leisure=marina) - Tags sollten kurz, genau und einprägsam sein - Seezeichen sollten in Etagen beschrieben werden (so von unten nach oben, was nicht da ist, fällt weg) Ich bin dafür, in die Richtung mal wirklich zu denken. Beste Grüße vom Seddinsee JJ www.freietonne.de - Was ägert eigentlich OpenSeamap an unserer Existenz, daß sie uns so fertigmachen (***heul***)? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Von AVG überprüft - www.avg.de Version: 8.5.387 / Virendatenbank: 270.13.9/2229 - Ausgabedatum: 07/11/09 17:56:00 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
René Falk schrieb: Ja, da gibt es auch, siehe Hamburg, Friedhof Ohlsdorf. nicht nur da, auch in Bergedorf; ich wolte darauf hinaus, über welche Straßentypen Busse fahren. service doch eher nicht? Jörk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Wie du schon geschrieben hast. ein Editor ist ein nützliches Hilfsmittel. Ich persönlich mache alles in JOSM. Aber die Tags gebe ich auch dort größtenteils manuell ein. Vorlagen nutze ich meist nur bei Sachen die ich seltener brauche. Leider konntest du mir noch nicht auf die Frage antworten, warum man z.B. mit buoy=cardinal_north oder beacon=lateral_starboard ohne weitere Details schlechter Navigieren kann, als ohne Zeichen. Gruß Mario Rolf Meyerhof schrieb: Hi Mario Es steht dir ja frei alles von Hand zu erfassen. Ich wünsche mir lieber ein Werkzeug das grobe Fehler verhindert. Das spricht für mich für einen Editor. Bye Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Mario Salvini Gesendet: Sonntag, 12. Juli 2009 16:31 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Der Denkfehler liegt aber dann bei euch. Denn OSM basiert darauf, dass der Detailgrad kontinuierlich gesteigert werden kann, aber auch schon die Basisinfo eine klare Aussage hat. Proprietäre Elitesysteme sind eigentlich nicht unser aller Ziel. Was ist bitte daran besser keine Tonne an einer Stelle zu haben als eine Tonne, die vielleicht noch nicht im Deatil beschrieben ist, aber trotzdem eine klare Aussage hat? Ich hab zum Navigieren doch lieber z.B. eine buoy=cardinal_north in der Karte als keine, nur weil noch kein Leuchtfeuer oder Topmark eingezeichnet ist... Wie gesagt. Details wie Form, Topmark und weitere aktive Signale sind auch wichtig zu erfassen. Ändern aber ja nix an der Richtigkeit der Grundfunktion. Aber um deine Frage zu beantworten. Hier ein Paar Beispiele:. foghorn=yes oder foghorn=horn oder foghorn=bell topmark=yes oder z.B. topmark=cylinder mit topmark:color=red light=yes oder light=red + light:category=quick (für z.B. Funkelfeuer) Das versteht jeder beschreibt den Sachverhalt und kann auch jeder wenns hart auf hart kommt manuel erfassen (ohne spezielle Editoren) Gruß Mario Rolf Meyerhof schrieb: Hi Mario Genau das ist der Denkfehler. Lieber keine Tonne, als eine Falsche oder unvollständig bezeichnete. Du verstehst nicht dass ein Editor, es eigentlich leichter macht, weil man diesen komplizierten Beschreibungsteil durch den Editor ausgefüllt bekommt. Und wo bleibt bei deinem Beispiel das mögliche Nebelhorn , das Leuchtfeuer und die Tonnengeometrie. Die werden doch dann nicht erfasst. Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Mario Salvini Gesendet: Sonntag, 12. Juli 2009 14:46 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Hi Rolf. Wer behauptet denn, dass ich vom Schema der S-57 abweiche? Ihr solltet nur vor lauter kompliziertem Beschreibungskatalog nicht vergessen es auch einfach/logisch/nachvollziehbar zu halten. Klar kann man Details mit beliebig vielen Tags beschreiben, und das ist auch richtig so. Aber wenn nicht auch schon minimalste Infos eine Aussage haben, dann nützt das Schema nicht viel. Mit buoy=lateral_port kann man z.B. einer Tonne eine eindeutige Funktion geben ohne auch nur ein Detail zu kennen. Gruß Mario Rolf Meyerhof schrieb: Hi Mario Leider ist mir nicht bekannt ob du Seemann bist oder nicht. Wenn ja solltest du bedenken das wir Seemänner später einmal nach diesen Eingaben navigieren wollen. Dazu sollten die Angaben so sicher und vollständig wie möglich sein. Das wird durch vollständige Abfragen in einem Editor sicherlich leichter erreicht. Ich kann eigentlich nicht vertreten wenn vom Schema der S-57 abgegangen wird. Mir geht hier nicht um meiner ist besser oder länger sondern um Qualität. Da die Infos schwierig einzugeben sind findest du bei OSeaM auch noch keine Flächendecken Daten. Gruß Rolf Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hallo Rolf, Hi Mario Leider ist mir nicht bekannt ob du Seemann bist oder nicht. Wenn ja solltest du bedenken das wir Seemänner später einmal nach diesen Eingaben navigieren wollen. Dazu sollten die Angaben so sicher und vollständig wie möglich sein. Das wird durch vollständige Abfragen in einem Editor sicherlich leichter erreicht. Was für eine überhebliche Frage. Willst Du andeuten, die bisher durch die Mapper eingetragenen Daten stimmen nicht? Oder meinst Du, sie würden durch einen Fremdeditor verfälscht? Die vollständige Abfrage zu einer grünen Tonne ist übrigens grün und Tonne. Und wenn sie verdammt nicht quietschen oder stinken will, ändert auch eine vollständige Erfassungsmaske nichts daran. Wir wollen hier diskutieren, wie wir diese Dinge syntaktisch uns strukturell am einfachsten und handhabbarsten in der Datenbank abbilden könne. Welchen Editor Du persönlich bevorzugst, ist dabei egal. Ich kann eigentlich nicht vertreten wenn vom Schema der S-57 abgegangen wird. Das mußt Du auch nicht. Es liegt nicht in Deiner Verantwortung. Und im übrigen sagst Du uns bitte, wer von der S-57 weggehen möchte? Hat überhaupt bisher einer gewagt, die heilige S-57 in Frage zu stellen? Ich denke nein. Nur wenn ich mir das erste Muster Hafen Rostock anschaue, sage ich, das ist nicht machbar, jedenfalls nicht ohne Editor. Und dies widerspricht einigen Dingen, die OSM grundlegend eigen sind. Der zweite Versuch Kiel ist da schon etwas realistischer, momentan eben auch das von uns verwendete Schema. Aber so richtig handhabbar ist es eben auch noch nicht. Das schmälert in keiner Weise, daß bis hierher viel Arbeit investiert worden ist. Im Gegenteil. Aber um richtig gut zu werden, sollten wir eben noch etwas feilen. Mir geht hier nicht um meiner ist besser oder länger sondern um Qualität. Darüber freue ich mich. Da werden wir ja bald auch zu den Inhalten diskutieren können. Da die Infos schwierig einzugeben sind findest du bei OSeaM auch noch keine Flächendecken Daten. Gruß Rolf Das wundert mich nicht. Deshalb versuchen andere Projekte eben einen eher empirischen Weg zu gehen, und ein System zu entwickeln, daß vorgefundene Realität leicht abbildbar macht, und neue Symbole sofort konsistent auf das Gesamtsystem (Karte, Editoren, Offline-Editoren, Josm, Garmin-Geräte) überträgt. Das Symbol, das heute zum ersten Mal in unserer Karte verwendet wurde, wirst Du morgen mit jedem Update für jedes Endgerät bekommen können. Z.B. bei den JOSM-Menüs kannst Du das gut nachvollziehen (Achte aber bitte darauf, daß der JOSM nicht bei jedem Neustart Updated :-), das liegt nicht in unserer Macht). In Ostdeutschland haben wir als OPENSTREETMAP übrigens schon recht gute Daten, z.B. die Ostseeküste, Mecklenburg, die Havel und den Berliner Raum betreffend :-) Und, um abschließend eine Frage zu beantworten, die Du heute gestellt hattest: Ja, ich möchte nach den Daten fahren, die wir schon haben. Ich mache das auch schon seit vorigem Jahr. Weil ich nach diesen Daten elektronisch navigiere, geht das. Bisherige Möglichkeiten, eine Papierkarte zu produzieren sind noch lange nicht da. Noch niemand hat sich z.B. daran versucht, eine Karte auf A1 Format mit eingeblendeten Längen und Breitengraden zu produzieren. Bis daahin ist es noch ein spannender Weg. Beste Grüße von Seemann zu Seemann JJ (MY-Naja, Seddinsee, Berlin, Rolf: in welcher Bucht liegst Du gerade?) www.freietonne.de - Warum sollen wir alles so machen, wie andere das wünschen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
Jörk schrieb: René Falk schrieb: Ja, da gibt es auch, siehe Hamburg, Friedhof Ohlsdorf. nicht nur da, auch in Bergedorf; ich wolte darauf hinaus, über welche Straßentypen Busse fahren. service doch eher nicht? Jörk wieso den nicht? über track oder path ja wohl noch weniger ;-) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symbole rfassung auf Wasserwegen
Hallo Stephan, vielen Dank für deine Kritik und Anregungen, Sprechende OSM-Namen (buoy_lateral) finde ich besser als Abkürzungen (BOYLAT). Die Tags sollten nicht unnötig lang sein. Sehe ich genauso und gebe zu, dass wir dort an einigen Stellen bestimmt noch Verbessrungsbedarf haben. Alle Seezeichen sollten mit jedem OSM-Editor ohne Zusatzprogramme editierbar sein. +1 Die Wiki-Beschreibung oder eine Kopie eines ähnlichen Objekts sollten als Vorlage genügen +1 Bereits vorhandene OSM-Tags (Fähre, boat, motorboat) sollten weiterbenutzt werden. +1 Die Tagnamen finde ich unnötig lang. Statt seamark:buoy_cardinal:name würde auch seamark:name genügen. OSM kommt sonst mit einem universellen name=* aus. Der lange Name ist umständlich zu tippen, passt möglicherweise nicht in jedes Textfeld, benötigt zusätzliche Abfragen in Renderern und Auswerteprogrammen. Zudem kann es zu Inkonsistenzen führen, wenn man ein seamark=buoy_safewater mit seamark:buoy_cardinal:name kombiniert. Da hast du natürlich Recht. Ein seamark: sollte aber trotzdem davor stehen bleiben, da ansonsten Mapnik und Osmarender die Namen ebenfalls darstellen würden. Ich würde Redundanz vermeiden. Wenn seamark=buoy_isolated_danger nur mir seamark:topmark:shape=2 spheres zu kombinieren ist, würde ein seamark:topmark=yes genügen. Da habe ich mir lange Gedanken drüber gemacht. Das Problem ist, dass einige Seezeichen eine genauere Definition des Topzeichens benötigen. Zumindest benötige ich bei den Lateral und Sonderzeichen eine Angabe der Farbe des Topzeichens. Daher stellt sich die Frage, ist es jetzt einfacher ein konsistentes Schema zu verwenden, oder bei dem einem Zeichen ein topmark=yes und bei dem anderen ein topmark:colour=* zu erwarten. Es bestünde natürlich die Möglichkeit auf ein topmark=yes zu reagieren und bei fehlender Farbangabe erst einmal die am häufigsten verwendete Farbe anzuzeigen. Zur Zeit ist für mich ein topmark:colour=* entscheidend ob ich ein Topzeichen darstelle oder nicht. Mir fehlen noch Tags für Markierungsbojen der Schwimmerbereiche (weißer Ball mit gelbem Kreuz), evtl. Nichtschwimmerbereichsbojen, Ankerbojen und dauerhafte Regattabojen. Ein Tag für Lichtsignalanlagen (typisch bei Schleusen, Klappbrücken, Kanalausweichstellen) wäre nützlich. Sehe ich genauso. Ich möchte aber noch einen Augenblick warten, bevor ich weitere Tags einführe. Ebenso wird noch ein Schlüssel für orange Bälle (Abgrenzung der Strandbereiche in der Ostsee) sowie Festmacherdalben benötigt. Regatta Tonnen und Gebiete sind in Arbeit. Sehr wichtig ist ein Schema für Sperrgebiete, Warngebiete, Verbotszonen (keine Schwimmer, Kitesurfen verboten, etc.) und Beschränkungszonen (Geschwindigkeit, Tiefgang, etc) sowohl für Wasserflächen als auch für Kanal- und Flussabschnitte siehe oben. Für Seezeichen wäre eine Angabe der Positionsgenauigkeit (von der vorbeifahrenden Fähre geschätzt bis aus amtlicher Quelle übernommen) nützlich. Gute Idee. Des Weiteren plane ich einen Schlüssel, der die Bedeutung der einzelnen Seezeichen definiert. Angedacht ist so etwas wie seamark:category= major|minor|habour. Damit wäre es möglich die Hauptfahrwasser ab Zoomlevel 12, die Nebenfahrwasser ab Zommlevel 14 und die hafenspezifischen Seezeichen ab Zoomlevel 15 darzustellen. Ohne diesen Schlüssel werden Seezeichen ab Zoomlevel 14 und Leuchtfeuer ab 12 dargestellt. Grüße Olaf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hallo Rolf, Roholf! Hi Mario Genau das ist der Denkfehler. Lieber keine Tonne, als eine Falsche oder unvollständig bezeichnete. Du verstehst nicht dass ein Editor, es eigentlich leichter macht, weil man diesen komplizierten Beschreibungsteil durch den Editor ausgefüllt bekommt. Und wo bleibt bei deinem Beispiel das mögliche Nebelhorn , das Leuchtfeuer und die Tonnengeometrie. Die werden doch dann nicht erfasst. Gruß Rolf Ich möchte sehen, wie Du bei Windstärke 6-7 in Böen ... Bis auf 3 Meter an die Einzelgefahrentonne ranfährst, Bezeichnung, Farben usw in eine Erfassungsmaske (Online) einträgst und dann stolz davon dampfst. Du wirst, wie in anderen Bereichen von OSM, dringend auf Notizen angewiesen sein. Auf fremde Unterlagen, ein Teil der Infos ist warscheinlich ohne Absschreiben aus fremden Karten, was wir ja nicht wollen, gar nicht zu leisten. Die Daten müssen also Nachbearbeitet werden. Außerdem haben wir die zeitliche Dimension. Mir selbst ist es letztes Jahr auf dem Rückmarsch durch das Achterwasser passiert. Ich hatte lustig alle Tonnen unterwegs erfaßt, abends in eine stillen Bucht geankert. Am nächsten morgen mußte ich ansehen, wie das Arbeitsboot des Schiffahrtsamtes daher kam, exakt zur letzten Tonne, die ich am Vortag geklickt hatte fuhr, den Kran raus, anheben, 5 meter weiter, platsch die Tonne liegt. Und dann fuhr der so die ganze Reihe, die ich am Vortag erfaßt hatte, rückwärts ab. Natürlich habe ich alle meine Daten sofort gelöscht ;-) Nein. Die Anforderungen, die Du hier definierst, sind nicht einzuhalten. Und sie sind auch in den Sportbootkarten nicht abbildbar. Natürlich wollen wir so genau wie möglich sein. Aber auch bei uns (OpenStreetmap) kann eine Tonne mit fixme gekennzeichnet, den nächsten Sportfreund animieren, hier genauere Infos zu recherchieren. Übrigens haben wir genau dafür eine Quarantänestation, die auch gern und viel genutzt wird. Momentan laden da fast 1000 (Korrektur, gerade sind es 1060 der letzten 20 Tage)Seezeichen ein, kontrolliert, verbessert, evtl aus Qualitätsmängeln gelöscht zu werden. Vielleicht schaust Du mal rein? http://www.freietonne.de/index.php?site=24infotyp=1redirect=24 Und nun, bitte, laß uns zum Thema des Threads kommen, oder eröffne einen neuen. Danke! Beste Grüße vom Seddinsee JJ www.freietonne.de - Mir fällt kein Spruch mehr ein :-( ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSeaM vs. freie Tonne
Hi Jörk, moin zusammen, kann es sein, daß hier teilweise aneinandervorbeigeredet wird? Ich verstehe es so, daß die FT im Binnenbereich angefangen hat, wo die BinSchStrO gilt, die etwas anders ist, als SeeSchStrO. Jetzt trifft man sich an den Küsten und da gelten dann etwas andere Regeln. das macht die FT doch nicht Schlechter. Die FreieTonne begann im Wattenmeer ;-) (http://www.freietonne.de/index.php?site=2infotyp=1redirect=24) Übrigens ist NAVIGATION nach nicht offiziellen Karten immer noch lebensgefährlich! (da schrieb neulich jemand, daß er das macht) Wenn man keine ordentliche Seekarte dabei hat, ja. Da ist nichts hinzuzufügen. Benutze ich aber unsere Daten als Ergänzung, um z.B. auf dem Garmin zu schaun, wie weit und in welcher Richtung die nächste Tonne liegen müßte, ist es ein großes PLUS an Sicherheit. Und genau das tue ich. Beste Grüße vom Seddinsee JJ www.freitonne.de - Warum eigentlich OSeaM vs. freie Tonne? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hallo Rolf Hallo Jan Wie du weisst beteilige ich mich erst seit kurzem an OSeaM. Ich habe auch schon verstanden was Mario möchte. Meine Entscheidung ist für OSeaM gefallen weil ich das für bessere System halte.Auch wenn Du schneller warst. Gruß Rolf Dagegen habe ich absolut nichts. Können wir nun endlich in diesem Thread das diskutieren, was das Subject aussagt? Das wäre mir wichtig. Danke :-) JJ www.freietonne.de - Wir waren schneller. Na und? Das sind immer solche Feststellungen ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
