Re: [talk-ph] tagging freindship route in Las pinas
I have no idea that's why I haven't tagged these routes yet even if I use them everyday. I guess I can add to his relation since modifying the tags is easy. On Mon, Jun 21, 2010 at 1:31 PM, maning sambale emmanuel.samb...@gmail.comwrote: Hi, A user added some for of friendship route is OSM. http://www.openstreetmap.org/browse/relation/969316 which he/she defined as: route is used by las pinas residents and others who are provided the friendship route stickers, it is a collaboration of the different villages to provide an alternative to alabang-zapote road. It is an official route sanctioned by the city hall thread from the my wikispaces page: http://esambale.wikispaces.com/message/view/home/25312903 What is the proper relation type for such case? -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Fwd: problem with naming Baguio streets created from quickbird
maning sambale wrote, On Monday, 21 June, 2010 01:28 PM: Eugene showed a technique to mark a tile dirty to trigger re-rendering last manda-ortigas party. Can't remember how. Anyone on the list can probably help. First you find out the URL of the tile: In Firefox I just right-click on the tile I'm interested in and select View Image. That gives you a URL like this http://a.tile.openstreetmap.org/14/13699/7522.png To mark it as dirty, just add /dirty on the end of the URL in the address bar, and hit return: http://a.tile.openstreetmap.org/14/13699/7522.png/dirty You get the message Tile submitted for rendering, and it will go away and re-render the tile. It might take a few minutes, but usually this works pretty quickly Jim -- datalude: information security e: j...@datalude.com Philippines: +63 2 403 1311 / mob: +63 920 912 5830 Hong Kong: +852 6840 6693 w: http://www.datalude.com/ ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] OpenStreetMap Philippines Inc. a Non-Stock Corporation May 28, 2010
Can we confirm this June 26, 2010 Eastwood City, Libis 5 pm onwards Skillshare and OSM-PH Org meeting any cafe with free wifi http://www.ka-fi.com/location/libis_eastwood/ On Mon, Jun 21, 2010 at 2:12 PM, Andre Marcelo-Tanner an...@enthropia.com wrote: Is this pushing through? :) ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Download tracks from Garmin
Bart Bartolome wrote, On Monday, 21 June, 2010 04:45 PM: Can you guys help me with how to get the tracks out of the garmin mobile xt? Googling didn't help me. ;) My immediate thought would be GPSbabel ... http://www.gpsbabel.org/ Have you tried this already? It seems to handle most Garmin formats, and I imagine the serial/USB protocol would be the same for all models So you might do something like this for Windows gpsbabel -t -i garmin -f com1 -o gpx -F output.gpx Or in linux: gpsbabel -t -i garmin -f /dev/ttyS0 -o gpx -F output.gpx You might have to try a few different formats (ie, change the bit after -i) and you'd have to know the port the unit is connected to ( com1 or /dev/ttyS0 ) Jim -- datalude: information security e: j...@datalude.com Philippines: +63 2 403 1311 / mob: +63 920 912 5830 Hong Kong: +852 6840 6693 w: http://www.datalude.com/ ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Download tracks from Garmin
http://tinyurl.com/2v82xav http://www.4x4community.co.za/forum/showthread.php?t=12727 http://roadguide.ph/forums/showthread.php?t=224 On Mon, Jun 21, 2010 at 5:03 PM, Jim Morgan j...@datalude.com wrote: Bart Bartolome wrote, On Monday, 21 June, 2010 04:45 PM: Can you guys help me with how to get the tracks out of the garmin mobile xt? Googling didn't help me. ;) My immediate thought would be GPSbabel ... http://www.gpsbabel.org/ Have you tried this already? It seems to handle most Garmin formats, and I imagine the serial/USB protocol would be the same for all models So you might do something like this for Windows gpsbabel -t -i garmin -f com1 -o gpx -F output.gpx Or in linux: gpsbabel -t -i garmin -f /dev/ttyS0 -o gpx -F output.gpx You might have to try a few different formats (ie, change the bit after -i) and you'd have to know the port the unit is connected to ( com1 or /dev/ttyS0 ) Jim -- datalude: information security e: j...@datalude.com Philippines: +63 2 403 1311 / mob: +63 920 912 5830 Hong Kong: +852 6840 6693 w: http://www.datalude.com/ ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] OpenStreetMap Philippines Inc. a Non-Stock Corporation May 28, 2010
I think Caffecino also has free Wi-Fi. I just haven't updated the Ka-Fi directory yet. I also think that they have power outlets since they have a small function room. But they're expensive. On Mon, Jun 21, 2010 at 4:45 PM, Bart Bartolome linuxbast...@paglalakbay.com wrote: Only Krispy Kreme and McDonald's has free wi-fi? Bummer. Last time I went to eastwood (a week ago) mcdonald's city walk is under renovations. Can you guys help me with how to get the tracks out of the garmin mobile xt? Googling didn't help me. ;) On Monday, 21 June, 2010 04:40 PM, maning sambale wrote: Can we confirm this June 26, 2010 Eastwood City, Libis 5 pm onwards Skillshare and OSM-PH Org meeting any cafe with free wifi http://www.ka-fi.com/location/libis_eastwood/ On Mon, Jun 21, 2010 at 2:12 PM, Andre Marcelo-Tanner an...@enthropia.com wrote: Is this pushing through? :) ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Download tracks from Garmin
so it's like downloading tracks/waypoints from my nuvi 1300, there's a GPX folder there and a file named current.gpx and and archived one what I do is transfer tracks/waypoints to my laptop using Mapsource then copy/paste/delete only the data I need, save into another GPX file I will open the GPX file using wordpad to cover my tracks in some instances then upload to OSM site for updating/editing On 6/21/10, maning sambale emmanuel.samb...@gmail.com wrote: http://tinyurl.com/2v82xav http://www.4x4community.co.za/forum/showthread.php?t=12727 http://roadguide.ph/forums/showthread.php?t=224 On Mon, Jun 21, 2010 at 5:03 PM, Jim Morgan j...@datalude.com wrote: Bart Bartolome wrote, On Monday, 21 June, 2010 04:45 PM: Can you guys help me with how to get the tracks out of the garmin mobile xt? Googling didn't help me. ;) My immediate thought would be GPSbabel ... http://www.gpsbabel.org/ Have you tried this already? It seems to handle most Garmin formats, and I imagine the serial/USB protocol would be the same for all models So you might do something like this for Windows gpsbabel -t -i garmin -f com1 -o gpx -F output.gpx Or in linux: gpsbabel -t -i garmin -f /dev/ttyS0 -o gpx -F output.gpx You might have to try a few different formats (ie, change the bit after -i) and you'd have to know the port the unit is connected to ( com1 or /dev/ttyS0 ) Jim -- datalude: information security e: j...@datalude.com Philippines: +63 2 403 1311 / mob: +63 920 912 5830 Hong Kong: +852 6840 6693 w: http://www.datalude.com/ ___ 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 -- --- I explore, therefore I blog. http://www.backpackingphilippines.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] OpenStreetMap Philippines Inc. a Non-Stock Corporation May 28, 2010
http://wiki.openstreetmap.org/wiki/WikiProject_Philippines/Events/SkillShare please add your name and desired topic On Mon, Jun 21, 2010 at 5:25 PM, Eugene Alvin Villar sea...@gmail.com wrote: I think Caffecino also has free Wi-Fi. I just haven't updated the Ka-Fi directory yet. I also think that they have power outlets since they have a small function room. But they're expensive. On Mon, Jun 21, 2010 at 4:45 PM, Bart Bartolome linuxbast...@paglalakbay.com wrote: Only Krispy Kreme and McDonald's has free wi-fi? Bummer. Last time I went to eastwood (a week ago) mcdonald's city walk is under renovations. Can you guys help me with how to get the tracks out of the garmin mobile xt? Googling didn't help me. ;) On Monday, 21 June, 2010 04:40 PM, maning sambale wrote: Can we confirm this June 26, 2010 Eastwood City, Libis 5 pm onwards Skillshare and OSM-PH Org meeting any cafe with free wifi http://www.ka-fi.com/location/libis_eastwood/ On Mon, Jun 21, 2010 at 2:12 PM, Andre Marcelo-Tanner an...@enthropia.com wrote: Is this pushing through? :) ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ 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] skillshare
if this is pushing thru. am interested but 50-50 (well, maybe 70-30). topic: miscellaneous maybe always been curious how to do a no left turn. that new program nuwtrac (?) geosync technics? (using camera) (efficient to way to collect data) search function on garmin (255) working erratically, unable to search streets which are on the map. why? proper label for projects that are being constructed or just announced with billboard? questions of this sort. etc. ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] weird wedding map edit
I find this edit weird: http://www.openstreetmap.org/browse/changeset/5042575 353 POIs removed! I already asked the editor for clarification, just in case it is a mistake, I will request a revertion. -- 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] Fwd: request for revert changeset 5042575
Sent this request to the OSm main list where most of the osm-revert operators are subscribed. -- Forwarded message -- From: maning sambale emmanuel.samb...@gmail.com Date: Tue, Jun 22, 2010 at 9:38 AM Subject: request for revert changeset 5042575 To: osm-talk t...@openstreetmap.org Hi, I would like to request a complete revert of this changeset: http://www.openstreetmap.org/browse/changeset/5042575 The user removed approximately 350++ POIs and removed all oneway tags within a fairly mature (osm-wise) area in Metro Manila. I already sent a message to the editor (no response so far), however, since this is a mature area, the osm-ph list agreed to revert the whole changeset to avoid further damage when other contributors try to correct the data by piecemeal. The changeset comment was wedding map, maybe the user wants a simplified map for a wedding invitation. :) -- 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] weird wedding map edit
The changeset is now reverted: http://www.openstreetmap.org/browse/changeset/5047946 Can anyone please this way: http://www.openstreetmap.org/browse/way/10590362 It's the only conflict in reversion process, otherwise everything is clean. :) IRC chat logs with balrog (who made the revertion) maning request for changeset revertion maning http://lists.openstreetmap.org/pipermail/talk/2010-June/051141.html maning hope the revert operators catch the message balrog-k1n maning: the ways have not been removed? balrog-k1n i think i can try reverting, let's see maning yes the ways haven't been removed just tags and pois are removed. maning thanks! balrog-k1n np balrog-k1n i hope there are no conflicts and if there are then that there will be someone to take care of what couldn't be undeleted because of them maning looking at the recent edits, no one is editing the area so far balrog-k1n oh good maning @ balrog, thanks, we owe you [insert your preffered bevarage] balrog-k1n maning: no problem, it's mostly automatic, but let's see if it works first :) balrog-k1n my scripts always break in some way maning OK I'll wait then. After your revertion, we can do some of the clean-up by hand. balrog-k1n yay, seems to have succeeded with just one conflicting way (in #5047942) balrog-k1n sorry, in #5047946 balrog-k1n http://www.openstreetmap.org/browse/way/10590362 is the conflicting way balrog-k1n i left it intact and reverted the rest balrog-k1n um no, i haven't balrog-k1n ah i know what happened, balrog-k1n the user had edited that way twice in this changeset balrog-k1n so i edited it and then had a conflict when trying to revert the second edit :P balrog-k1n anyway that's the only thing to check maning OK thanks for the help. balrog-k1n np maning I'll ask local mappers to check on that way. On Tue, Jun 22, 2010 at 9:54 AM, maning sambale emmanuel.samb...@gmail.com wrote: revertion commencing ... On Tue, Jun 22, 2010 at 7:53 AM, Eugene Alvin Villar sea...@gmail.com wrote: Revert the whole thing even if the user has not replied yet. The user deleted all the oneway=yes tags he can find. On Tue, Jun 22, 2010 at 6:42 AM, maning sambale emmanuel.samb...@gmail.com wrote: I find this edit weird: http://www.openstreetmap.org/browse/changeset/5042575 353 POIs removed! I already asked the editor for clarification, just in case it is a mistake, I will request a revertion. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- 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-be] how to insert a street with multiples branches
Hello, Sometimes, some ways are gathered and «baptized» with the same name, but the resulting «street» is not composed of a single line. It's often the case in rural areas when new houses are builded on anonymous and close ways. In OSM, you can't join the differents segments in one way. And the segments are often made of different characteristics (width, surface...). I've been confronted with that in my first plots. I thought that the solution was to gather the ways in a relation (http://www.openstreetmap.org/browse/relation/965688) and to give the name to the relation only, but the name of the relation doesn't appear in the rendering. So what is the best practice in such cases ? To tag all the segments with the same name ? Is it however convenient to create a relation to gather all the segments ? Regards, Gauthier ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Removing ways in Potlatch
If historical data is really desired then it seems like there need to be some features added to support it. By default historical data should obviously not be rendered but it also shouldn't even show up in editors unless you explicitly specify it via some option. Otherwise new mappers are going to be like I surveyed this area and there is no road there! and hit delete without giving it another thought. Heck, I've done that. There were two hospitals being rendered in my city that no longer exist. One is a frat house and the other is an apartment building. I deleted them because having a hospital icon show up in a map where there is no hospital is most definitely a BAD thing. On Sun, Jun 20, 2010 at 6:23 AM, Lester Caine les...@lsces.co.uk wrote: John Smith wrote: On 20 June 2010 17:07, Steve Bennettstevag...@gmail.com wrote: On Fri, Jun 18, 2010 at 9:10 AM, Alex S.m...@swavely.com wrote: Some would like to see it kept and marked historical, but deleting ways Oh? Could you elaborate? Some people would like to be able to map the 4th dimension (time)... So that historical maps could be shown, but the API would have to be updated to be able to do this by specifying start/end dates and by default only return data that is still deemed current... +10 for that ... main reason I am playing with the mapping is for genealogical reasons, and it would be nice to see the state of things at a particular snapshot in time. Following the development of London for example -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing ways in Potlatch
On 21 June 2010 16:11, Toby Murray toby.mur...@gmail.com wrote: If historical data is really desired then it seems like there need to be some features added to support it. By default historical data should obviously not be rendered but it also shouldn't even show up in By default things should stay as the status quo, how this is implemented will be the hard thing. With the filtering code that now exists in JOSM this could be done by editors, but it only takes one editor that does filter to have a lot of hard work suddenly be deleted, so realistically this needs server side changes. Rendering on the other hand will be more tricky, although for most people this will most likely only need osm2pgsql tweaking to filter out historical data by default. editors unless you explicitly specify it via some option. Otherwise new mappers are going to be like I surveyed this area and there is no road there! and hit delete without giving it another thought. Heck, I've done that. There were two hospitals being rendered in my city that no longer exist. One is a frat house and the other is an apartment building. I deleted them because having a hospital icon show up in a map where there is no hospital is most definitely a BAD thing. Erm deleted or altered the tags? If they still exist, but have other uses they shouldn't have been deleted... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging for street danger levels
On Monday 21 June 2010 01:21:19 Roy Wallace wrote: On Sun, Jun 20, 2010 at 6:17 AM, Anthony o...@inbox.org wrote: Personally I don't mind if they add some sort of subjective hazard level tag as well as these objective tags, but I think the objective tags will be much more useful in the long term. +1. Please map the cause of the hazard, instead of (or at least as well as) a vague, subjective meta-description of a conglomeration of factors. If you are having trouble tagging any of these factors, e.g. traffic flow, let's discuss and fix that instead. So we are going to retag all highway=primary|secondary|tertiary|unclassified to highway=road and then tag the number of lanes and their width and surface in stead? Something tells me I heard all those arguments a time or two or three before and they still don't make sense. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging for street danger levels
On Mon, Jun 21, 2010 at 4:40 PM, Cartinus carti...@xs4all.nl wrote: +1. Please map the cause of the hazard, instead of (or at least as well as) a vague, subjective meta-description of a conglomeration of factors. If you are having trouble tagging any of these factors, e.g. traffic flow, let's discuss and fix that instead. So we are going to retag all highway=primary|secondary|tertiary|unclassified to highway=road and then tag the number of lanes and their width and surface in stead? Not instead, but as well as. You can't infer lanes OR width OR surface from highway=*. In the same way, I expect that I would not be able to choose an informed cycle route based on someone tagging hazard:cycle=2. I'd rather know what the hazard is - high traffic, potholes, narrow lanes, hills, etc. If you insist, go ahead and use hazard:cycle=2 - it doesn't bother me, and may have some use as an interim solution - but I think we should ultimately aim for a better solution, that is, more specific information at least as well as the vague information. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing ways in Potlatch
On Mon, Jun 21, 2010 at 4:11 PM, Toby Murray toby.mur...@gmail.com wrote: If historical data is really desired then it seems like there need to be some features added to support it. That would actually be pretty easy to add in any renderer, if a proposal was made for a tag like status=historic or timespan_end=xxx. By default historical data should obviously not be rendered but it also shouldn't even show up in editors unless you explicitly specify it via some option. Yes, editors need better filters, not just for this reason. My bugbear is administrative boundaries which always get in the way, and rarely need to be edited. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging for street danger levels
On Sat, Jun 19, 2010 at 02:36:46PM -0400, john whelan wrote: I'm also interested in this as Ottawa has recommended cycling routes mainly between cycle lanes and cycle paths how should they be tagged? Easy: as 'route' relations (with 'network=lcn' probably). http://wiki.openstreetmap.org/wiki/Cycle_routes Greets, Jacek ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Fedora packages for GPX video tool
I see there is a script to convert a GPX file into a movie but I'm having some difficulties tracking down some of the pre-req packages specifically for a Fedora 12 distro ie http://wiki.openstreetmap.org/wiki/Party_render Does anyone have an idea where I start to download some of these reqs eg PyCairo and pymedia? Paul ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging for street danger levels
On Mon, Jun 21, 2010 at 12:21 AM, Roy Wallace waldo000...@gmail.com wrote: On Sun, Jun 20, 2010 at 6:17 AM, Anthony o...@inbox.org wrote: Personally I don't mind if they add some sort of subjective hazard level tag as well as these objective tags, but I think the objective tags will be much more useful in the long term. +1. Please map the cause of the hazard, instead of (or at least as well as) a vague, subjective meta-description of a conglomeration of factors. If you are having trouble tagging any of these factors, e.g. traffic flow, let's discuss and fix that instead. Absolutely. Tagging the actual hazards also has additional advantages within OSM, since it's not just a bicycle project. So instead of tagging cyclist-difficulty:2 you were to tag instead that the road is unsurfaced, you'd be helping the OSM-inline-skaters map and their tags would be helping you too. Or if the lanes are too narrow to allow cars to pass bikes easily, then tagging the width of the lanes helps improve the data for horse riders too. Or if there is heavy traffic; well, it's easy to see who else benefits. Specific, verifiable tags are how we organise OSM to promote cooperation in tagging between the whole community. If we all tag things in a bike-specific (or inline-skates specific or horse-specific) manner then we end up with parallel tagging projects. And we probably don't have the density of contributors to handle that beyond a handful of specific areas. Now as for rendering, it's very easy to pre-process the data to give each road a cycleability rating on a scale of 0-5 based on all the other attributes of the road. People do this kind of preprocessing already, such as http://cyclestreets.net who produce their own ratings/metric for each road using a combination of normal tags, to great result. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing ways in Potlatch
On Sun, Jun 20, 2010 at 7:23 PM, Lester Caine les...@lsces.co.uk wrote: John Smith wrote: On 20 June 2010 17:07, Steve Bennettstevag...@gmail.com wrote: On Fri, Jun 18, 2010 at 9:10 AM, Alex S.m...@swavely.com wrote: Some would like to see it kept and marked historical, but deleting ways Oh? Could you elaborate? Some people would like to be able to map the 4th dimension (time)... So that historical maps could be shown, but the API would have to be updated to be able to do this by specifying start/end dates and by default only return data that is still deemed current... +10 for that ... main reason I am playing with the mapping is for genealogical reasons, and it would be nice to see the state of things at a particular snapshot in time. Following the development of London for example One big problem with any 4th dimensional idea is plate tectonics. I'm willing to bet that if you were to map how London was before the great fire of 1666, the coordinates of places won't match their current locations in WGS84 coordinates. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing ways in Potlatch
On 21 June 2010 11:32, Eugene Alvin Villar sea...@gmail.com wrote: One big problem with any 4th dimensional idea is plate tectonics. I'm willing to bet that if you were to map how London was before the great fire of 1666, the coordinates of places won't match their current locations in WGS84 coordinates. Yes it is a problem of using WGS84 as it is an absolute set of coordinates as opposed to more relatives set of coordinates. Emilie Laffray ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fedora packages for GPX video tool
Paul wrote: Does anyone have an idea where I start to download some of these reqs eg PyCairo http://cairographics.org/pycairo/ and pymedia? http://pymedia.org/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing ways in Potlatch
Eugene Alvin Villar wrote: One big problem with any 4th dimensional idea is plate tectonics. I'm willing to bet that if you were to map how London was before the great fire of 1666, the coordinates of places won't match their current locations in WGS84 coordinates. And exactly how do you propose that we get accurate coordinates for the positions of streets in 1665 other using a modern surveyed overlay? I don't think Samuel Pepys supplemented his diary with GPS derived WGS84 coordinates. :-) Any surveying that was done then (some rather accurately) would be done with reference to a fixed object on the landmass. These would have moved coherently on a tectonic plate. The 4 metres or so the plate bearing London has moved since the mid 17thC is only just within our current consumer GPS resolution and therefore on the boundary of our error range. Besides, all this plate movement is relative, who says London has moved at all? -- Cheers, Chris user: chillly ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing ways in Potlatch
On 21 June 2010 21:03, Chris Hill o...@raggedred.net wrote: And exactly how do you propose that we get accurate coordinates for the positions of streets in 1665 other using a modern surveyed overlay? I don't think Samuel Pepys supplemented his diary with GPS derived WGS84 coordinates. :-) Doesn't most countries have their own datum that is fixed to the tectonic plate and they keep track of this in relation with WGS84? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing ways in Potlatch
Also, if only certain parts of a roadway are out of sync between the map and current-day reality, you can't always be sure whether this represents the road having been rerouted (to make a curve less sharp, for instance), or whether this simply represents an error on the part of the original mapper. I have also seen cases where the official map of an area shows a roadway, or even minor bridge, that had been planned but never was built. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria -Original Message- From: Eugene Alvin Villar sea...@gmail.com Sender: talk-boun...@openstreetmap.org Date: Mon, 21 Jun 2010 18:32:00 To: Lester Caineles...@lsces.co.uk Cc: OSM Talktalk@openstreetmap.org Subject: Re: [OSM-talk] Removing ways in Potlatch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging for street danger levels
Toby Murray wrote: Someone in my area is starting up a new website that is focused on cycling in the city. They have decided to use OSM as their map which is awesome. Streets are not dangerous to bicyclists; ~intersections~ are dangerous to bicyclists. When bicyclists modify their behavior in search of safe streets they set themselves up, lemming like, to be killed at intersections. Most of the dangerous and (mostly) illegal cycling behaviors that are widespread, such as riding on sidewalks, riding on the wrong side of the road, riding on sidewalks on the wrong side of the road, and weaving around parked cars are derived from this fantasy cyclists have that some motorist is going to come up from behind in a faster, larger vehicle and cream them. In reality, the self-preservation of motorists forces them to be looking ahead of themselves for vehicles that behave like other automobiles. Cyclists are most likely to be picked up by that scanning behavior if they follow traffic rules. If they disobey traffic rules, they're at much greater risk. Cyclists may be safer if they follow a dangerous busy street that is well signalized and has few dangerous intersections than riding on a safe back alley that crosses numerous busy streets at poorly defined intersections. There very well may be an objective measurement of the safety of ways, routes, and intersections, but the majority of cyclists have demonstrated in everyday behavior and by their actions in the political sphere that the mental model of safety that they have is dangerously incorrect. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Finding relation members in osm2pgsql PostGIS database?
I've got a PostGIS database created and maintained with osm2pgsql. For some of the Mapnik rendering I'm doing, I'd like to see whether ways belong to relations. (Specifically, whether a highway=* way is a member of a route=road relation.) I've been able to look in the planet_osm_rels table for relation membership, but the members are stored in an array, and searching those arrays for membership, even on a bbox-restricted subset, is really slow. Is there any way to do this faster? If not, I suppose I can file a feature request against osm2pgsql for an indexed relation membership table. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Last Rule of Politics: Kingdoms are good. Empires are evil. -- Console Role Playing Game Clichés, item 74 --- -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Failed to download 9.5 GB planet
Dear list: I'm trying to download one of the latest planets and I repeatedly get this error message, always after ~1.5 GB, with wget and also using Mozilla Firefox. Any idea why this happens and how to solve it? ... 1583000K .. .. .. 15%1.36 MB/s 1583050K .. .. .. 15%1.16 MB/s 1583100K ... 15%2.90 MB/s 16:23:53 (1.02 MB/s) - Connection closed at byte 1621101924. Retrying. --16:23:53-- http://ftp.heanet.ie/mirrors/openstreetmap.org/planet-100618.osm.bz2 (try: 2) = `planet_100618.osm.bz2' Connecting to ftp.heanet.ie|193.1.193.64|:80... connected. HTTP request sent, awaiting response... 500 ( Arithmetic result exceeded 32 bits. ) 16:23:53 ERROR 500: ( Arithmetic result exceeded 32 bits. ). Regards Juan Lucas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Failed to download 9.5 GB planet
most likely your OS, or disk partition, or wget can't handle large files. on old unix systems this is usually 2GB. on windows FAT partitions there are also limits but don't know the numbers On 21 Jun 2010, at 9:12 , Juan Lucas Domínguez Rubio wrote: Dear list: I'm trying to download one of the latest planets and I repeatedly get this error message, always after ~1.5 GB, with wget and also using Mozilla Firefox. Any idea why this happens and how to solve it? ... 1583000K .. .. .. 15%1.36 MB/s 1583050K .. .. .. 15%1.16 MB/s 1583100K ... 15%2.90 MB/s 16:23:53 (1.02 MB/s) - Connection closed at byte 1621101924. Retrying. --16:23:53-- http://ftp.heanet.ie/mirrors/openstreetmap.org/planet-100618.osm.bz2 (try: 2) = `planet_100618.osm.bz2' Connecting to ftp.heanet.ie|193.1.193.64|:80... connected. HTTP request sent, awaiting response... 500 ( Arithmetic result exceeded 32 bits. ) 16:23:53 ERROR 500: ( Arithmetic result exceeded 32 bits. ). Regards Juan Lucas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging for street danger levels
On Mon, Jun 21, 2010 at 2:40 AM, Cartinus carti...@xs4all.nl wrote: On Monday 21 June 2010 01:21:19 Roy Wallace wrote: On Sun, Jun 20, 2010 at 6:17 AM, Anthony o...@inbox.org wrote: Personally I don't mind if they add some sort of subjective hazard level tag as well as these objective tags, but I think the objective tags will be much more useful in the long term. +1. Please map the cause of the hazard, instead of (or at least as well as) a vague, subjective meta-description of a conglomeration of factors. If you are having trouble tagging any of these factors, e.g. traffic flow, let's discuss and fix that instead. So we are going to retag all highway=primary|secondary|tertiary|unclassified to highway=road and then tag the number of lanes and their width and surface in stead? That would probably piss people off. Would be fine with me, though. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging for street danger levels
2010/6/21 Anthony o...@inbox.org: So we are going to retag all highway=primary|secondary|tertiary|unclassified to highway=road and then tag the number of lanes and their width and surface in stead? That would probably piss people off. Would be fine with me, though. this discussion (and voting) took already place some time ago and I really would not like to go through it again. Since then it should be clear that the highway-class is an additional information to surface, lanes and width. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Finding relation members in osm2pgsql PostGIS database?
On 22 June 2010 01:15, Phil! Gold phi...@pobox.com wrote: I've got a PostGIS database created and maintained with osm2pgsql. For some of the Mapnik rendering I'm doing, I'd like to see whether ways belong to relations. (Specifically, whether a highway=* way is a member of a route=road relation.) I've been able to look in the planet_osm_rels table for relation membership, but the members are stored in an array, and searching those arrays for membership, even on a bbox-restricted subset, is really slow. Is there any way to do this faster? If not, I suppose I can file a feature request against osm2pgsql for an indexed relation membership table. osm2pgsql probably isn't the best tool for the job, relations get stored as geometries in the database, rather than meta information cross referencing the ways. What you are after is a database structure similar/the same as the main OSM DB to be able to do this kind of interrogation rather than trying to interrogated pre-processed information which has lost some/a lot of non-desirable attributes to make rendering faster. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing ways in Potlatch
Steve Bennett stevagewp at gmail.com writes: On Mon, Jun 21, 2010 at 4:11 PM, Toby Murray toby.murray at gmail.com wrote: If historical data is really desired then it seems like there need to be some features added to support it. That would actually be pretty easy to add in any renderer, if a proposal was made for a tag like status=historic or timespan_end=xxx. We have a GIS system where all the features have two attributes for this purpose: birth_date and death_date. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Pilot project to purchase 40 gps devices and train mappers in Kosovo
Hi, here is a project were the OSM community can help, We are getting 2000 Euros to purchase devices and have a School to train new mappers for Kosovo, http://www.openstreetmap.org/user/h4ck3rm1k3/diary/11036 All suggestion for hardware and training are welcome. This is something where the community could help make a difference. thanks, mike -- James Michael DuPont Member of Free Libre Open Source Software Kosova and Albania flossk.org flossal.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Finding relation members in osm2pgsql PostGIS database?
2010/6/21 Phil! Gold phi...@pobox.com: I've got a PostGIS database created and maintained with osm2pgsql. For some of the Mapnik rendering I'm doing, I'd like to see whether ways belong to relations. (Specifically, whether a highway=* way is a member of a route=road relation.) I've been able to look in the planet_osm_rels table for relation membership, but the members are stored in an array, and searching those arrays for membership, even on a bbox-restricted subset, is really slow. Is there any way to do this faster? If not, I suppose I was playing around with representing ways as arrays of node id:s the other day, and I got seemingly decent performance, at least doing array intersection tests (using '', stuff like what other ways share nodes with this way), by building a GIN index on the array column. I was just playing around with it interactively though, so it might still be too slow for heavy use. Just mentioning it in case you have not tried. :-) -- Ture ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging for street danger levels
On Tue, 22 Jun 2010, Paul Houle wrote: Toby Murray wrote: Someone in my area is starting up a new website that is focused on cycling in the city. They have decided to use OSM as their map which is awesome. Streets are not dangerous to bicyclists; ~intersections~ are dangerous to bicyclists. When bicyclists modify their behavior in search of safe streets they set themselves up, lemming like, to be killed at intersections. Most of the dangerous and (mostly) illegal cycling behaviors that are widespread, such as riding on sidewalks, riding on the wrong side of the road, riding on sidewalks on the wrong side of the road, and weaving around parked cars are derived from this fantasy cyclists have that some motorist is going to come up from behind in a faster, larger vehicle and cream them. In reality, the self-preservation of motorists forces them to be looking ahead of themselves for vehicles that behave like other automobiles. Cyclists are most likely to be picked up by that scanning behavior if they follow traffic rules. If they disobey traffic rules, they're at much greater risk. Cyclists may be safer if they follow a dangerous busy street that is well signalized and has few dangerous intersections than riding on a safe back alley that crosses numerous busy streets at poorly defined intersections. There very well may be an objective measurement of the safety of ways, routes, and intersections, but the majority of cyclists have demonstrated in everyday behavior and by their actions in the political sphere that the mental model of safety that they have is dangerously incorrect. Firstly I don't agree with your assessment. Secondly, how will this assist with tagging streets unsuitable for cycling? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] request for revert changeset 5042575
Hi, I would like to request a complete revert of this changeset: http://www.openstreetmap.org/browse/changeset/5042575 The user removed approximately 350++ POIs and removed all oneway tags within a fairly mature (osm-wise) area in Metro Manila. I already sent a message to the editor (no response so far), however, since this is a mature area, the osm-ph list agreed to revert the whole changeset to avoid further damage when other contributors try to correct the data by piecemeal. The changeset comment was wedding map, maybe the user wants a simplified map for a wedding invitation. :) -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] request for revert changeset 5042575
Thanks to balrog for responding to the request: http://www.openstreetmap.org/browse/changeset/5047946 On Tue, Jun 22, 2010 at 9:38 AM, maning sambale emmanuel.samb...@gmail.com wrote: Hi, I would like to request a complete revert of this changeset: http://www.openstreetmap.org/browse/changeset/5042575 The user removed approximately 350++ POIs and removed all oneway tags within a fairly mature (osm-wise) area in Metro Manila. I already sent a message to the editor (no response so far), however, since this is a mature area, the osm-ph list agreed to revert the whole changeset to avoid further damage when other contributors try to correct the data by piecemeal. The changeset comment was wedding map, maybe the user wants a simplified map for a wedding invitation. :) -- 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 mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
Vrijwilligers doen dat helemaal gratis omdat ze het leuk vinden. Als jij dat te veel moeite vind, dan hoef je niet mee te helpen. Maar eisen dat een ander daar geld aan uit gaat geven is, . -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
On Sun, Jun 20, 2010 at 11:45:56PM +0200, Polderrunner wrote: || Een andere vraag: Vaak volgt de route van punt A naar B een andere route || dan die van B naar A (door fietspaden met eenrichtingsverkeer etc). Wat || is best? Aparte relaties voor de routes A-B en B-A of gebruik van || forward/backward roles in dezelfde route relation? Ik vind zelf het || gebruik van twee aparte relaties meer logisch. Ik denk dat het het extra werk niet waard is. Sterker, het is duplicatie van informatie: die delen die tweerichting zijn komen dan twee keer in de database. Dat is niet handig. Daarom vind ik de forward/backward (waarom eigenlijk niet reverse? Backward klinkt een beetje... achterlijk?) beter. Ciao.Vincent. -- Vincent Zweije zwe...@xs4all.nl| If you're flamed in a group you http://www.xs4all.nl/~zweije/ | don't read, does anybody get burnt? [Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
2010/6/21 Cartinus carti...@xs4all.nl: Vrijwilligers doen dat helemaal gratis omdat ze het leuk vinden. Als jij dat te veel moeite vind, dan hoef je niet mee te helpen. Maar eisen dat een ander daar geld aan uit gaat geven is, . Wie heeft het hier over geld uitgeven? Het geld is al uitgegeven, en er hoeft niets extra's bij. Laat ze ons de permissie geven, en die vrijwilligers doen de rest. -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
Wij (Goudappel Coffeng) zijn bezig voor Limburg, Noord-Brabant, Zeeland en Twente OSM te verbeteren om hier een fietsrouteplanner op te baseren. Onze opdrachtgevers hebben hier juist voor gekozen omdat de data die wij genereren niet alleen in onze eigen planner blijft maar vanzelf meer nut genereert (van een touristische I-Phone app in Zeeland tot garmin-downloads). In dit kader worden natuurlijk ook de fietsknopennetwerken opnieuw nagelopen. Wij hebben de fietsersbond uitgenodigd hierin met ons samen te werken - onze data dubbel-licensed ook in de fietsersbond planner en hun data via ons naar OSM. De gesprekken hierover lopen nog. Dirk Bussche Disclaimer De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. De afzender sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending.inline: 0F365215.gif___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
-Flink wat meer dom werk Realiseer ik me, hoewel het volgens mij minimaal is, als je eenmaal je routine erop aangepast hebt. Zoals het toevoegen van de knooppuntnodes zelf. De eerste keer zul je meermalen de relation editor openen, maar je leert snel genoeg om dat gelijk mee te nemen met het toevoegen van de ways. -Aan de netwerk relatie kan je niet zien welke knooppunten deelnemen, anders dan de interne node nummers. Dat klopt, maar dat is dan iets van binnen de editor. Dat verandert niets aan de validiteit van de data opzich. Om nog maar niet te spreken over de editing problemen als er een stukje wijzigt en je niet alleen de route relatie moet wijzigen, maar ook de grote relatie. Als je alleen een stukje van de routerelatie wijzigt, hoef je niet de netwerkrelatie te wijzigen. In de netwerkrelatie zitten immers alleen de knooppunten en de routerelaties, niet de afzonderlijke wegen van de routerelaties. Dat laatste heb ik wel geconstateerd op plekken, maar is dus niet de manier van dit schema. Het lijkt mij veel slimmer om die grote relatie door een Botje op regelmatig tijdstip samen te stellen uit de nu al getagde informatie. Mijn plan is het nog steeds om er een diagnosetool voor te maken, die dit soort dingen in ieder geval signaleert, en wellicht sommige dingen zelf kan corrigeren. Ook het toevoegen van de begin en end nodes kan automatisch. Niet in alle gevallen. Misschien kan de laatste versie van JOSM overweg met die multilevel Relaties, maar dan moet er voor mij in elk geval wel een heel goede tutorial/wiki komen. Die relatie editor is zo al ingewikkeld. Multilevelrelaties in JOSM zijn niet zo'n probleem. Je ziet gewoon een andere relatie als lid van de de relatie staan in de editor. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
Ik steun je datamodel, maar niet het extra werk. Alle getallen langer dan pincodes hebben bij mij nl pen en papier nodig, en ik heb zo de indruk dat je gewoon veel extra werk nodig hebt om relatie nummers in te toetsen. Alle getallen langer dan pincodes hebben op mijn leeftijd nl pen en papier nodig ;) Heb ik het verkeerd ?? Maar, ik zal het eens proberen. Is het veel gevraagd om er een soort stap-voor-stap (met wat controlepunten) wiki voor te maken ?? Begin je met de netwerkrelatie, of met de route relatie? Wat is handiger, Horen de tussenliggende punten ook bij de routes in jouw model ? (ik begrijp van niet maar weet het niet zeker) Gert Gremmen - Openstreetmap.nl (alias: cetest) Before printing, think about the environment. -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Lennard Verzonden: Monday, June 21, 2010 11:11 AM Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Fiets Knooppuntennetwerken -Flink wat meer dom werk Realiseer ik me, hoewel het volgens mij minimaal is, als je eenmaal je routine erop aangepast hebt. Zoals het toevoegen van de knooppuntnodes zelf. De eerste keer zul je meermalen de relation editor openen, maar je leert snel genoeg om dat gelijk mee te nemen met het toevoegen van de ways. -Aan de netwerk relatie kan je niet zien welke knooppunten deelnemen, anders dan de interne node nummers. Dat klopt, maar dat is dan iets van binnen de editor. Dat verandert niets aan de validiteit van de data opzich. Om nog maar niet te spreken over de editing problemen als er een stukje wijzigt en je niet alleen de route relatie moet wijzigen, maar ook de grote relatie. Als je alleen een stukje van de routerelatie wijzigt, hoef je niet de netwerkrelatie te wijzigen. In de netwerkrelatie zitten immers alleen de knooppunten en de routerelaties, niet de afzonderlijke wegen van de routerelaties. Dat laatste heb ik wel geconstateerd op plekken, maar is dus niet de manier van dit schema. Het lijkt mij veel slimmer om die grote relatie door een Botje op regelmatig tijdstip samen te stellen uit de nu al getagde informatie. Mijn plan is het nog steeds om er een diagnosetool voor te maken, die dit soort dingen in ieder geval signaleert, en wellicht sommige dingen zelf kan corrigeren. Ook het toevoegen van de begin en end nodes kan automatisch. Niet in alle gevallen. Misschien kan de laatste versie van JOSM overweg met die multilevel Relaties, maar dan moet er voor mij in elk geval wel een heel goede tutorial/wiki komen. Die relatie editor is zo al ingewikkeld. Multilevelrelaties in JOSM zijn niet zo'n probleem. Je ziet gewoon een andere relatie als lid van de de relatie staan in de editor. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
On Friday 18 June 2010 23:02:20 Philip Homburg wrote: In your letter dated Fri, 18 Jun 2010 21:02:57 +0200 you wrote: Dit vind ik een twijfelachtige conclusie. Het zou namelijk er ook op kunnen duiden dat de AND data gewoon klopt, en dus niet aangepast hoeft te worden. Ja, en nee. Het klopt dat in veel gevallen de AND data gewoon correct is. Dus in die zin denk ik dat we daar erg blij mee moeten zijn. Maar de AND data is, zeker op het gebied van fietsenpaden, natuurlijk ook erg onvolledig. En als je een fietspad mapt, dan sluit dat ook aan op de AND data, dus krijgt die weg vaak een nieuw versie nummer. Het nadeel van de AND data is dus dat als je naar de kaart kijkt het er gewoon goed uitziet. Pas als je echt in dat gebied rond rijdt zie alle ontbrekende fietspaden. Dus voor mensen die tijd overhebben, (en dat ben ik dus niet) is misschien een overlay met alleen AND versie 1 data wel handig. Dan weet je dat daar wat te mappen valt. Als er toevallig toch helemaal niets te doen is, dan zet je er de juist maxspeed tags op, en dan verdwijnt ie vanzelf van de overlay. Lennard heeft zich weer uitgeleefd: http://mijndev.openstreetmap.nl/~ldp/no- AND/?zoom=9lat=52.35665lon=5.03601layers=0B00 De enige kaart waar we steeds minder data op willen zien ;) Cheers, --Roeland ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
On Mon, 21 Jun 2010 11:56:41 +0200, Roeland Douma u...@rullzer.com wrote: On Friday 18 June 2010 23:02:20 Philip Homburg wrote: In your letter dated Fri, 18 Jun 2010 21:02:57 +0200 you wrote: Dit vind ik een twijfelachtige conclusie. Het zou namelijk er ook op kunnen duiden dat de AND data gewoon klopt, en dus niet aangepast hoeft te worden. Ja, en nee. Het klopt dat in veel gevallen de AND data gewoon correct is. Dus in die zin denk ik dat we daar erg blij mee moeten zijn. Maar de AND data is, zeker op het gebied van fietsenpaden, natuurlijk ook erg onvolledig. En als je een fietspad mapt, dan sluit dat ook aan op de AND data, dus krijgt die weg vaak een nieuw versie nummer. Het nadeel van de AND data is dus dat als je naar de kaart kijkt het er gewoon goed uitziet. Pas als je echt in dat gebied rond rijdt zie alle ontbrekende fietspaden. Dus voor mensen die tijd overhebben, (en dat ben ik dus niet) is misschien een overlay met alleen AND versie 1 data wel handig. Dan weet je dat daar wat te mappen valt. Als er toevallig toch helemaal niets te doen is, dan zet je er de juist maxspeed tags op, en dan verdwijnt ie vanzelf van de overlay. Lennard heeft zich weer uitgeleefd: http://mijndev.openstreetmap.nl/~ldp/no- AND/?zoom=9lat=52.35665lon=5.03601layers=0B00 De enige kaart waar we steeds minder data op willen zien ;) Zo te zien is dit een kaart waar alleen de AND data op staat waar niets mee gedaan is? Dan is het een leuke gimmick, maar nietszeggend. Ik zie dat in mijn gemeente bijna alle wegen weg zijn. Dat komt omdat ik op bijna alle wegen een maxspeed tag heb gezet. En dan duiken ze hier dus niet meer op. Dat wil echter totaal niet zeggen dat die wegen ook correct a.d.h. van GPS tracks zijn gelegd of dat er extra features zijn toegevoegd. Of komt er meer detail met wegen die weer toegevoegd zijn na de AND import als je verder inzoomt? Vanaf zoom 14 krijg ik geen tiles meer. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
2010/6/21 Maarten Deen md...@xs4all.nl: Zo te zien is dit een kaart waar alleen de AND data op staat waar niets mee gedaan is? Dan is het een leuke gimmick, maar nietszeggend. Ik zie dat in mijn gemeente bijna alle wegen weg zijn. Dat komt omdat ik op bijna alle wegen een maxspeed tag heb gezet. En dan duiken ze hier dus niet meer op. Dat wil echter totaal niet zeggen dat die wegen ook correct a.d.h. van GPS tracks zijn gelegd of dat er extra features zijn toegevoegd. Ik denk dat de enige manier om ook dat soort informatie te hebben, is dat we bij het bewerken gebieden aangeven die we hebben gedaan, met daarbij de informatie (in ruwe categorieën) wát we hebben gedaan. En zoiets werkt dan eigenlijk weer alleen goed als iedereen het zou doen, en dat zie ik nog niet gebeuren. -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
On Mon, 21 Jun 2010 13:05:34 +0200, Andre Engels andreeng...@gmail.com wrote: 2010/6/21 Maarten Deen md...@xs4all.nl: Zo te zien is dit een kaart waar alleen de AND data op staat waar niets mee gedaan is? Dan is het een leuke gimmick, maar nietszeggend. Ik zie dat in mijn gemeente bijna alle wegen weg zijn. Dat komt omdat ik op bijna alle wegen een maxspeed tag heb gezet. En dan duiken ze hier dus niet meer op. Dat wil echter totaal niet zeggen dat die wegen ook correct a.d.h. van GPS tracks zijn gelegd of dat er extra features zijn toegevoegd. Ik denk dat de enige manier om ook dat soort informatie te hebben, is dat we bij het bewerken gebieden aangeven die we hebben gedaan, met daarbij de informatie (in ruwe categorieën) wát we hebben gedaan. En zoiets werkt dan eigenlijk weer alleen goed als iedereen het zou doen, en dat zie ik nog niet gebeuren. Je moet juist zaken die in de AND import zaten niet laten zien, maar juist de zaken die daarna zijn toegevoegd. Dus eigenlijk kijken wat het hoogste ID van de AND import is, en alleen de ways en de nodes (plus ways die daaraan vastzitten) van daarna laten zien. Als je bijvoorbeeld een kruising ombouwt naar een rotonde, dan krijg je extra nodes. En waar je dan witte vlekken hebt, dat zijn de gebieden waar je aandacht aan wil besteden. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
In your letter dated Mon, 21 Jun 2010 13:32:00 +0200 you wrote: Weer het voorbeeld van mijn woonplaats: nu is het hele dorp zichtbaar, terwijl voor de meeste wegen alleen maar een maxspeed tag is toegevoegd, en die wegen zijn niet meer af dan wegen in lutjebroek die niet geraakt zijn. Ik ga er even vanuit dat je niet zomaar overal een maxspeed tag op gezet hebt, maar dat je ook gecontroleerd hebt of die wegen echt bestaan, etc. In dat geval is het toch prima. Je kan eindeloos lang aan OSM data blijven poetsen. Het hangt natuurlijk ook van je doel af. Ik gebruik OSM voornamelijk als route planner. Voor mij is het belangrijk dat data die in OSM staat correct is (er is niets vervelenders dan naar een weg gestuurd te worden waar je niet mag rijden). En liefst dat het ook volledig genoeg is dat je geen rare routes krijgt. Of het er op een kaart mooi uitziet is iets waar ik me minder druk over maak. Maar dat kan voor iemand anders natuurlijk juist wel heel belangrijk zijn. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
2010/6/21 Maarten Deen md...@xs4all.nl: Nee, dan krijg je ook de AND data die veranderd is. Ik wil alleen de na-AND data zien. Dus alle nodes en ways die door de AND import zijn gemaakt wil ik niet zien, zolang de enige aanpassing een tag-change is. Wel nodes die verplaatst zijn, en alle ways die aan die nodes vastzitten. Weer het voorbeeld van mijn woonplaats: nu is het hele dorp zichtbaar, terwijl voor de meeste wegen alleen maar een maxspeed tag is toegevoegd, en die wegen zijn niet meer af dan wegen in lutjebroek die niet geraakt zijn. Dat zou inderdaad ook andere categorieën schijnbaar-gecontroleerde wegen tonen, namelijk de wegen waar de enige wijziging een verandering van categorie is (omdat de AND-import wel erg veel wegen als tertiary heeft). Anderzijds zouden er ook veel meer false positives zijn. Daarnaast ben ik nog steeds van mening dat ook in jouw voorstel het tonen van juist de niet (of onvoldoende) gewijzigde data inzichtelijker is dan het tonen van de wél gewijzigde data. -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
Goede reminder.. Ik had nog een track liggen met een paar Zeeuwse knooppunten (van vorig jaar). Het zet niet heel veel zoden aan de dijk, maar beter dan laten roesten.. Foppe Op 19-06-10 14:38, ce-test, qualified testing bv - Gert Gremmen schreef: Zijn er nog lieden in de streek Den Haag-Rotterdam-Bergschenhoek-Zoetermeer leiden die zin hebben om wat fiestroutes compleet te maken. Dit voorjaar zijn er 2 netwerken (rotterdam en haaglanden) geopend, en die mogen nu best worden aangesloten op de rest van Nederland. Ik hoop na een pijnlijke winter en druk voorjaar in juli weer deze 2 netwerken compleet te maken.en kan wel wat hulp gebruiken. Overigens, waar blijven de OSM-Zeeuwen, ook daar moet nog heel wat gefietst worden. [GG] Gert Gremmen ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
On 21-6-2010 14:24, Andre Engels wrote: Dat zou inderdaad ook andere categorieën schijnbaar-gecontroleerde wegen tonen, namelijk de wegen waar de enige wijziging een verandering van categorie is (omdat de AND-import wel erg veel wegen als tertiary heeft). Anderzijds zouden er ook veel meer false positives zijn. Komt dat even mooi uit! De hiervoor genoemde kaartjes zijn een uitloper van het project waar ik daarvoor mee bezig was: het downgraden van de vele tertiary wegen van de AND-import naar unclassified. Het resultaat in beeld vind je hier: http://mijndev.openstreetmap.nl/~ldp/AND-reclassified/ De visualisering daar gaat uit van de volgende interpretatie: highway=tertiary + AND:importance_level=5 + version=1 = highway=unclassified highway=secondary + AND:importance_level=4 + version=1 + geen ref=* = highway=tertiary Door juist niet ook op user=AND te testen pak ik hier de gevallen mee waar iemand een AND version=1 straat heeft gesplitst. Let op: dit is dus alleen maar een speciale kaart met dit erin verwerkt. Het herclassificeren is dus nog niet daadwerkelijk gebeurd. Roeland bouwt hiervoor nog een scriptje. Een eventuele actie zal dan ook onder de user AND (voor de wegen die nu ook van AND zijn) resp. een ander account (voor de niet-AND wegen, dus de afgesplitste stukken) kunnen draaien. Op het forum zijn ze alvast enthousiast voor deze herclassificatie. Hoe denken jullie er hier op de ML over? Daarnaast ben ik nog steeds van mening dat ook in jouw voorstel het tonen van juist de niet (of onvoldoende) gewijzigde data inzichtelijker is dan het tonen van de wél gewijzigde data. Als er een visualisatie gewenst is, die gebouwd kan worden uit de op _dat_ moment aanwezige data in OSM, dan kunnen we een poging doen om dat in kaart te brengen. Het moet dan specifiek niet gaan over tag changes etc, want zonder volledige history per object is dat niet na te gaan. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
In your letter dated Mon, 21 Jun 2010 16:17:09 +0200 you wrote: Als er een visualisatie gewenst is, die gebouwd kan worden uit de op _dat_ moment aanwezige data in OSM, dan kunnen we een poging doen om dat in kaart te brengen. Het moet dan specifiek niet gaan over tag changes etc, want zonder volledige history per object is dat niet na te gaan. Wat misschien nog wel mooi zou zijn, gezien de klachten over de relatief onnauwkeurige posities in AND data, is om een kaart te maken met alle stukjes weg die nog op dezelfde plaats liggen als vlak na de AND import. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
On Monday 21 June 2010 09:29:57 Andre Engels wrote: Wie heeft het hier over geld uitgeven? Het geld is al uitgegeven, en er hoeft niets extra's bij. Laat ze ons de permissie geven, en die vrijwilligers doen de rest. Als je iets baseert op niet vrije data van een ander, dan kun je het naderhand niet zomaar weggeven. Dus dan kost het geld. Bovendien zomaar fietsroutes overtekenen is lang niet zo nuttig als ze opnieuw verkennen. Als je ze opnieuw verkent dan zie je ook allerlei andere dingen zoals bankjes, maximumsnelheid, hindernissen, gewijzigde of nog niet aanwezige wegen/paden, etc. En nogmaals: Als mensen het teveel moeite vinden om te mappen, wat doen ze hier dan? -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
2010/6/21 Cartinus carti...@xs4all.nl: On Monday 21 June 2010 09:29:57 Andre Engels wrote: Wie heeft het hier over geld uitgeven? Het geld is al uitgegeven, en er hoeft niets extra's bij. Laat ze ons de permissie geven, en die vrijwilligers doen de rest. Als je iets baseert op niet vrije data van een ander, dan kun je het naderhand niet zomaar weggeven. Dus dan kost het geld. Dus jij zegt dat de Fietsersbond hun kaarten niet mogen weggeven? Hebben die mooi een kat in de zak gekocht... Bovendien zomaar fietsroutes overtekenen is lang niet zo nuttig als ze opnieuw verkennen. Als je ze opnieuw verkent dan zie je ook allerlei andere dingen zoals bankjes, maximumsnelheid, hindernissen, gewijzigde of nog niet aanwezige wegen/paden, etc. Dus? Die nieuwe verkenning is sowieso nuttig, maar wordt er niet noodzakelijker op als de data met ons gedeeld wordt. En nogmaals: Als mensen het teveel moeite vinden om te mappen, wat doen ze hier dan? Dus jij bent van mening dat al die AND-data en 3dshapes-data en data gebaseerd op Yahoo-afbeeldingen en data gebaseerd op het eigen geheugen maar verwijderd moet worden omdat we het ook zelf zouden kunnen mappen? -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
2010/6/21 Lennard l...@xs4all.nl: Het resultaat in beeld vind je hier: http://mijndev.openstreetmap.nl/~ldp/AND-reclassified/ De visualisering daar gaat uit van de volgende interpretatie: highway=tertiary + AND:importance_level=5 + version=1 = highway=unclassified highway=secondary + AND:importance_level=4 + version=1 + geen ref=* = highway=tertiary Door juist niet ook op user=AND te testen pak ik hier de gevallen mee waar iemand een AND version=1 straat heeft gesplitst. Let op: dit is dus alleen maar een speciale kaart met dit erin verwerkt. Het herclassificeren is dus nog niet daadwerkelijk gebeurd. Roeland bouwt hiervoor nog een scriptje. Een eventuele actie zal dan ook onder de user AND (voor de wegen die nu ook van AND zijn) resp. een ander account (voor de niet-AND wegen, dus de afgesplitste stukken) kunnen draaien. Op het forum zijn ze alvast enthousiast voor deze herclassificatie. Hoe denken jullie er hier op de ML over? Op zich een goede actie, maar ik zie momenteel nog te veel inconsistente wegen (stukje secondary - stukje tertiary - stukje secondary - stukje tertiary of stukje tertiary - stukje unclassified - stukje tertiary - stukje unclassified). Ook zijn er nog wegen die niet worden meegenomen terwijl ze duidelijk unclassified zouden moeten zijn (vermoedelijk omdat iemand ooit het AND:importance_level heeft gesloopt). Ik denk dus dat het stukje bij beetje moet gebeuren, met daarna een correctie-edit (waarvoor ik best een paar handjes wil helpen). -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waar zouden we zijn zonder AND?
On 21-6-2010 17:53, Andre Engels wrote: Op zich een goede actie, maar ik zie momenteel nog te veel inconsistente wegen (stukje secondary - stukje tertiary - stukje secondary - stukje tertiary of stukje tertiary - stukje unclassified - stukje tertiary - stukje unclassified). Ook zijn er nog wegen die niet worden meegenomen terwijl ze duidelijk unclassified zouden moeten zijn (vermoedelijk omdat iemand ooit het AND:importance_level heeft Dat is inderdaad meestal de reden. Iemand heeft die stukjes al geëdit, en daarom laat ik ze zien zoals ze nu zijn. gesloopt). Ik denk dus dat het stukje bij beetje moet gebeuren, met daarna een correctie-edit (waarvoor ik best een paar handjes wil helpen). We kunnen het per gemeente of provincie doen. Sowieso zijn het 80k+ ways, dus we doen het liever in iets kleinere brokken dan in 2 grote changesets. We kunnen dus beginnen met gebieden waar iemand het resultaat ook direct kan controleren. Echter, uiteindelijk zal toch heel NL gedaan moeten worden, en na een voorzichtig begin moeten we denk ik niet te lang wachten om de rest dan ook gewoon te doen. De inconsistenties die je noemt werken we allemaal dan vanzelf wel weg. Tot nu toe is het echter nog maar een voorstel, met een kaart ter ondersteuning daarvan. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
Andre Engels wrote: 2010/6/21 Cartinus carti...@xs4all.nl: Als je iets baseert op niet vrije data van een ander, dan kun je het naderhand niet zomaar weggeven. Dus dan kost het geld. Dus jij zegt dat de Fietsersbond hun kaarten niet mogen weggeven? Hebben die mooi een kat in de zak gekocht... inderdaad, die conclusie hebben we in het verleden ook al eens getrokken: http://www.mail-archive.com/talk-nl@openstreetmap.org/msg00159.html http://www.mail-archive.com/talk-nl@openstreetmap.org/msg04229.html ook interessant: http://www.mail-archive.com/talk-nl@openstreetmap.org/msg04869.html groet, floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
Goed om te horen Dirk, jullie initiatief met de Fietsersbond klinkt als een simpele en professionele oplossing. En is ook geheel in lijn met de richting die onze overheid wil naar het meer gebruik maken van open source. Succes met de gesprekken. Johan Op 21 juni 2010 10:34 schreef dbuss...@goudappel.nl het volgende: Wij (Goudappel Coffeng) zijn bezig voor Limburg, Noord-Brabant, Zeeland en Twente OSM te verbeteren om hier een fietsrouteplanner op te baseren. Onze opdrachtgevers hebben hier juist voor gekozen omdat de data die wij genereren niet alleen in onze eigen planner blijft maar vanzelf meer nut genereert (van een touristische I-Phone app in Zeeland tot garmin-downloads). In dit kader worden natuurlijk ook de fietsknopennetwerken opnieuw nagelopen. Wij hebben de fietsersbond uitgenodigd hierin met ons samen te werken - onze data dubbel-licensed ook in de fietsersbond planner en hun data via ons naar OSM. De gesprekken hierover lopen nog. Dirk Bussche Disclaimer De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. De afzender sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl 0F365215.gif___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets Knooppuntennetwerken
ce-test, qualified testing bv - Gert Gremmen wrote: Dat nieuwe schema is zeker beter, maar heeft een paar nadelen: -Flink wat meer dom werk Zoals Lennard zegt: Weinig extra werk. -Aan de netwerk relatie kan je niet zien welke knooppunten deelnemen, anders dan de interne node nummers. Inderdaad een probleempje. Het zou een grote hulp zijn als de editor (JOSM) de ref nummers in de relation editor kon weergeven. Dat dat ingewikkeld is blijkt al uit het feit sommige punten in je haaglanden netwerk eigenlijk bij het netwerk middendelfland horen... (zelf ingefietst!) Nou, hier is blijkbaar iets verandert. Ik denk dat het Middendelfland netwerk (ten minste gedeeltelijk) in het Haaglanden netwerk is opgenomen. Alle Middendelfland boorden in Rijswijk zijn door Haaglanden boorden vervangen. Ook zijn er nieuwe knooppunten (bijvooorbeeld 57 en 60) bijgekomen, die de oude routes in twee opknippen. Zal volgend weekeinde even nagaan of de dichtstbijzijnde boorden in gemeente Middendelfland ook zijn vervangen. Om nog maar niet te spreken over de editing problemen als er een stukje wijzigt en je niet alleen de route relatie moet wijzigen, maar ook de grote relatie. Zoals Lennard zegt, geen probleem tenzij knooppunten worden toegevoegd of verwijderd. Het lijkt mij veel slimmer om die grote relatie door een Botje op regelmatig tijdstip samen te stellen uit de nu al getagde informatie. En ja, die redunantie is niet zo erg. Maakt het makkelijker om te weten wat je waar doet. Ook het toevoegen van de begin en end nodes kan automatisch. Misschien kan de laatste versie van JOSM overweg met die multilevel Relaties, maar dan moet er voor mij in elk geval wel een heel goede tutorial/wiki komen. Die relatie editor is zo al ingewikkeld. Zo ingewikkeld is het ook niet. Een relatie aan een ander relatie toevoegen is eigenlijk niet anders dan een node of weg toevoegen. Met de relatie editor geopend de gewenste relatie selecteren en op 'toevoegen' klikken. Ole ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Rivers and streams
Thanks John for the reply. It does look like the data is from about 10 to 15 years ago. Could I use this data instead. https://www.ga.gov.au/products/servlet/controller?event=GEOCAT_DETAILScatno =64459 Markus -Original Message- From: John Smith [mailto:deltafoxtrot...@gmail.com] Sent: Sunday, 20 June 2010 8:54 PM To: Markus Cc: OSM Australian Talk List Subject: Re: [talk-au] Rivers and streams On 20 June 2010 21:05, Markus marku...@bigpond.com wrote: I am interested in adding some of the lakes and creeks in the national parks to OSM. Just to confirm this source to be ok to use. The data doesn't belong to ga.gov.au, they link to psu.edu and on that page it says the data is quite out of date, did you look at the rivers/streams data from data.australia.gov.au? No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 9.0.829 / Virus Database: 271.1.1/2952 - Release Date: 06/21/10 04:06:00 ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Rivers and streams
On 21 June 2010 17:59, Markus marku...@bigpond.com wrote: It does look like the data is from about 10 to 15 years ago. Could I use this data instead. https://www.ga.gov.au/products/servlet/controller?event=GEOCAT_DETAILScatno=64459 I couldn't see where to download it, the files some times come with licenses that differ from cc-by Also the area covered is quite small... N Lat :-27.0W Long :139.5 S Lat :-28.0E Long :141.0 ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Rivers and streams
The data is part of the GIG Dataset - 250K scale Follow this link and choose Topography with Innamincka as an example for the keyword and press show me results. https://www.ga.gov.au/products/servlet/controller?event=DEFINE_PRODUCTS It is small but I am interested in adding the water ways and lakes for the SA National Parks. I plan to do it park by park. Markus. -Original Message- From: John Smith [mailto:deltafoxtrot...@gmail.com] Sent: Monday, 21 June 2010 6:26 PM To: Markus Cc: OSM Australian Talk List Subject: Re: [talk-au] Rivers and streams On 21 June 2010 17:59, Markus marku...@bigpond.com wrote: It does look like the data is from about 10 to 15 years ago. Could I use this data instead. https://www.ga.gov.au/products/servlet/controller?event=GEOCAT_DETAILScatno =64459 I couldn't see where to download it, the files some times come with licenses that differ from cc-by Also the area covered is quite small... N Lat :-27.0W Long :139.5 S Lat :-28.0E Long :141.0 No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 9.0.829 / Virus Database: 271.1.1/2952 - Release Date: 06/21/10 04:06:00 ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Coastline
There seems to be an unintended side effect to this statement: The maritime borders are 12nm out to sea from the coastline. Bass Strait seems to have been given over to international waters according to that statement. There are some weird lines around Vic / Tas and the Bass Strait islands at the moment on zoom level 7 which i assume are linked to this converstation. On Tue, May 25, 2010 at 8:35 PM, John Smith deltafoxtrot...@gmail.comwrote: On 25 May 2010 20:28, Markus marku...@bigpond.com wrote: You still haven't explained how to check the whole coastline is joined with JOSM. You mensioned JOSM has a validation checker that should be used for this kind of thing. Click to display the validation plugin panel or press Alt+Shift+V then click on the validate button, make sure nothing is selected or only the selection with be validated, you could make things a little more specific by first searching for natural=coastline segments. The renders I create for Garmin Mapsource has problems if the coastline isn't joined. So does mapnik, but they cheated to get round most problems by creating a shape file first. The 2000 node limit for polygons is documented to be over come by using a relation. Which was made redundent by creating shape files from the coastline segments before relations existed, although this is probably still a lot more useful. The maritime borders are 12nm out to sea from the coastline. See below link. Yes, but coastlines should be much less nodes otherwise you start hitting problems similar to those in the Philippines... ___ 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] Australian Coastline
On 21 June 2010 22:12, Leon Kernan lker...@gmail.com wrote: There seems to be an unintended side effect to this statement: The maritime borders are 12nm out to sea from the coastline. That is the general case, but in Qld I think it's 12nm from the edge of the barrier reef... Bass Strait seems to have been given over to international waters according to that statement. Are you thinking about maritime borders or the Exclusive Economic Zone (EEZ) which is 200nm from the coastline... There are some weird lines around Vic / Tas and the Bass Strait islands at the moment on zoom level 7 which i assume are linked to this converstation. If you know where they are, feel free to fix them... ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Rivers and streams
On 21 June 2010 19:43, Markus marku...@bigpond.com wrote: The data is part of the GIG Dataset - 250K scale Follow this link and choose Topography with Innamincka as an example for the keyword and press show me results. I can't comment about all datasets, but I downloaded that particular dataset in shape format and there was only shape files so it seems you are allowed to use it if you take the notice on their website into account: Unless otherwise noted, all Geoscience Australia material on this website is licensed under the Creative Commons Attribution 2.5 Australia Licence. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Rivers and streams
On 22 June 2010 05:27, John Smith deltafoxtrot...@gmail.com wrote: Unless otherwise noted, all Geoscience Australia material on this website is licensed under the Creative Commons Attribution 2.5 Australia Licence. You will need to tag at least all ways with: source=Geoscience Australia attribution=Based on Geoscience Australia data I'd also add the main URL of the product (source:url=*), but this isn't mandatory. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Coastline
Are you meaning the horizontal line half way between Vic and Tas in bass straight? If it is it is the state border between the two not the maritime boarder. I am currently tidying the existing maritime boarder to correctly render with mgkmap and mapnik using osm rules for maritime boarders. It doesn't seem to need the baseline I was talking about originally. The line around the coast is the 12nm zone that we now can see. http://www.ga.gov.au/oceans/mc_amb-bndrs.jsp http://wiki.openstreetmap.org/wiki/Proposed_features/Maritime_borders If I have made a mistake interpreting it let me know. Markus _ From: talk-au-boun...@openstreetmap.org [mailto:talk-au-boun...@openstreetmap.org] On Behalf Of Leon Kernan Sent: Monday, 21 June 2010 9:43 PM To: OSM Australian Talk List Subject: Re: [talk-au] Australian Coastline There seems to be an unintended side effect to this statement: The maritime borders are 12nm out to sea from the coastline. Bass Strait seems to have been given over to international waters according to that statement. There are some weird lines around Vic / Tas and the Bass Strait islands at the moment on zoom level 7 which i assume are linked to this converstation. On Tue, May 25, 2010 at 8:35 PM, John Smith deltafoxtrot...@gmail.com wrote: On 25 May 2010 20:28, Markus marku...@bigpond.com wrote: You still haven't explained how to check the whole coastline is joined with JOSM. You mensioned JOSM has a validation checker that should be used for this kind of thing. Click to display the validation plugin panel or press Alt+Shift+V then click on the validate button, make sure nothing is selected or only the selection with be validated, you could make things a little more specific by first searching for natural=coastline segments. The renders I create for Garmin Mapsource has problems if the coastline isn't joined. So does mapnik, but they cheated to get round most problems by creating a shape file first. The 2000 node limit for polygons is documented to be over come by using a relation. Which was made redundent by creating shape files from the coastline segments before relations existed, although this is probably still a lot more useful. The maritime borders are 12nm out to sea from the coastline. See below link. Yes, but coastlines should be much less nodes otherwise you start hitting problems similar to those in the Philippines... ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 9.0.829 / Virus Database: 271.1.1/2954 - Release Date: 06/22/10 04:06:00 ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Rivers and streams
Thanks for that. Regards, Markus -Original Message- From: John Smith [mailto:deltafoxtrot...@gmail.com] Sent: Tuesday, 22 June 2010 5:05 AM To: Markus Cc: OSM Australian Talk List Subject: Re: [talk-au] Rivers and streams On 22 June 2010 05:27, John Smith deltafoxtrot...@gmail.com wrote: Unless otherwise noted, all Geoscience Australia material on this website is licensed under the Creative Commons Attribution 2.5 Australia Licence. You will need to tag at least all ways with: source=Geoscience Australia attribution=Based on Geoscience Australia data I'd also add the main URL of the product (source:url=*), but this isn't mandatory. No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 9.0.829 / Virus Database: 271.1.1/2954 - Release Date: 06/22/10 04:06:00 ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Qld State Controlled Roads data
Recently David Dean asked for some data and he was given access to it with a favourable license (cc-by). This dataset only covers Qld Govt funded roads, this doesn't include local government roads. While there was additional information attached to the data, it was mostly internal references so this was removed, I also simplified all the ways as there was an excessive number of points, it appeared that raw GPS data had been used in some/many places without any kind of simplification applied. I don't know if it was due to the conversion processing or not, but many of the roads don't interconnect properly. Most roads are in segments as various different tags were applied to the sections, think like last survey dates. With that all said, the name/vector data seems very useful for both ways not already in OSM and for fixing up Landsat derived data, the vector data probably isn't that useful for places where Nearmap have coverage. For those interested in this data in OSM format, you can download it from here: http://map-data.bigtincan.com/data/sc_roads_qld.osm.bz2 It's approx 1.5M and if you enable the slippymap plugin with mapnik background image you can use it to see which roads are missing and which just need a few tweaks here and there. I've posted a brief page here about permission: http://wiki.openstreetmap.org/wiki/Australia/Queensland/Department_of_Transport_and_Main_Roads And another here about the data itself: http://wiki.openstreetmap.org/wiki/Australia/Queensland/Department_of_Transport_and_Main_Roads/Import ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-br] Importação dos dados da prefeitura d e Goiânia
Na minha opinião, se os dados da prefeitura são mais corretos*, não tem porque guardar informação antiga, errada ou incompleta. Por outro lado, algo me diz que seria bom guardar esses dados de alguma maneira, caso precisemos consultá-los mais tarde. Eu vejo três possibilidades: 1) Remarcar toda a informação que está agora lá como deprecated (ou algo assim), de maneira que fique invisível no renderer, mas que se alguém tiver interesse ainda pode ser acessada pelo editor. Se ninguém reclamar, depois de um tempo apaga a informação velha. Contra: Vai ficar uma bagunça no editor. 2) Cria um changeset gigante e coloca todos os dados removidos em uma mudança só. Assim fica fácil reverter se houver necessidade. Contra: se houver algum dado que não estiver no que vier da prefeitura, a gente perde. 3) Tentar fazer um merge dos dados... isso requer identificação de quais pontos presentes atualmente coincidem com os pontos do novo dataset. E depois tem que ver o que fazer com os tags... Contra: a menos que alguém tenha um método automágico, fazer um merge vai ser uma quantidade de trabalho incrível. *) Nota: eu me pergunto qual dos datasets é realmente mais correto. Eu já vi diferenças bem feias entre as imagens de satélite e a realidade (baseado em deixar o gps no mesmo lugar um tempão para que a posição estabilizasse, ou seja, ter baixo DOPhttp://en.wikipedia.org/wiki/Dilution_of_precision_(GPS)). Pode ser que os dados da prefeitura sejam os corretos... Att, Ricardo 2010/6/20 Flávio Henrique yoshi...@gmail.com Offset... vou procurar... O Claudomiro tá ocupado nestes dias, então vou tentar me virar por enquanto. Eu iria perguntar sobre os dados já existentes depois, mas já que o assunto foi mencionado agora: realmente os dados a serem importados são completíssimos (tem até os postes da rede elétrica da cidade), então por que não podemos apagar o que existe lá e importar a cidade inteira (não de uma vez, claro)? Grande parte do que está lá fui eu quem inseri e o que existia nem havia ligação com rodovias ou outras vias. Não sei se alguém sabe, mas se eu, utilizando o JOSM, reposicionar a imagem de satélite para que as vias fiquem ok, o JOSM vai adequar as coordenadas das vias ou da imagem? Digo, é uma forma de corrigir? Abraços! Flávio Henrique 2010/6/20 Vitor George vitor.geo...@gmail.com Com certeza deve existir uma opção de offset, talvez o Claudomiro conheça. Outra coisa, no IBGE o Claudomiro importou só em lugar onde não tinha nada mapeado. No caso de Goiânia, eu acho que não dá para fazer assim, porque na imagem que você mandou dá pra ver que os dados a serem importados tem uma qualidade muito melhor. Também não dá pra apagar tudo que tá no osm, então eu acho que vai ter que existe uma parte manual, não sei como, de substituição do que tá no OSM pelo que está nos dados da prefeitura. Ou talvez jogar tudo e aí corrigir de acordo com as imagens de satélite. Vitor 2010/6/19 Flávio Henrique yoshi...@gmail.com Olá pessoal! Depois de várias tentativas e algumas quase-desistências, consegui descobrir o caminho das pedras para começar a importar os dados da Prefeitura de Goiânia para o projeto. Entretanto... (claro, pois sempre há um problema) os dados importados estão deslocados em relação a algumas vias já desenhadas no projeto, bem como ao background do Yahoo Imagery. Vejam no link abaixo um exemplo do que estou falando. O que está em cinza (desabilitado) são os dados importados e os coloridos são dados baixados pelo JOSM do projeto. Preciso resolver isso antes de começar a analisar outros fatores da importação que, com certeza, ainda vai demorar. Link: http://i45.tinypic.com/27xqbf5.png Fazem ideia de como tratar isso? Desde já agradeço ao Claudomiro e ao Vitor George pelos primeiros 'empurrões' sobre o assunto. Grato! Flávio Henrique There are only 10 types of people in the world: Those who understand binary, and those who don't 2010/5/13 Flavio Bello Fialho be...@cnpuv.embrapa.br Provavelmente SAD-69. Manda converter para WGS-84. Flávio Henrique escreveu: Ok. Consegui abrir os arquivos pelo uDig e estão ótimos. Há coisas interessantes que posso trabalhar... Porém, preciso indicar ao uDig qual é o Sistema de Coordenadas que os arquivos utilizam. Como descobrir? Desculpem-me se é uma questão básica, mas estou iniciando... Grato! Flávio Henrique 2010/5/12 Flávio Henrique yoshi...@gmail.com mailto: yoshi...@gmail.com Olá Arlindo! Sim, os arquivos .shp são acompanhados por outros 5 ou 6 extensões (dbf, shx, dbx, etc)... Tentei abrir os .shp pelo Merkaator, mas nada aparece. O ogr2ogr também não gera um .osm que o JOSM consiga abrir... estou meio sem opções. :( Vou tentar a sugestão do Vitor... tentar abri-los em um GIS. Vamos ver no que
Re: [Talk-br] Importação dos dados da prefeitura de Goiânia
Eu prefiro a opção do deprecated, pois se alguém ver um erro no mapa e quiser editar, vai ter a chance de ver no editor os dados que foram apagados ou só os importados. No josm também é possível usar filtros por tags, e aí dá pra fazer aparecer só os dados antigos ou os novos. 2010/6/21 Ricardo Padilha ricardospadi...@gmail.com Na minha opinião, se os dados da prefeitura são mais corretos*, não tem porque guardar informação antiga, errada ou incompleta. Por outro lado, algo me diz que seria bom guardar esses dados de alguma maneira, caso precisemos consultá-los mais tarde. Eu vejo três possibilidades: 1) Remarcar toda a informação que está agora lá como deprecated (ou algo assim), de maneira que fique invisível no renderer, mas que se alguém tiver interesse ainda pode ser acessada pelo editor. Se ninguém reclamar, depois de um tempo apaga a informação velha. Contra: Vai ficar uma bagunça no editor. 2) Cria um changeset gigante e coloca todos os dados removidos em uma mudança só. Assim fica fácil reverter se houver necessidade. Contra: se houver algum dado que não estiver no que vier da prefeitura, a gente perde. 3) Tentar fazer um merge dos dados... isso requer identificação de quais pontos presentes atualmente coincidem com os pontos do novo dataset. E depois tem que ver o que fazer com os tags... Contra: a menos que alguém tenha um método automágico, fazer um merge vai ser uma quantidade de trabalho incrível. *) Nota: eu me pergunto qual dos datasets é realmente mais correto. Eu já vi diferenças bem feias entre as imagens de satélite e a realidade (baseado em deixar o gps no mesmo lugar um tempão para que a posição estabilizasse, ou seja, ter baixo DOPhttp://en.wikipedia.org/wiki/Dilution_of_precision_%28GPS%29). Pode ser que os dados da prefeitura sejam os corretos... Att, Ricardo 2010/6/20 Flávio Henrique yoshi...@gmail.com Offset... vou procurar... O Claudomiro tá ocupado nestes dias, então vou tentar me virar por enquanto. Eu iria perguntar sobre os dados já existentes depois, mas já que o assunto foi mencionado agora: realmente os dados a serem importados são completíssimos (tem até os postes da rede elétrica da cidade), então por que não podemos apagar o que existe lá e importar a cidade inteira (não de uma vez, claro)? Grande parte do que está lá fui eu quem inseri e o que existia nem havia ligação com rodovias ou outras vias. Não sei se alguém sabe, mas se eu, utilizando o JOSM, reposicionar a imagem de satélite para que as vias fiquem ok, o JOSM vai adequar as coordenadas das vias ou da imagem? Digo, é uma forma de corrigir? Abraços! Flávio Henrique 2010/6/20 Vitor George vitor.geo...@gmail.com Com certeza deve existir uma opção de offset, talvez o Claudomiro conheça. Outra coisa, no IBGE o Claudomiro importou só em lugar onde não tinha nada mapeado. No caso de Goiânia, eu acho que não dá para fazer assim, porque na imagem que você mandou dá pra ver que os dados a serem importados tem uma qualidade muito melhor. Também não dá pra apagar tudo que tá no osm, então eu acho que vai ter que existe uma parte manual, não sei como, de substituição do que tá no OSM pelo que está nos dados da prefeitura. Ou talvez jogar tudo e aí corrigir de acordo com as imagens de satélite. Vitor 2010/6/19 Flávio Henrique yoshi...@gmail.com Olá pessoal! Depois de várias tentativas e algumas quase-desistências, consegui descobrir o caminho das pedras para começar a importar os dados da Prefeitura de Goiânia para o projeto. Entretanto... (claro, pois sempre há um problema) os dados importados estão deslocados em relação a algumas vias já desenhadas no projeto, bem como ao background do Yahoo Imagery. Vejam no link abaixo um exemplo do que estou falando. O que está em cinza (desabilitado) são os dados importados e os coloridos são dados baixados pelo JOSM do projeto. Preciso resolver isso antes de começar a analisar outros fatores da importação que, com certeza, ainda vai demorar. Link: http://i45.tinypic.com/27xqbf5.png Fazem ideia de como tratar isso? Desde já agradeço ao Claudomiro e ao Vitor George pelos primeiros 'empurrões' sobre o assunto. Grato! Flávio Henrique There are only 10 types of people in the world: Those who understand binary, and those who don't 2010/5/13 Flavio Bello Fialho be...@cnpuv.embrapa.br Provavelmente SAD-69. Manda converter para WGS-84. Flávio Henrique escreveu: Ok. Consegui abrir os arquivos pelo uDig e estão ótimos. Há coisas interessantes que posso trabalhar... Porém, preciso indicar ao uDig qual é o Sistema de Coordenadas que os arquivos utilizam. Como descobrir? Desculpem-me se é uma questão básica, mas estou iniciando... Grato! Flávio Henrique 2010/5/12 Flávio Henrique yoshi...@gmail.com mailto: yoshi...@gmail.com Olá
Re: [Talk-br] Mapping Party no Rio de Janeiro
Para mim não dá. 1 semana antes de acabar o período é impossível! Aquele abraço, Pedro Marins. Em 19 de junho de 2010 18:00, Henrique de Andrade henriquedeandr...@gmail.com escreveu: Eu pilho e voto em Paquetá =) -- Henrique Rabelo de Andrade 2010/6/18 Arlindo Pereira openstreet...@arlindopereira.com E então meu povo carioca, vamos fazer nossa primeira Mapping Party? Acho que já temos quórum para mapearmos juntos. Copiei alguns amigos (em CC, espero que vocês não se importem). Como comentei em pvt com vocês, tenho algumas sugestões de lugares, como Paquetá - http://osm.org/go/OVdmgRix-- - e lugares como o zoológico, jardim botânico e afins, onde dá para fazer um micromapping legal e já sair com algo completo no mesmo dia, ou então um bairro à nossa escolha. A minha ideia é fazer uma coisa bem light, não nerd, passeio mesmo, utilizando GPS e Walking Papers após uma meia hora de conversa sobre o projeto e o objetivo do encontro. Algo que nossas namoradas iriam ;) Outra possibilidade interessante que imagino seria mapear a Uruguaiana (para os não-cariocas, região de comércio popular aqui no Rio). Ou uma trilha (leve). Em suma, algo que você não encontre nos mapas tradicionais. O que vocês acham? Sugestão de datas? Sugiro 10 e 11 de julho, para o pessoal de fora do Rio que queira chegar poder se programar. []s ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Como ajudar Alagoas?
Criei uma página no wiki. Estou buscando imagens do CBERS para ver se conseguimos mapear as cidades afetadas. Criei o canal osm-br para gente conversar mais fácil. http://wiki.openstreetmap.org/wiki/Pt-br:2010_Alagoas_Flooding irc://irc.oftc.net/osm-br Vitor ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação dos dados da prefeitura d e Goiânia
Ok... projeção corrigida! Obrigado Arlindo pela dica do proj4 string. Apenas alterei para +zone=22 e tudo ficou alinhado. Se eu conseguir resolver um problema por dia, quem sabe até o final do ano eu consiga importar algo? :p Agora estou apanhando ao tentar unir as vias. É que as vias a serem importadas são divididas em segmentos (vários por via). O que vocês utilizaram? Estou tentando com o script shp-to-osm.jar mas ele não está aceitando a projeção informada. Tá complicado! Qualquer dica nesse sentido será muito bem vinda! Grato! Flávio Henrique 2010/6/21 Vitor George vitor.geo...@gmail.com Eu prefiro a opção do deprecated, pois se alguém ver um erro no mapa e quiser editar, vai ter a chance de ver no editor os dados que foram apagados ou só os importados. No josm também é possível usar filtros por tags, e aí dá pra fazer aparecer só os dados antigos ou os novos. 2010/6/21 Ricardo Padilha ricardospadi...@gmail.com Na minha opinião, se os dados da prefeitura são mais corretos*, não tem porque guardar informação antiga, errada ou incompleta. Por outro lado, algo me diz que seria bom guardar esses dados de alguma maneira, caso precisemos consultá-los mais tarde. Eu vejo três possibilidades: 1) Remarcar toda a informação que está agora lá como deprecated (ou algo assim), de maneira que fique invisível no renderer, mas que se alguém tiver interesse ainda pode ser acessada pelo editor. Se ninguém reclamar, depois de um tempo apaga a informação velha. Contra: Vai ficar uma bagunça no editor. 2) Cria um changeset gigante e coloca todos os dados removidos em uma mudança só. Assim fica fácil reverter se houver necessidade. Contra: se houver algum dado que não estiver no que vier da prefeitura, a gente perde. 3) Tentar fazer um merge dos dados... isso requer identificação de quais pontos presentes atualmente coincidem com os pontos do novo dataset. E depois tem que ver o que fazer com os tags... Contra: a menos que alguém tenha um método automágico, fazer um merge vai ser uma quantidade de trabalho incrível. *) Nota: eu me pergunto qual dos datasets é realmente mais correto. Eu já vi diferenças bem feias entre as imagens de satélite e a realidade (baseado em deixar o gps no mesmo lugar um tempão para que a posição estabilizasse, ou seja, ter baixo DOPhttp://en.wikipedia.org/wiki/Dilution_of_precision_%28GPS%29). Pode ser que os dados da prefeitura sejam os corretos... Att, Ricardo 2010/6/20 Flávio Henrique yoshi...@gmail.com Offset... vou procurar... O Claudomiro tá ocupado nestes dias, então vou tentar me virar por enquanto. Eu iria perguntar sobre os dados já existentes depois, mas já que o assunto foi mencionado agora: realmente os dados a serem importados são completíssimos (tem até os postes da rede elétrica da cidade), então por que não podemos apagar o que existe lá e importar a cidade inteira (não de uma vez, claro)? Grande parte do que está lá fui eu quem inseri e o que existia nem havia ligação com rodovias ou outras vias. Não sei se alguém sabe, mas se eu, utilizando o JOSM, reposicionar a imagem de satélite para que as vias fiquem ok, o JOSM vai adequar as coordenadas das vias ou da imagem? Digo, é uma forma de corrigir? Abraços! Flávio Henrique 2010/6/20 Vitor George vitor.geo...@gmail.com Com certeza deve existir uma opção de offset, talvez o Claudomiro conheça. Outra coisa, no IBGE o Claudomiro importou só em lugar onde não tinha nada mapeado. No caso de Goiânia, eu acho que não dá para fazer assim, porque na imagem que você mandou dá pra ver que os dados a serem importados tem uma qualidade muito melhor. Também não dá pra apagar tudo que tá no osm, então eu acho que vai ter que existe uma parte manual, não sei como, de substituição do que tá no OSM pelo que está nos dados da prefeitura. Ou talvez jogar tudo e aí corrigir de acordo com as imagens de satélite. Vitor 2010/6/19 Flávio Henrique yoshi...@gmail.com Olá pessoal! Depois de várias tentativas e algumas quase-desistências, consegui descobrir o caminho das pedras para começar a importar os dados da Prefeitura de Goiânia para o projeto. Entretanto... (claro, pois sempre há um problema) os dados importados estão deslocados em relação a algumas vias já desenhadas no projeto, bem como ao background do Yahoo Imagery. Vejam no link abaixo um exemplo do que estou falando. O que está em cinza (desabilitado) são os dados importados e os coloridos são dados baixados pelo JOSM do projeto. Preciso resolver isso antes de começar a analisar outros fatores da importação que, com certeza, ainda vai demorar. Link: http://i45.tinypic.com/27xqbf5.png Fazem ideia de como tratar isso? Desde já agradeço ao Claudomiro e ao Vitor George pelos primeiros 'empurrões' sobre o assunto. Grato! Flávio Henrique There are only 10 types of people in the world: Those who understand binary, and those
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
Am 21.06.2010 02:50, schrieb Thomas Ineichen: Hallo Ulf Z.B. Bei französischen Gebirgspässen kommt es durchaus vor, das es eine französische Seite zum Pass gibt, dieser Pass aber in der deutschen WP nur im Fließtext der naheliegenden Ortschaft kurz erwähnt wird. Passhöhe und Ortschaft liegen aber dann schonmal mehrere Kilometer voneinander entfernt. Dann würde ich aber auch keinen deutschen Wiki-Link auf das Dorf setzen. MMn sollte man auf Wikipedia nur verlinken, wenn es in der Sprache auch einen eigenen Artikel gibt. Oder sehe ich das zu eng? Ist halt so ein Grenzfall, aber man sollte auch dran denken: nicht jeder kann französisch. Ich würde das lieber dem Mapper überlassen, ob sich da ein Link lohnt. Wenn da nur der Name erwähnt wird eher nicht, aber es stehen da auch mal ein paar Sätze. Was machen wir dann z.B. bei listenartigen Artikeln, die gleich eine ganze Reihe von Koordinaten enthalten: http://de.wikipedia.org/wiki/Erzgebirgsp%C3%A4sse oder schlimmer: http://de.wikipedia.org/wiki/Liste_der_Gebirgsp%C3%A4sse_in_Frankreich Zumindest bei den Erzgebirgspässen gibt es zwar keinen eigenen Artikel, aber in dem Sammelartikel stehen genug Informationen über die einzelnen Pässe, das sich ein Link aus meiner Sicht lohnt. Ich habe schon einige Zeit mit dem Vergleich Wikipedia in verschiedenen Sprachen vs. OSM zugebracht. Auf den ersten Blick sieht das noch ganz passend 1:1 aus so wie hier von einigen erwähnt. Aber bei genauerer Betrachtung gibt es da eine ganze Reihe an Sonderfällen, Überschneidungen etc. In vielen Fällen wird man mit den Interwikilinks gut hinkommen. Aber davon auszugehen, daß immer ein Link reicht halte ich für zu kurz gedacht ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einzelner Marker auf Karte per Link
Hallo Sebastian. Am Freitag 18 Juni 2010, 22:27:49 schrieb Sebastian Hohmann: ich war immer etwas genervt von der osm.org Methode einen Marker auf die Karte zu bekommen (Karte auf den gewünschten Punkt zentrieren, URL Parameter manuell ändern), also habe ich mich mal daran gemacht, eine etwas benutzerfreundliche Methode anzubieten. Das tut Not, ja. :) Ist eigentlich keine große Sache, aber vielleicht nützt es ja jemandem. Manchmal möchte man ja einfach nur schnell etwas auf der Karte markieren und jemandem anders zeigen. http://m.osmtools.de (m wie map oder marker) Unten links kann man einen Marker setzen und hat auch eine kurze Hilfe. Es gibt mehrere Permalinks zur Auswahl, je nachdem was man gerade braucht. Und vielleicht hat ja auch noch jemand Verbesserungsvorschläge. Zwei Vorschläge: 1. Lasse neben der Karte unten oder an einer Seite etwas Rand und lege die Links (Marker setzen, Permalinks) dort hin. Dann sieht man die sofort. 2. Ist das Setzen vielfältig bunter Marker wirklich sinnvoll? Immerhin gibt es weiterhin nur die Möglichkeit, *einen* Marker zu setzen. Dann braucht man ja gar keine unterschiedlichen Symbole um diese zu unterschieden... Ich habe gehofft, es würde ein Frontend, mit dem man osm.org-URLs mit dem dortigen Marker setzen kann. Also einfach Permalinks zu osm.org/?mlon... Denn durch das jetzige Welcher Marker und die Auswahl einer schieren Menge an Permalinks ist der wirklich einfache Anwender ja schon wieder überfordert. Meine Zielsetzung an eine derartige Seite wäre ungefähr folgendes: Ich kommuniziere mit jemandem der Ortskenntnis hat wo ich sie nicht habe. Dann bitte ich ihn, mir den genauen Standort von Bäckerei Maier mitzuteilen. Ich sende ihm eine Adresse mit dem ungefähren Bildausschnitt und er klickt lediglich auf die Karte (siehe openstreetbugs für diese Benutzerführung, es funktioniert!) und sieht dann idealerweise in einem Text-Eingabefeld eine Adresse die er kopieren und mir senden kann. Gruß, Bernd -- Ein Optimist lacht, um zu vergessen. Ein Pessimist vergißt zu lachen. 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] Fahrrad-Access-Map
Am Montag 21 Juni 2010, 00:01:39 schrieb Friedhelm Schmidt: ( Bernd, sag doch auch mal was :-) ) Sorry, war über's Wochenende verreist. ;-)) Die Debatte ist mittlerweile lustig zu lesen aber IMHO nicht zielführend. Ich finde es sehr schade, anfangs war es Aufgabe der Tags auf verblüffend einfache Weise eine Karte zu machen. Vor einiger Zeit war es so: Ob man auf einem Weg nicht radfahren *kann* oder nicht radfahren *darf*, ist in der Praxis eigentlich egal. Man fährt da nicht und es darf ein bicycle=no dran stehen. Umgekehrt genau so. Wenn da ein durchschnittliches Fahrrad (Rennräder fahren sowieso immer auf der Straße, MTBs überall) fahren kann und fahren darf, dann ist das ein bicycle=yes. Das war einfach, nicht 100% konsistent, nicht grade das Vorzeigebeispiel deutscher Gründlichkeit aber es hat funktioniert. Schöne gerenderte Karten ergeben und das Routing ging da auch schon. Jetzt kommen vermehrt Leute auf den Trichter, die Realität zu erfassen und sagen, die Intention und das Denken des Mappers hat mit Realität nichts zu tun und ist auszuschalten. Der Mapper soll bitte alle Quantenteilchen der Umgebung mappen und man muss dann später als Nutzer daraus ableiten ob man da fahrradfahren will oder nicht. Das macht das Mappen für mich langweilig und bringt mir keinen Mehrwert. Da es (erwartungsgemäß) zu viele Leute nicht verstehen, haben wir jetzt viele Wege die teilkorrekt aber eigentlich doch nutzlos getagged sind. Leider gibt es halt auch vermehrt Leute, die jedes neue Tag auf der OSM- Hauptkarte, mittlerweile auch im Mapnik-Stil, sehen wollen, was zumindest bei mir hier dazu führt, dass die OSM-Karte für einfache Lagekarten und Wegbeschreibungen nicht mehr taugt, weil an jeder Ecke ein schwarz gestrichelter Trampelpfad abzweigt und wir ein dichtes Netz an eigentlich nicht existierenden aber ulkig verlaufenden Pfaden haben. Und mal ehrlich: Für den die Homepage des Gemüsezüchtervereins rendere ich keinen eigenen Kartenstil und zahle auch niemanden dafür einen solchen zu erstellen. Gruß, Bernd -- Die Gehirnwäsche gilt allenthalben als fürchterlich und schrecklich. Es gibt aber Gehirne, denen eine Wäsche ganz gut täte. - Johannes Gross (dt. Publizist 1932) 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] Einzelner Marker auf Karte per Link
Hallo Bernd, Ich kommuniziere mit jemandem der Ortskenntnis hat wo ich sie nicht habe. Dann bitte ich ihn, mir den genauen Standort von Bäckerei Maier mitzuteilen. Das deckt den projektinternen Arbeitsablauf gut ab. Das Werkzeug könnte aber auch /für alle Anwender/ nutzlich sein: Link erzeugen für Ortsbeschreibung/Anfahrtsskizze. Und da finde ich es nett, zwischen Raute, Kreis, Pin wählen zu können. Aber Du hast recht: für Anwender würde der Permalink mit Karte, Kartenmittelpunkt, Markerposition, Markertyp meist reichen. Text-Eingabefeld für eine Adresse Das fände ich eine sehr schöne Erweiterung! Bekommt man denn einen PopUp-Text in die URL? (und automatisch auf der Karte angezeigt?) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Adressreferenzierte Objekte importieren
Liebe OSMer, Ist es möglich, Objekte die nicht georeferenziert sind, aber als Liste mit vollständiger Adresse vorliegen, als POI zu importieren? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
Hallo Thomas, - jede Kirche hat ihre eigene, deutsche Wiki-Seite Hier finde ich einen WP-Link hilfreich. - vier Kirchen haben eine englische Wiki-Seite, die restlichen acht werden nur auf der Übersichtsseite erwähnt. Hier fände ich einen WP-Link unzweckmässig. Besser den Sammelartikel zerlegen und erst dann verlinken. Vielleicht könnte der Artikel Zürich in z=10 verlinkt sein, und dann könnte man in WP über die internen Links und Kategorien weiterblättern. Auf einen Spezialkarte Kirchen der Schweiz könnte man die einzelnen Kirchen z.B. ab z=14 verlinken. Aber es soll keinen Link die Kirchen von Zürich geben. Auf der Standardkarte funktioniert eine sinnvolle Verlinkung sowieso nur mit einem Kategorien-Baum als ein/ausschaltbarer Layer. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einzelner Marker auf Karte per Link
Am 18.06.2010 22:27, schrieb Sebastian Hohmann: Hallo, ich war immer etwas genervt von der osm.org Methode einen Marker auf die Karte zu bekommen (Karte auf den gewünschten Punkt zentrieren, URL Parameter manuell ändern), also habe ich mich mal daran gemacht, eine etwas benutzerfreundliche Methode anzubieten. Ist eigentlich keine große Sache, aber vielleicht nützt es ja jemandem. Manchmal möchte man ja einfach nur schnell etwas auf der Karte markieren und jemandem anders zeigen. http://m.osmtools.de (m wie map oder marker) Unten links kann man einen Marker setzen und hat auch eine kurze Hilfe. Es gibt mehrere Permalinks zur Auswahl, je nachdem was man gerade braucht. Und vielleicht hat ja auch noch jemand Verbesserungsvorschläge. Gruß Moin ! das Tool ist wirklick klasse. Wenn das nicht viel ist wäre es nicht effektiver dieses Tool auf einem der offiziellen Server zu deponieren. Sebastian bitte nicht falsch verstehen - aber solche langfristigen Möglichkeiten würde ich lieber personen-unabhängig ansiedeln. gruß jan .-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
Markus schrieb: Hier fände ich einen WP-Link unzweckmässig. Besser den Sammelartikel zerlegen und erst dann verlinken. Das kannst du von einem Mapper aber nicht erwarten - der will seine Daten in die DB bekommen und nicht erst noch einen WP-Account erstellen müssen um dort dann Texte zu bearbeiten. Lg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressreferenzierte Objekte importieren
Am 21.06.2010 09:07, Markus: Liebe OSMer, Ist es möglich, Objekte die nicht georeferenziert sind, aber als Liste mit vollständiger Adresse vorliegen, als POI zu importieren? Gruss, Markus Wenn die Punkte noch nicht in OpenStreetMap vorhanden sind ist davon auszugehen, dass auch deren genaue Adressinformationen noch nicht vorhanden sind. Eine Georeferenzierung würde also auf einer Approximierung/Interpolation aus vorhandenen Adressdaten aufbauen. Wenn du einen entsprechenden FIXME: Bitte genaue Position überprüfen dranbaust wäre das sicher möglich. Genauso wichtig ist aber vor dem Import zu prüfen, ob die Informationen bereits in der Datenbank vorhanden sind. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
es gibt z.B. auch den Fall, dass ein Platz einen eigenen Artikel hat in einer Sprache und in der anderen im Artikel über den Architekten behandelt wird, oder dass ein Brunnen einmal einen eigenen Artikel hat, in einer anderen Sprache aber die Skulptur des Brunnens (ggf. wieder in einem Sammelartikel). Solche Beispiele gibt es viele, es ist eine Tatsache, dass nicht jeder Artikel 1:1 gematch werden kann, und daher sind mehrere Links (teilweise vielleicht sogar in derselben Sprache) oft durchaus sinnvoll. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
- Ursprüngliche Mitteilung - Am Montag 21 Juni 2010, 00:51:06 schrieb aighes: Ein allgemeiner Tag, der spezialisiert wird ist deutlich aussagekräftiger als ein spezialtagg, den jeder so auslegt, wie er ihn braucht. Das ist ein gelebtes OSM Problem.. Wenn man nicht in der Lage ist verbindlich Dinge zu regeln gibt es Kuddelmuddel.. Aber andererseits leben ja auch wieder Einige davon, aus dem Kuddelmuddl wieder etwas sinnvolles zu machen.. Und diese werden eher immer wieder ein bißchen zur Freiheit aufrufen.. Wir kratzen immer wieder an der Oberfläche, das schafft die eigentlichen Probleme nicht aus der Welt. ~ +1 Durch eine nähere Beschreibung wird der Weg eindeutiger und es lassen sich sinnvolle Schlüsse ziehen. Bspw. wie die Oberfläche ist oder wie breit der Weg ist, wer da alles lang darf uvm. +1 Gruß Sven___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
Am 20. Juni 2010 21:36 schrieb Joerg Fischer osm2...@jfis.de: Ich bin vielleicht aus den Erfahrungen meiner Ecke etwas angenervt. Ich habe hier mehr oder weniger flächendeckend alle Radwege erfasst, und weil das highway=cycleway dranhängt nicht noch zusätzlich bicycle=designated benutzt, weil das implizit am highway hing. Dann kamen ein paar Leute daher und machten aus allen =cycleway ein =path, _ohne_ ein bicycle=designated zu ergänzen, und schon sahen alle Wege, die vorher optisch sauber getrennt dargestellt wurden, wie ein Trampelpfad aus. Und es gingen richtig viel Informationen verloren, weil natürlich auch alle =footway angepackt und zu =path umgetaggt wurden. :-/ Das ist natürlich ein ziemlich hirnloser edit, den der Mitmapper da fabriziert hat... Andererseits kam die Position, daß highway=cycleway als Abkürzung für highway=path, bicycle=designated zu sehen ist, auch erst mit dem highway=path auf, was alle vorher nach anderen Kriterien(hier kann man gut...) eingetragenen cycleways nicht berücksichtigt(wie auch bei den footways). Daher finde ich die implikation cycleway=designated problematisch - es gibt auch noch einen großen Teil an Mappern, die cycleway so taggen (nach Eignung/Nutzung). Path kann diese Situation ebenso gut darstellen, wenn nicht sogar besser (kombinierte Wege). Nein. Ok, das überzeugt mich. Wo versagt path hier? Mißverständis: path ist nicht _besser_. Es gehen günstigstenfalls keine Informationen _verloren_, wie es im oben beschriebenen Beispiel passiert ist. Für mich wird die Klarheit gewonnen, daß alle Eigenschaften, die nicht getaggt sind auch nicht bekannt sind. ein fehlendes surface=* heißt bei path also nicht es ist die Oberfläche anzunehmen, die die meisten Mapper als Standard für path ansehen (so wie die meisten durch cycleway eine befestigte Oberfläche als gegeben ansehen), sondern, daß es schlicht noch fehlt. Auf die Implikation von bicycle=designated kann man sich bei cycleway ja leider auch nicht verlassen. Daher ist es mir dann lieber, bewußt auf implikation zu verzichten, die mir bekannten Fakten einzutragen und durch highway=path zu zeigen, daß ich nichts implizieren will, außer, daß es ein untergeordneter Weg ist. (Notiz: ich bin *nicht* für blindes umtaggen) Wie handhabst Du das dann? Ich mache das eigentlich nur dann, wenn cycleway oder footway entweder *wirklich* falsch sind (z.B. ein reiner Fußweg oder Trampelpfad, der als cycleway gemappt ist) oder ich sowieso eine inhaltliche Ergänzung hinzufügen muß (wenn bei ausgeschilderten Wegen kein *=designated vorhanden ist). Oder halt, wenn wieder jemand rumgeht und von mir mit path und *=designated eingetragene Wege in cycleway umändert - idealerweise noch unter löschung der *=designated-tags. ;-) Damit die information, was nun vor Ort ist, besser überleben kann, tagge ich meist noch eine notiz wie note=fuß und radweg / note=reiner radweg dazu - vielleicht sollte ich das mal auf traffic_sign=* umstellen. Wie gesagt: Wenn der Umtagger bei der Aktion das, was vorher im highway steckte, jetzt nach =designated verlagert hat er zumindest mal keinen Schaden angerichtet. Er hat aber auch keine zusätzlichen, irgendwie nützlichen Informationen hinterlegt. Da bin ich dann für never change a running system. Inzwischen benutzen so viele Anwendungen OSM-Daten, das ich mit Umdefinitionen von globalen, bewährten Tags gern vorsichtiger wäre. Wie gesagt, ich halte die implikation von *=designated im highway nicht für stabil - ein explizites taggen sagt dagegen aus, daß tatsächlich genau das gemeint ist. Was war so schlimm daran? Jetzt ist der breite footway, dessen Eigenschaften man hätte ebenfalls durch smoothness usw. beschreiben können, durch den _noch_ breiteren path ersetzt worden, denn der soll jetzt zusätzlich zu allen footway auch noch die cycleway ersetzen. ;-) Das schlimme war, daß die Gesamtbreite sich aus vielen Einzelnen Interpretationen zusammensetzt(e), die allesamt doch recht eng waren. Und als Auswerter frage ich mich dann, in welcher Ecke des Spektrums der Mitmapper seinen footway gerade sah. ;-) Ups. Jetzt wirds interessant! (Ich benutze bisher die AIO-Garminkarte von Christoph.) Die hatte ich auch und von dort habe ich mir auch teilweise die Umsetzung der maxspeed-Werte in garmin-road_speed-Klassen abgeguckt. Ich kenne die Anleitung wie die AIO-Karte entsteht, solche Eigenschaften sind dort etwas unterdokumentiert wie mir scheint. Da habe ich ganz klar ein Defizit, ich wußte nicht dass das geht. Bisher sagten alle, es gäbe diese IIRC 13 routingfähigen Garmintypen und da müsse man alles hinein pressen. Das habe ich so hingenommen. Ja, das stimmt auch(etwa) - aber jedes Stück Weg lässt sich noch mit den Eigenschaften Verboten für $Fahrzeugklasse, Geschwindigkeit(road_speed), Netzhierarchie/Routinggewicht(naja, es heißt road_class und drückt aus, wie stark das Gerät einen Weg bevorzugen soll), unbefestigt, Kostenpflichtig sowie (benutze ich nicht, weiß
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
Am 21. Juni 2010 09:50 schrieb Peter Körner osm-li...@mazdermind.de: Markus schrieb: Hier fände ich einen WP-Link unzweckmässig. Besser den Sammelartikel zerlegen und erst dann verlinken. Das kannst du von einem Mapper aber nicht erwarten - der will seine Daten in die DB bekommen und nicht erst noch einen WP-Account erstellen müssen um dort dann Texte zu bearbeiten. bei WP kann man Artikel bearbeiten ohne einen Account zu haben, aber es erfordert zugegebenermaßen trotzdem etwas Einarbeitung und Recherche, gerade wenn man Artikel zerlegen will, oder Weiterleitungen einrichten, von daher im Prinzip +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
Am 21. Juni 2010 08:48 schrieb Bernd Wurst be...@bwurst.org: Leider gibt es halt auch vermehrt Leute, die jedes neue Tag auf der OSM- Hauptkarte, mittlerweile auch im Mapnik-Stil, sehen wollen, was zumindest bei mir hier dazu führt, dass die OSM-Karte für einfache Lagekarten und Wegbeschreibungen nicht mehr taugt, weil an jeder Ecke ein schwarz gestrichelter Trampelpfad abzweigt und wir ein dichtes Netz an eigentlich nicht existierenden aber ulkig verlaufenden Pfaden haben. ich finde diese Trampelpfade eine Stärke von OSM, wobei sie natürlich von echten d.h. angelegten Wegen zu unterscheiden sein sollten (und evtl. erst in den ganz großen Zoomstufen auftauchen sollten). Ich nutze dafür z.B. zusätzlich informal=yes, so dass die Unterscheidung datentechnisch klar sein sollte. Und mal ehrlich: Für den die Homepage des Gemüsezüchtervereins rendere ich keinen eigenen Kartenstil und zahle auch niemanden dafür einen solchen zu erstellen. was ja gerade dafür spricht, dass die auch einen brauchbaren allgemeinen Stil verwenden können, oder? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
Am 21. Juni 2010 01:48 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: Pro Layer wird nur ausgewertet, was im entsprechenden Key steht; es gibt keine Vererbung 'von oben' und highway=* wird nicht beachtet. Daher bitte nicht alle Wege, wo man Fahrrad fahren kann mit bicycle=yes taggen, nur damit sie im entsprechenden Layer grün leuchten. :) verstehe ich nicht: ist bicycle=yes nicht extra dafür gedacht, alle Wege wo man fahrradfahren kann zu taggen? Was empfiehlst Du für ein Tagging für Wege, wo man fahrradfahren kann? Abgesehen davon: wie taggen für keinen (speziellen) Renderer Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
Hallo Martin, Am 21. Juni 2010 01:48 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: Pro Layer wird nur ausgewertet, was im entsprechenden Key steht; es gibt keine Vererbung 'von oben' und highway=* wird nicht beachtet. Daher bitte nicht alle Wege, wo man Fahrrad fahren kann mit bicycle=yes taggen, nur damit sie im entsprechenden Layer grün leuchten. :) verstehe ich nicht: ist bicycle=yes nicht extra dafür gedacht, alle Wege wo man fahrradfahren kann zu taggen? Doch, aber trotzdem ist es unnötig, an jeden highway=residential ein bicycle=yes dranzuhängen. Ich hätte oben vielleicht 'Strassen' anstatt 'Wege' schreiben sollen. Was empfiehlst Du für ein Tagging für Wege, wo man fahrradfahren kann? smoothnes=* und surface=* :- Abgesehen davon: wie taggen für keinen (speziellen) Renderer Genau davon rate ich ja auch ab! Trotzdem beeinflussen Renderer (und Editoren) unser Tagging-Verhalten sehr stark. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Metrorad Ruhr und OSM
Hiermit dokumentiere ich meine Kontaktaufnahme zu Nextbike / Metrorad Ruhr (www.metrorad.de): Sehr geehrter Herr Kaluper! Hallo Nextbike! Ich freue mich auf Metrorad Ruhr! Sie benutzen für Ihre Standortkarte Openstreetmap. Das freut uns, denn es macht uns bekannter und zeigt Wertschätzung für unsere Arbeit, die wir meist unbezahlt in unserer Freizeit geleistet haben. Dass Sie dafür die Google-API benutzen ist nicht schön, aber erstmal verständlich. Besonders unglücklich (aber wie ich weiß nicht einfach vermeidbar) ist der Link Nutzungsbedingungen neben den Hinweisen auf OSM, der aber zu Google führt. Haben Sie über Alternativen (z.B. Openlayers) nachgedacht? Ich nehme an, wenn wir Ihnen eine gangbare Alternative nennen, sind sie dafür offen?! Wo kommen Ihre Tiles (die Grafikkacheln der OSM-Karte) her? Falls direkt vom OSM-Server sollten Sie bei einer stärkeren Nutzung darüber nachdenken, selbst Tiles zu hosten. Ggf. werden andere Aktive von OSM sie dazu ansprechen. Ich bin selbst kein Experte auf diesem Gebiet. Wenn Sie technische Unterstützung benötigen, kann ich Ihnen z.B. die Experten der Geofabrik empfehlen (www.geofabrik.de) oder andere OSM-Aktive die neben ihrer kommerziellen Arbeit der Community etwas zurückgeben. Nicht zuletzt möchte ich Sie fragen, ob Sie sich vorstellen können, kostenlos für OSM zu werben. Viele Firmennutzer von OSM nutzen Ihre Möglichkeiten - ohne dass sie dazu verpflichtet wären - um OSM zu danken. Bei Ihnen wäre das die Bereitstellung nicht verkaufter Werbeflächen oder ein kleiner Aufkleber auf den Rädern oder oder... Der Fantasie sind keine Grenzen gesetzt. Auch ein Stadtplan auf den Rädern oder an den Stationen wäre denkbar... Einen hätte ich noch: Könnten Sie sich vorstellen eine Datenschnittstelle (API) freizugeben, über die wir automatisiert die aktuelle Verfügbarkeit an den Metroradstationen abfragen könnten? Dann könnten auch wir von OSM unsere Karten mit diesen Infos anreichern. Alternativ oder übergangsweise würde auch ein Direktlink für jede Metroradstation helfen (z.B. www.metrorad.de/stationsnummer) Ich bedanke mich schon jetzt für eine Antwort bzw. mehrere Antworten Ihrer jeweiligen Experten zu den einzelnen Themen. Mit vielen Grüßen aus Essen Rotbarsch von der OSM-Community Essen Dieses Schreiben geht in Kopie auch an die deutsche Mailingliste und die Essener Mailingliste sowie die Ruhrgebietsmailingliste von OSM. -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
Am 21. Juni 2010 00:01 schrieb Friedhelm Schmidt fschm...@extend.de: Kann Gary68 nicht vielleicht ein Checker schreiben um fehlende highway bei gesetztem tracktype zu finden ? Ich bin sicher, das ginge, und es wäre auch sinnvoll. Aber das fehlende Tag ist nicht mein eigentlicher Punkt. Mein Punkt ist die Inflation von Differenzierungen, die keinen oder kaum Mehrwert bringen. Naja, in deinem Beispiel war wirklich viel Käse drin, was aber eher daran liegen dürfte, daß der vorherige mapper mit den access-tags nicht so geschickt war. Optimal wäre m.E. highway=track, tracktype=grade1, motor_vehicle=agricultural - damit wäre alles gesagt. Die MTBler scheinen die Aussage dies ist für uns wirklich kein interessanter Weg dem nicht-taggen vorzuziehen, warum auch nicht? Ich denke was *wirklich* zum vergessen des highway-tags geführt hat war, daß josm auch *ohne* highway=track bei vorhandenem tracktype=* einen track anzeigt... ;-) Und dazu gehört halt auch die Path-Seuche: Hier noch ein paar Stilgerechte Ideen für deine Formulierungen: Pest, Krebsgeschwür, Pathflut, Informationskatastrophe ,Untergang des Abendlandes, spätwikipedianische Dekadenz... ;-) Statt z.B. easy highway = cycleway, foot = yes oder umgekehrt sollen endlose Path-Orgien einen Vorteil bringen? Statt easy alle Wege unterhalb von track mit path zu taggen und einfach einzutragen, wie sie beschaffen sind und wem sie gewidmet sind, soll ich endlos regional-national unterschiedliche Implikationen lernen, nur um taggen zu können? Die getrennte Erfassung ist auch gerade für Einsteiger einfacher, die so einfach nur eintragen müssen, was da ist, ohne groß die Abgrenzung zwischen footway, cycleway und bridleway in verschiedenen Regionen zu lernen. Nee - nee - nee (in meinem Dialekt Awwa). Wir brauchen keine weiteren neutralen Wegtypen, die durch Zusatztags verschiedenste Wege werden können. Nur weil du aus dem Segler die Schildchen nicht erkennst... ;-) Konsistent: highway = track - tracktype = ... ist immer ein Wirtschaftsweg Inkostistent: highway = path - Zusatztags = ... kann Trampelpfad, Fußweg, Radweg, ... sein. Ist immer ein Weg unterhalb track. Wie der genau aussieht sowie wem er gewidmet ist, ergibt sich aus den Zusatztags - eigentlich müsstest du track also auch hassen und highway=pavedtrack, highway=campactedtrack, highway=partlycompactedtrack, highway=barelycompactedtrack sowie highway=reallybadornearlyinvisibletrack hier vorschlagen... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
Hallo Peter, Besser den Sammelartikel zerlegen und erst dann verlinken. Das kannst du von einem Mapper aber nicht erwarten Klar, ein reiner Mapper wird da vielleicht nicht interessiert sein. Aber es gibt ja durchaus OSMer, die gleichzeitig Wikipedianer sind, und Wikipedianer, die gleichzeitig OSMer sind. Und wenn die Kooperation WP-OSM weiter voranschreitet, die Projekte zunehmend zusammenwachsen, dann werden sichauch die Fähigkeiten der Beteiligten entwickeln und die gemeinsamen Werkzeuge besser werden. In diesem Sinne ist es m.E. ein guter Schritt, sich jetzt schon Gedanken zu machen über ein hilfreiches Datenschema und passende Attribute. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
Am 21. Juni 2010 10:17 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: verstehe ich nicht: ist bicycle=yes nicht extra dafür gedacht, alle Wege wo man fahrradfahren kann zu taggen? Was empfiehlst Du für ein Tagging für Wege, wo man fahrradfahren kann? Eher, wo man darf - das können ist ja stark vom Gefährt und der eigenen Person abhängig. Daher sollte man es m.E. an der Ausgabeseite filtern - also entweder ein noch zu etablierendes(?) bicycle:suitability=*-Tag auswerten oder gleich die Eigenschaften des Weges, die die Nutzbarkeit ausmachen: Oberfläche, Breite, Ebenheit, Anwesenheit von Orks ;-) Abgesehen davon: wie taggen für keinen (speziellen) Renderer Ja, jedenfalls verbiegen wir unser tagging möglichst nicht dafür. ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
Hallo aighes, Wo hast du denn das bicyle=designated im highway=cycleway drin. Das wiki sagt dazu nichts. Hier ist ein cycleway als ein Weg beschreiben, der hauptsächlich zum Radfahren genutzt wird. Ebenso bei footway und briddleway. | Für ausgewiesene (designated) Fahrradwege. In Deutschland sind diese | Wege meist ausgeschildert. | | Da in der Regel keine anderen Verkehrsteilnehmer erlaubt sind, | müssen eventuelle ausgeschilderte Ausnahmen explizit angegeben | werden. http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dcycleway | The highway=cycleway indicates that the used way is mainly or | exclusively for bicycles. Consider using highway=path if use is not | restricted to cyclists. http://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway Default access-restriction: highway=cycleway - bicycle=designated http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
Am 21. Juni 2010 10:39 schrieb Martin Simon grenzde...@gmail.com: Am 21. Juni 2010 10:17 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: verstehe ich nicht: ist bicycle=yes nicht extra dafür gedacht, alle Wege wo man fahrradfahren kann zu taggen? Was empfiehlst Du für ein Tagging für Wege, wo man fahrradfahren kann? Eher, wo man darf - das können ist ja stark vom Gefährt und der eigenen Person abhängig. Ja, ich dachte eher weniger an technisches können, sondern an legales eigentlich nicht dürfen aber geduldet sein. Vermutlich sollte man das mit bicycle=permissive taggen (kommt in Berlin und Rom z.B. öfters vor, in Rom wird es praktisch überall geduldet, bzw. wird man als Fahrradfahrer von den Ordnungskräften überhaupt nicht als Verkehrsteilnehmer eingestuft, aber auch in Berlin ist rücksichtsvolles Fahren auf dem Bürgersteig praktisch fast überall geduldet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
On Fri, Jun 18, 2010 at 01:09:57PM +0200, M???rtin Koppenhoefer wrote: Am 18. Juni 2010 10:16 schrieb Andreas Tille andr...@an3as.eu: Ich habe jetzt auch noch mal genau hingeguckt es gibt auch GELBE Schilder: http://www.paderborn.de/freizeit/images/442.gif.scaled/150x90.pm1.bgFF.png auf der entsprechenden Seite http://www.paderborn.de/freizeit/radfahren/sp_auto_13041.php ist diese mit 16. Ein gelbes, rechteckiges Schild mit Fahrradsymbol und Pfeil (Z 442) kennzeichnet den weiteren Verlauf eines Radweges. beschrieben. Bei uns ist es aber definitiv kein Radweg mit blauem Schild, sondern die Radfahrer werden als Alternative zur falschen Richtung einer Einbahnstraße auf einen ansonsten nicht gekennzeichneten (also insbesondere nicht durch irgendwelche blauen Schilder) gepflasterten etwa 2.5 m breiten Weg geschickt (der durch einen Fluß von der Straße getrennt ist). Ist das nun ein bicycle= yes / designated / official ?? das ist m.E. kein bicycle=irgendwas sondern Teil einer Fahrradroute und daher die Straße in eine Routenrelation aufzunehmen. Fahrradrouten haben aber einen Namen, Hinweisschilder von wo nach wo, einen Operatoer etc. Das alles trifft für oben genannte Gegebenheit nicht zu. Aoßerdem stellt sich die Frage: Bevorzugen Router für Fahrräder Teile von oben genannten Fahrradrouten oder richten sie sich ausschließlich nach den verwendeten Tags. Wenn das letztere der Fall ist (und intuitiv würde ich das annehmen wollen) sollte alles ohnehing korrektes getaggt werden. Selbst wenn aber die Routing Software Fahrradrouten tatsächlich bevorzugen würde, bin ich der Meinung, daß die Tags sinnvoll zu setzen sind. Die Tatsache, daß ein Weg auf einer Fahrradroute liegt sagt ja erstmal über die Beschaffenheit des Weges ansich nichts aus. Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
