Re: [OSM-talk] GPS Accuracy under Forest Canopy
On Mon, Aug 10, 2009 at 12:40 PM, Apollinaris Schoell ascho...@gmail.comwrote: Garmin calls it high sensitivity but thats marketing Maybe better than very old Garmin devices but much worse compared to a SiRF III I have a new Hcx and compared multiple times. Only 60, Oregon, Colorado use a SiRF III and they are much better in accuracy but drain batteries like crazy. Still like the Hcx because it's smaller and battery life is very important on long hikes. No, the 60Cx/60CSx are the only handheld Garmin models that have a Sirf Star III (well, maybe some niche units like the Astro or Rino have it). The Colorado has a MediaTek just like the Vista HCx. The Oregon has a STM Cartesio chipset, same as the Delorme PN-40. I haven't used a 60Cx or 60CSx model, but I had a Vista HCx and it performed quite well. There was a rough series of chipset firmware for the Vista HCx that had a problem with drifting from the true position under difficult conditions, but recent firmwares have fixed that (or you could use the old version...). It was definitely able to hold a signal under difficult conditions better than the PN-40 I have now. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Something Might be Broken
On Thu, Jul 30, 2009 at 7:29 PM, Andrew Ayre a...@britishideas.com wrote: Take a look at this boundary where a forest and national park meet: http://osm.org/go/TwUljNo-- Notice that the boundaries don't line up. This is because the national park is in slightly the wrong place. The national park is this changeset uploaded yesterday: http://www.openstreetmap.org/browse/changeset/1980439 Today I moved the national park into the correct position. The changeset was closed at 31 Jul 00:09: http://www.openstreetmap.org/browse/changeset/1989864 I then marked the tile you are looking at as dirty. It was apparently rendered by Mapnik on 31 Jul 03:21: http://a.tile.openstreetmap.org/12/772/1608.png/status As you can see the data from my new changeset has not been used. On 31 Jul 01:33 I added a new changeset with some trails: http://www.openstreetmap.org/browse/changeset/1990063 This was rendered with trails at 31 Jul 03:13: http://a.tile.openstreetmap.org/13/1567/3318.png/status If data I uploaded at 01:33 was rendered at 3:13, how come data I uploaded at 00:09 has not been rendered at the time of writing this? (03:21)? One clue might be that the trails are new data but the movement of nodes was not. Also JOSM gave me an error of unexpected end of file when the changeset was closing, but the changeset is listed in my edits as being closed anyway. It also has all 23573 nodes. I have cleared my browser cache and tried two browsers. I have two other examples of different data/changesets that I just cannot get Mapnik to render it. In both cases some of the data is rendered. One of those I've asked for help on here and the Mapnik list with no solution. I've tried everything I can think of. I don't know what the Osmarender update speed is or how to mark tiles as dirty or find out when they were rendered, so I am unsure if Osmarender tiles can be directly compared. Any help is greatly appreciated, otherwise I am losing confidence. Andy If the boundary is a relation, that may be the reason. (Since you said it has 23573 nodes, then it must be a boundary relation.) AFAIK, Mapnik (or more properly, osm2pgsql) currently doesn't process relations for diffs. You'll have to wait until the planet reload after next Wed to see the border update. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] park barrier
On Sun, Jul 26, 2009 at 8:16 AM, John Smith delta_foxt...@yahoo.com wrote: --- On Sun, 26/7/09, ヴィカス ヤダワ (vikas yadav) mevi...@gmail.com wrote: Is there a park barrier like this: Like its made of metal, circular in shape, two perpendicular diagonals separator, rotates and prevents any sort of vehicles including cycles to be brought in. Only one person can enter at a time. I checked the http://wiki.openstreetmap.org/wiki/Barrier but could not locate it. barrier=stile? The definition of that tag on the wiki is exactly what I imagined a stile to be, but that's not quite what he's describing. He's talking about a turnstile (http://en.wikipedia.org/wiki/Turnstile). I suppose barrier=stile could apply, but if that's the case the wiki should be updated to show that variant. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] [Talk-us] [OSM-talk] Bicycle boulevards
On Wed, Jun 10, 2009 at 10:04 AM, Paul Johnson ba...@ursamundi.org wrote: Karl Newman wrote: *Avoid duplicate copies of messages?* When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select /Yes/ to avoid receiving copies from the mailing list; select /No/ to receive copies. If the list has member personalized messages enabled, and you elect to receive copies, every copy will have a X-Mailman-Copy: yes header added to it. This does not work: What about gmane users? I don't really know how gmane works from a posting perspective (e.g., do you have to be subscribed to the mailing list to be able to post from gmane, like you do on nabble?), but on http://gmane.org/post.php I found this: - What address is used? The news-to-mail authorization script uses the From header to determine who's sent the message. If the Reply-To header exists, that header is used instead. If you wish From to take precedence over Reply-To, insert a non-empty Gmane-From header as well. If you wish to redirect replies to your messages back to the mailing list, add a Mail-Copies-To: never header to your messages. That will result in a Mail-Followup-To header being generated by Gmane. These headers are heeded by quite a few mail readers. If you add a Reply-To header to your messages that points to a mailing list, the message will be silently dropped. - Karl ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk] [Talk-us] Bicycle boulevards
On Wed, Jun 10, 2009 at 10:04 AM, Paul Johnson ba...@ursamundi.org wrote: Karl Newman wrote: *Avoid duplicate copies of messages?* When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select /Yes/ to avoid receiving copies from the mailing list; select /No/ to receive copies. If the list has member personalized messages enabled, and you elect to receive copies, every copy will have a X-Mailman-Copy: yes header added to it. This does not work: What about gmane users? I don't really know how gmane works from a posting perspective (e.g., do you have to be subscribed to the mailing list to be able to post from gmane, like you do on nabble?), but on http://gmane.org/post.php I found this: - What address is used? The news-to-mail authorization script uses the From header to determine who's sent the message. If the Reply-To header exists, that header is used instead. If you wish From to take precedence over Reply-To, insert a non-empty Gmane-From header as well. If you wish to redirect replies to your messages back to the mailing list, add a Mail-Copies-To: never header to your messages. That will result in a Mail-Followup-To header being generated by Gmane. These headers are heeded by quite a few mail readers. If you add a Reply-To header to your messages that points to a mailing list, the message will be silently dropped. - Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bicycle boulevards
On Tue, Jun 9, 2009 at 11:44 AM, Paul Johnson ba...@ursamundi.org wrote: (Please don't CC me when replying; I get the list, and I don't need two copies (plus this defeats unsubscribing if someone later wants to leave the conversation). Please use your mailer's reply-to-list feature or check your To: and CC: headers!) Paul, Go to http://lists.openstreetmap.org/listinfo/talk, log in and edit your options. Scroll to the bottom and find this: *Avoid duplicate copies of messages?* When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select *Yes*to avoid receiving copies from the mailing list; select *No* to receive copies. If the list has member personalized messages enabled, and you elect to receive copies, every copy will have a X-Mailman-Copy: yes header added to it. Obviously it doesn't address your concern about leaving the conversation, but maybe it will be less annoying for you to receive messages from people like me that have been conditioned to Reply All. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] [OSM-talk] Bicycle boulevards
On Tue, Jun 9, 2009 at 11:44 AM, Paul Johnson ba...@ursamundi.org wrote: (Please don't CC me when replying; I get the list, and I don't need two copies (plus this defeats unsubscribing if someone later wants to leave the conversation). Please use your mailer's reply-to-list feature or check your To: and CC: headers!) Paul, Go to http://lists.openstreetmap.org/listinfo/talk, log in and edit your options. Scroll to the bottom and find this: *Avoid duplicate copies of messages?* When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select *Yes*to avoid receiving copies from the mailing list; select *No* to receive copies. If the list has member personalized messages enabled, and you elect to receive copies, every copy will have a X-Mailman-Copy: yes header added to it. Obviously it doesn't address your concern about leaving the conversation, but maybe it will be less annoying for you to receive messages from people like me that have been conditioned to Reply All. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] How big of an SD card should I get for Openstreetmap work
On Sun, May 31, 2009 at 2:45 AM, Peter Herison pheri...@web.de wrote: Karl Newman wrote: Peter Herison wrote: Iván Sánchez Ortega wrote: AFAIK, the biggest microSD card that you can put into an eTrex is a 2 GB card (the bigger microSD-HC cards won't work). This is for firmware 2.80. With 3.00 you can use SD-Cards up to 4GB. But it's irrelevant because you can still only use a compiled map file up to 2 GB (and 2025 map segments which is usually the more relevant number). Changes made from version 2.80 to 3.00: * Add support for maps greater than 2 GB. http://www8.garmin.com/support/download_details.jsp?id=3707 Wow, cool. I hadn't been keeping up (since I smashed my Vista HCx in a bike accident last month... cry) I had thought that was some sort of hardware limitation, not something that could be fixed in software. Or at the least, not something that they would fix in software for older units. I wonder if it still has the 2025 segment limitation, though. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How big of an SD card should I get for Openstreetmap work
On Sat, May 30, 2009 at 3:17 PM, Peter Herison pheri...@web.de wrote: Iván Sánchez Ortega schrieb: AFAIK, the biggest microSD card that you can put into an eTrex is a 2 GB card (the bigger microSD-HC cards won't work). This is for firmware 2.80. With 3.00 you can use SD-Cards up to 4GB. But it's irrelevant because you can still only use a compiled map file up to 2 GB (and 2025 map segments which is usually the more relevant number). You could use the rest of the space for tracklogs, I suppose, but that's many months or years worth of tracklogs. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Re verting Changes....
On Mon, May 18, 2009 at 10:13 AM, Russ Nelson r...@cloudmade.com wrote: Richard, I know that you don't have infinite resources to devote to Potlatch. But if you can't fix usability problems, then maybe the EDIT tab should go to a Webstart JOSM page? I'm not suggesting that we ban potlatch; just give you some breathing room to fix it. Oh, boy, here we go with another 60+ email thread... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM maps of Denmark for download to Garmin devices
On Wed, Apr 29, 2009 at 5:31 AM, Lambertus o...@na1400.info wrote: Maarten Deen wrote: Lambertus wrote: Maarten Deen wrote: Not to diminish your work on that front, but I find the tilelayout on your site very strange. Of course it is a work of the splitter, but I would opt for a manual layout, guided by an initial automated process. Please forgive me for relying on the automated Splitter layout mechanism as I have no intention to manually divide the world into 500 tiles (317 America + 182 Europe/Asia/Africa/Oceania currently). Optimizing the tiles would result in even more, so you'd be talking about e.g 750 tiles. I'm certainly not complaining about your work. It's the reason why I bought a Garmin Nüvi and not a TomTom. See Garmin...this is why you need to publicize your map format :-) Needless to say: patches welcome ofcourse. The definition files for Splitter are: - http://planetosm.oxilion.nl/~lambertus/america.listhttp://planetosm.oxilion.nl/%7Elambertus/america.list - http://planetosm.oxilion.nl/~lambertus/eurasia.listhttp://planetosm.oxilion.nl/%7Elambertus/eurasia.list IMHO the strategy that the Mapsource tiles use is much more logical. Take one big tile, if that has too many nodes, split it in half horizontally, if that has too many nodes split it in half vertically... repeat until you have a sufficient small amount of nodes. This strategy is afaik exactly what Splitter does. Then it does it in a strange way. I'm sure you've noticed that the edges of the tiles don't line up by just a few 1/100th of a degree in a lot of places. That is inconsistent with a strategy of dividing a tile in half if it has too many nodes. E.g. tiles 63240113 and 63240116. One has a north border of 51.679688, the other 51.635742. And then two tiles further east, 63240120 has a north border of 52.679688 again. Well, maybe not exactly in half, but the idea is the same. Afaik, the reason why Splitter doesn't split exactly in half is that there is less chance that a polygon is present in too many tiles. BTW: have you seen that Mapsource draws the maps as overlapping? I've attached a screenshot of how Mapsource displays maps 63240105 (yellow), 63240175 (blue, continuing to the top) and 63240179 (green). They all overlap eachother. According to their definitions, they should not overlap, but mapsource apparently disagrees. Any idea why that is? I've seen this with topo maps made with older versions of Mkgmap as well. This might be a bug in Mkgmap or a misunderstanding of the Garmin map format but I don't think it's harmful though. Probably the reason for the overlap is nodes shared on a polyline which crosses a tile boundary, to prevent gaps. These shared nodes would extend the boundaries of each tile somewhat into the space of the neighboring tile. Otherwise, each tile would have to have a node exactly on the border, and the map resolution might not allow that. Shared nodes are required in routable maps (the shared nodes are marked as external to allow routing across tiles). Another reason I just thought of, which may explain why the overlap looks so large (larger than could be explained by shared nodes) is possibly the map projection used by MapSource. The projection might distort the map boundaries from a rectangle into something warped, but for simplicity MapSource only draws a straight line (not great circle) between the map boundary segments. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] osmosis 0.30 problem...
On Mon, Apr 27, 2009 at 7:07 AM, Gary68 g...@gary68.de wrote: hi, i want to use the clipIncompleteEntities option for 0.6 data files. osmosis version is 0.30 i get: com.bretth.osmosis.core.OsmosisRuntimeException: Argument clipIncompleteEntities for task 2-bounding-box was not recognised. is option order crucial? command line is: ../../osmosis/osmosis-0.30/bin/osmosis --rx ../../osmdata/spain.osm --bounding-box left=-5.7 right=-3.8 bottom=35.99 top=36.9 clipIncompleteEntities=true --wx ../../osmdata/costadelsol.osm cheers gerhard That option is only implemented in the 0.6 tasks, and Osmosis 0.30 defaults to 0.5 tasks. In order to use this with 0.30, you need to specifically indicate 0.6 tasks by appending -0.6 to each task name. In other words: ../../osmosis/osmosis-0.30/bin/osmosis --read-xml-0.6 ../../osmdata/spain.osm --bounding-box-0.6 left=-5.7 right=-3.8 bottom=35.99 top=36.9 clipIncompleteEntities=true --write-xml-0.6 ../../osmdata/costadelsol.osm Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] newbies Digest, Vol 26, Issue 15 - can't upload
On Sat, Apr 25, 2009 at 6:49 AM, Mike Harris mik...@googlemail.com wrote:
I have raised a ticket for this but would appreciate any help so that I can
make some progress ...
I tackled API6 with JOSM for the first time today. My first attempt - a
small edit - worked like a dream and the update appeared OK on the next
download from OSM.
My next attempt was a much bigger set of edits - this repeatedly fails to
upload. The error message has to be read in sections as it is too long for
the dialogue box but after several failed uploads I can see I am getting a
java error java.io.IOException and an OSM server error code 409. I have
been
industriously filling in the new comment box!
I have tried downloading immediately before uploading. This always gives
the
same single conflict (ID 28422846) a short way that was duplicated and I
edited out the duplication. Attempting to resolve the conflict gives me the
obvious two choices - deleted=true ('mine') or deleted=false ('theirs').
After resolving the conflict the upload still fails with a 409 error. It
doesn't matter which option I choose. I have even chosen 'false',
re-deleted
the duplicate and then tried again.
Seems to be a bug somewhere in API6 - so no more mapping until I can get an
answer that allows me to upload. Particularly annoying as I had to recreate
the OSM as I was half way through the job before the API change and didn't
want to mess about with the half-finished work in api 5 osm format.
I am using josm v 1555 (but have also tried v1529 - the most recent
'stable'
version - which still gives 409 errors). I am using java v1.6.0_13.
HELP!
Mike
Cross-posting to JOSM-dev. I haven't looked at the code, but it makes me
wonder if the conflict resolution is not taking the version number from the
downloaded (conflicting) entity, which would make the version number
mismatch and give you a 409 (conflict) error and thus prevent you from
uploading.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osmosis Problem with bounding-polygon and v0.6?
On Thu, Apr 23, 2009 at 12:39 PM, Marco Lechner - FOSSGIS e.V. marco.lech...@fossgis.de wrote: hi karl, ./bin/osmosis --read-xml-0.6 file=path/planet-090421.osm.bz2 compressionMethod=bzip2 --bounding-polygon-0.6 file=path/aoi.pff --write-xml-0.6 file=path/aoi_2009-04-21_v06.osm gives (almost) the same error as pure v0.5: Unable to parse xml file path/planet-090421.osm.bz2. publicId=(null), systemId=(null), lineNumber=6663, columnNumber=34. at com.bretth.osmosis.core.xml.v0_6.XmlReader.run(XmlReader.java:114) at java.lang.Thread.run(Thread.java:636) Caused by: org.xml.sax.SAXParseException: XML document structures must start and end within the same entity. Marco So, it sounds like you had multiple problems. Probably your planet file is corrupt. You could try to look at the referenced line (6663) in the unpacked file and see if it is valid XML. Most likely you will need to re-download the planet file. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] best GPS for trekking
On Sun, Apr 19, 2009 at 3:05 PM, Ed Avis e...@waniasset.com wrote: One data point: my Garmin eTrex unit has recently broken the 'zoom in' button on the side - it broke off underneath the rubber bumper and started rattling around inside, so now the map display can be zoomed out but not in. I bought it a few months ago, so will try to get it repaired under warranty. I don't know if competing units have better build quality. I think the eTrex series is generally pretty robust. I (used to) frequent the geocaching.com boards and saw a lot of complaints about various units, but the eTrex design has been around for a while and is fairly bulletproof. Obviously cases like yours are the exception, but the common complaints about the eTrex construction (when there are any) are the surrounding rubber band separating from the unit (happens more when exposed to temperature extremes) and a loose/disconnected screen ribbon cable (only on older models). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing home point cloud(s) from multiple GPX files
On Fri, Apr 17, 2009 at 12:21 PM, David Ebling dave_ebl...@yahoo.co.ukwrote: During the downtime I figured I should really catch up with cleaning up my huge backlog of GPX files and prepare them for upload. I have many many hours of tracks on my HDD that I have not uploaded because many of them are polluted with point clouds around my house and my relatives' houses. I am not happy to upload these for privacy reasons and also for data purity reasons. I am not very command line compatible, and can't find *any* gui tool for Mac or Windows that will let me do this. GPX Babel only seems to let you remove points outside a radius not inside the radius, unless you use the exclude option which appears to be command line only. It also takes lat and long in an annoying format (decimal minutes, neither decimal degrees nor degrees, minutes and seconds.) It also seems only to be able to process one file at a time on the Mac version I've played with. Is there any program out there that will do this easily? If not OSM would really benefit from one, as I think there are many people like me who aren't uploading GPX because cleaning them up is simply too much effort. Here's my idea for someone with more programming skills than me: -A dialogue box that uses an OSM slippy map to draw circles of exclusion on the map, with a guidance note suggesting that they are near and covering but not exactly centred on your home/work/other point cloud locations. -Ability to batch process that's user friendly -Output to a new folder -Ideally, upload direct to OSM, to be considerate to other users, perhaps over a specified time interval. Any programmers out there want to take up this idea while we have some down time? :D Please? :) I'll upload lots of GPX files in return! ;) Thanks, Dave I want the same thing, and I looked into doing this with GPSBabel, too, and while it has the capability to filter points inside or outside a radius (or polygon, etc.), that function does not work on trackpoints, and the author had said something to the effect of it doesn't make sense to have it enabled for trackpoints because it would make false tracks (jumps, etc.). At least, that's what I found when I last checked about maybe a year ago. I don't know why it couldn't just split it into however many tracks it needs to show the discontinuity before/after the exclusion zone. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing home point cloud(s) from multiple GPX files
On Fri, Apr 17, 2009 at 1:48 PM, Frederik Ramm frede...@remote.org wrote: Hi, Karl Newman wrote: I want the same thing, and I looked into doing this with GPSBabel, too, and while it has the capability to filter points inside or outside a radius (or polygon, etc.), that function does not work on trackpoints, and the author had said something to the effect of it doesn't make sense to have it enabled for trackpoints because it would make false tracks (jumps, etc.). Those free software authors are bastards aren't they ;-) Someone on talk-de recently posted the following magic spell he's using with gpsbabel to simplify his tracks, clear them of point clouds and exclude certain areas: -x nuketypes,waypoints,routes -x transform,wpt=trk -x nuketypes,tracks -x polygon,file=europa.txt -x polygon,file=gruener.txt,exclude -x sort,time -x transform,trk=wpt -x nuketypes,waypoints -x track,pack,sdistance=0.2k,split=20s -x position,distance=1m The clever bit seems to be the -x transform incantantions with which he converts trackpoints to waypoints before applying the polygon filter, then transforms them back! Bye Frederik Cool. I'll have to check that out. I'm curious to see what information is lost in the translation. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] best GPS for trekking
On Thu, Apr 16, 2009 at 9:26 AM, Lambertus o...@na1400.info wrote: Joe Richards wrote: I will be trekking in Nepal later this year, and would like to keep some nice GPX trails and waypoints (both on the trekking trails and in the towns/roads), since it looks relatively unmapped... I usually use a windows mobile device with a bluetooth GPS but this strikes me as way to flimsy and the battery life would be far too short. What is my best option given the requirements of: * reasonable robustness - ie can be put in the top pocket of a backpack and forgotten about for a day, even if I slip over or sling my bag around * excellent battery life, ideally a few days' tracking before a recharge (although I could carry other power sources, I'd rather not) * a little feedback, not just a GPS 'brick' - e.g. a display and/or the ability to enter waypoint names would be nice My options would be the Garmin Vista HCx or Garmin GPSmap 60CSx. Both are very sturdy outdoor GPS devices with high sensitivity receiver, micro-SD card for maps and unlimited tracklogs, color screen. The HCx is a bit cheaper but the 60CSx has a screen that's a bit larger and better readable without the backlight on (which saves battery life). With good batteries you should be able to get about 20 hours between charges. I notice that my NiMH batteries (Ansmann 2700mAh) perform worse when it's cold, so maybe normal Alkaline batteries might be better in cold environments. The Vista HCx is plenty readable with the backlight off. Where it's most difficult is in shade or under cloudy conditions. The HCx has better battery life than the 60 CSx, too (maybe 24 hours vs. 16 for ~2500 mAh NiMH batteries), and lithium batteries perform the best in cold weather. Both NiMH and alkalines drain fast in the cold. Lithiums also have higher capacity than either. However, they're not rechargeable, unfortunately. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] best GPS for trekking
On Thu, Apr 16, 2009 at 9:34 AM, Joe Richards joefis...@yahoo.com wrote: Well I'd like to collect lots of data, even if it involves me taking a pack of those 2GB SD cards that I keep switching every day or two... Obviously taking normal AA batteries is a plus, and I am thinking of getting one of those solar chargers that covers the top of your backpack (yes seriously!) Browsing the Garmin eTrex devices, I notice even the ones with a proper screen aren't all that expensive http://www.gpsw.co.uk/details/prod3549.html I could then load it up with maps that show any existing data from OSM and/or any other sources, e.g. http://www.nepalgpsmap.com/en/maps.html to keep track of how far (and high) we're going and whether or not waypoints have already been marked... One 2 GB MicroSD card should be enough for years of data, even at 1 sec resolution in GPX format. Just make sure you format the card as FAT32 so you can have more efficient storage of many small files (assuming you get a Garmin). Also note that your tracklogs share space with maps on the card, but even if you leave yourself 100 MB or so, that should be plenty of space for many days of high-frequency tracklogs. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] best GPS for trekking
On Thu, Apr 16, 2009 at 11:54 AM, Igor Brejc igor.br...@gmail.com wrote: Lambertus wrote: Igor Brejc wrote: I think 5 sec interval when walking is quite enough - realistically that's less than 7 m of distance between two points. The problem with Garmins (at least eTrex) is that they only really use unit's internal RAM for storing tracks and they store up to 10,000 points there. When storing tracks on SD cards, Garmins do a lot of simplifying, so the tracks end up being useless. This is not the case with Vista HCx and 60CSx when the settings are correct: In the track menu goto Setup - Enable the Wrap When Full option Goto Data Card Setup menu - Enable Log Track To Data Card option Now you can log the raw trackpoints to the SD-card practically forever. You're right - I've just compared the GPX from the internal memory (Vista Cx) with the one from the SD card and they seem to be exactly the same. Hmmm I'm SURE I viewed these a way back and they were all mangled You learn new things every day. Igor If you save your internal track, it simplifies (mangles) it. But the track on the card will always have the original data. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=cyclefootway
On Fri, Mar 27, 2009 at 7:53 AM, Ed Loach e...@loach.me.uk wrote: So you're saying that highway=cycleway is not intended for ways which are for bicycles? What an ... interesting interpretation! I think mainly/exclusively may overstress the exclusively bit. I think generally if a bicycle and a pedestrian can use a way, but cars can't then highway=cycleway (foot=yes, bicycle=yes) is a better choice than highway=footway (foot=yes, bicycle=yes). As has been said, pedestrians can also walk on most roads in the UK, yet we don't tag those highway=footway (foot=yes, motorcar=yes). I see highway=path as a handy shortcut like highway=road for tagging something until a 'proper' tag can be assigned, though I realise not everyone will agree... Ed This may be a UK/Europe vs. rebel colonies thing, too, because in the US, we don't generally have such prominently defined access rules for paths. Certainly a system of color-coded signs and markings are not common here. More likely neighborhood paths are geared toward casual recreational usage (for walking dogs, etc, more than for bike commuting). So, the values used (footway, bridleway, cycleway) have generally well-defined meanings in the UK, but leaves those of us in the US a bit baffled. That's why highway=path makes a lot of sense for us when it's a multi-use path, not predominantly for any mode of transport. If it is primarily for a given mode of transport, designated= can fill that gap. Otherwise, the access keys can cover any posted permissions for different modes of transport. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Bridges, nodes, and routing engines (Navit, Gosmore, etc)
On Tue, Mar 24, 2009 at 6:46 PM, Chris Lawrence lordsu...@gmail.com wrote: Now the question is: should I remove the shared nodes (or detach them in JOSM) Yes. The roads are not topologically connected at the shared node, so nuke it. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Run tilesAtHome client and only accept requests for a small bbox. Possible?
On Thu, Mar 19, 2009 at 7:44 AM, LeedsTracker leedstrac...@gmail.comwrote: 2009/3/19 Tal tal@gmail.com: Every time I change something in my local neighborhood, I have to wait an unknown period of time before it appears in the Osmarender layer. This is quite annoying. Just a reminder of: http://labs.metacarta.com/osm/up-to-date/ It's for the Mapnik layer, I know, but I find it very handy. cheers, LT The main Mapnik layer on OSM.org is updated minutely now, I believe (maybe it's hourly). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] GNIS Import Done
While GNIS might not be perfectly accurate in geoposition, it is the authoritative set of geographic names for the US. It contains features that are on no other map or spatial database. Until now, anyway. ;-) Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Conflating Tracks?
On Tue, Mar 10, 2009 at 6:44 AM, Ed Avis e...@waniasset.com wrote: Daniel A Carleton daniel.carleton at exaptic.com writes: Are any of you aware of a conflation algorithm that snaps GPS tracks to the street grid? This could be a useful way to verify existing road networks and fill in any gaps. e.g. I go out and ride on city streets, overlay my GPS track on the OSM grid, and the algorithm shows me where I traveled over unknown segments of road or deviated a disproportionate amount. To do that you'd ideally want to know the margin of error for the GPS readings. My GPS unit (Garmin eTrex Vista HCx) shows an error circle on its screen (giving a tighter circle when there is good reception, and a wider one when the sky is obscured by tall buildings) but on saving the tracks as GPX this information is lost. Is there a way to export the track log including error circles into a format that the OSM servers recognize? (It appears that I could connect the unit to a laptop and record the tracks with gpsd, but I would prefer to just carry the unit and recover the track log afterwards.) -- Ed Avis e...@waniasset.com I have a Vista HCx, too. Bafflingly, Garmin does not store the DOP with the tracklog and there is no way to extract it after the fact (or even realtime, I don't think). If you can get an NMEA stream, you can get the HDOP (which is what you care about for this application). The USB-only Garmin units (like the Vista HCx) cannot emit a NMEA stream like the serial-enabled units could. I believe the Garmin 60CSx has USB and serial and can emit NMEA over the serial port, but you'd need a laptop to capture it. By the way, the circle on your Vista HCx is a function of both your EPE (positional error as estimated by the receiver) AND the resolution of the maps you're currently displaying. The circle is more conservative (i.e., larger) than the displayed EPE number, too. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Conflating Tracks - getting error margin from Garmin devices
On Tue, Mar 10, 2009 at 8:44 AM, Ed Avis e...@waniasset.com wrote: Karl Newman siliconfiend at gmail.com writes: Are any of you aware of a conflation algorithm that snaps GPS tracks to the street grid? This could be a useful way to verify existing road networks and fill in any gaps. To do that you'd ideally want to know the margin of error for the GPS readings. My GPS unit (Garmin eTrex Vista HCx) shows an error circle on its screen I have a Vista HCx, too. Bafflingly, Garmin does not store the DOP with the tracklog and there is no way to extract it after the fact (or even realtime, I don't think). Oh, that is disappointing. If you can get an NMEA stream, you can get the HDOP (which is what you care about for this application). The USB-only Garmin units (like the Vista HCx) cannot emit a NMEA stream like the serial-enabled units could. Apparently the Windows program GpsGate can convert the output from the USB Garmin devies to NMEA format. I wonder if there is a free equivalent to get it working with gpsd or similar on Linux? Well, GPSBabel is your cross-platform friend for translating between GPS data formats, but my impression is that the Garmin USB protocol does not contain DOP information. I would be happy if I were completely wrong on that point, though. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Activity Level in My Area?
On Tue, Mar 10, 2009 at 4:53 PM, Daniel A Carleton daniel.carle...@exaptic.com wrote: Hello All, I'm trying to evaluate what street map dataset to go with for a web application. I appreciate the features in the OSM data that would otherwise go overlooked by big commercial products. e.g. Trails and such. Also the affordability! There is substantial risk, though, because the TIGER data is not sufficient, and I don't know how active the OSM mapping community is in my area. Is there an easy way to determine the activity level of users in my area? I live in Seattle, WA USA. Seems like most of you folks are in Europe. Thanks, - Daniel There's a pretty good community in the US, too (although not nearly as prolific as the Germans). To monitor activity I'd suggest you go to www.itoworld.com and sign up to monitor an area you're interested in. The sessions view will give you an idea about recent activity. Also, if you set a location on your OSM profile, you can see other nearby users who have given their location as well. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] amenity=doctor or amenity=doctors ? [tagging]
On Mon, Feb 23, 2009 at 9:26 AM, Mike Harris mik...@googlemail.com wrote: Ed I guessed it was a little t-i-c (:) but as it raised an issue I was interested in, I took the opportunity to post! You have returned the compliment! As what might be described as a footpath worker (and getting very involved outside of OSM in all sorts of footpath issues), when I was a complete OSM newbie (as opposed to having 'P' plates) I read the wiki avidly and was a bit surprised to find that the recommendation for UK (should be England and Wales anyway!) public footpaths (i.e. public rights of way on foot) was highway=footway plus foot=yes. Whereas imho it should be foot=designated. But as a newbie I didn't then dare to rock the boat and have now tagged hundreds of ways with foot=yes! But your first thought seems eminently sensible - foot=designated where there is a public 'right' of way and foot=yes where a path is physically capable of being walked on foot. By the same token, imho, a public bridleway (with 'bridleway' as defined in rights of way law) should be highway=track plus foot=yes and horse=designated and (usually - this is a more complex legal issue) bicycle=yes. But the wiki recommends foot=yes plus horse=yes etc. In short, the wiki http://wiki.openstreetmap.org/wiki/UK_public_rights_of_way doesn't seem to know about x=designated at all. There is a little sentence on the same page that reads: It would be ideal (to ensure your data shows up in renderers) to use the following combinations of tags. So maybe that was why =designated was not used (as I have never used it myself, I haven't checked the rendering - but then there is the old saw about not tagging for the renderers!). Yet another take on all this is found on http://wiki.openstreetmap.org/wiki/Key:access ! If we were starting from scratch I would strongly recommend the use of =designated for public rights of way but, unless someone wants to set up a new bot, this would require a huge amount of re-tagging (and a bot for the change would be hard to program unless one had knowledge of the rights of way status of each and every footway etc.). In an ideal and consistent logical world (i.e. not a wiki?!) we would perhaps use =designated, =permissive and =no for legality, reserving =yes for physical characteristics enabling the specified type of use (and perhaps implying permissive). This would also help with the problem of multi-user paths that are not public rights of way, such as most cycleways forming part of the regional and national networks - foot=permissive, bicycle=permissive, motorcar=no, motorcycle=no, horse=??? - as opposed to the cycleways that are specifically for cyclists alongside major roads (sometimes split only by a painted line from a parallel footway) - foot=no, bicycle=designated, etc. Where I would really like to see the old hands at osm chiming in on this whole nexus of issues is to provide advice as to how to be logical and consistent - and yet avoid massive retrospective changes to tagging! Where do we go from here! Mike I believe =designated came about at the same time as highway=path, and was part of that proposal. One of the original goals of highway=path was to replace cycleway, footway, bridleway, etc. So, instead of highway=footway, you would tag it highway=path, foot=designated. It has since been moderated as an alternative to those tags when the path usage may not be obvious and also promoted for multi-use paths. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] National Forest Boundaries
On Thu, Feb 19, 2009 at 8:21 AM, Theodore Book tb...@libero.it wrote: I have put the various proposals on the wiki at: http://wiki.openstreetmap.org/wiki/US_Forest_Service_Data It seems like the landuse=forest tag has a fair amount of consensus, but that we are not yet sure how to tag the fact that it is a national forest, and not just any forest. Especially since there may be large swathes within the national forest boundary that are devoid of trees... Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] usercases for josm outside osm
On Mon, Feb 2, 2009 at 7:27 PM, Kim Hawtin kim.haw...@adelaide.edu.auwrote: hi maning, maning sambale wrote: JOSM is an excellent data editing tool (hey I also love potlatch!). Many of of its features I would love integrated in some FOSS GIS editing toolbox. That being said, are there user cases where JOSM is used outside OSM as a GIS editing app? Please share your experiences. what i'd really like is a mode where i can edit the GPS trails. just top and tailing the junk off the ends where the GPS was started and stopped, any time where you are are effectively indoors... also splitting large GPS trails into smaller more manageable sections. one of the issues i have is that i can spend a fair bit of time trailing and can upload those trails, but don't always have the notes to go with to identify the specific journey. you have to upload the trail to the web site before you know where it is, and them edit the other attributes to go with it. so being able to use josm to get your bearings about which GPS trail it is before uploading it would be handy... this may not be what you had in mind, but a .gpx editor/manager would help a lot to get more of my trails up so folks can make use of them =) regards, kim I agree, a simple GPX editor (basically to split or merge tracks, and possibly to upload to OSM) integrated into JOSM would be ideal. In the meantime, there's Viking (viking.sourceforge.net), a GPS data management software which supports a number of OSM layers as background and allows uploading GPX tracks to OSM. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Osmosis running forever with completeWays=yes?
On Sun, Feb 1, 2009 at 1:55 PM, Frederik Ramm frede...@remote.org wrote: Hi, (f'up set to osmosis-dev) Karl Newman wrote: Anyway, the tee can choke things up with all the temporary files. It would be nice to be able to share the stored node and ways files between tee tasks, but I haven't created that infrastructure yet. It would be even better to have an extended --bp task that somehow takes a list of disjoint polygons and uses some kind of point location algorithm to determine which node belongs to which polygon. The rationale being of course that with the classic --bp/--tee approach, each node is duplicated n times and tested against each of the polygons which is a waste of time, especially with a large input file and many polygons (e.g. split up the US into counties or so). Does the task and stream model that osmosis uses theoretically support tasks where the number of output streams they create is not fixed, but dependent on their parameters? So that e.g. a bp file=a.poly file=b.poly (or bp files=a.poly,b.poly) creates two entity streams and so on? Bye Frederik What you're asking is possible. The number of input and output pipes has to be known at invocation because the pipes are connected before any tasks are run, but if it's a parameter passed to the task, then the task can report to the pipeline manager how many output pipes it has. The tricky part might be connecting the downstream tasks. It might be confusing because of the stack-based pipeline ordering. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How do I take a screenshot on the Garmin 60CSx?
On Thu, Jan 15, 2009 at 7:13 AM, Ævar Arnfjörð Bjarmason ava...@gmail.comwrote: I've read that on some Garmin units you can press a given button for a set period of time to have it dump a screenshot to its SD card. But I haven't found out how to do this for my Garmin GPSMAP 60CSx. Garmin has a utility called ximage which can do this, but I don't use win32, it doesn't run under Wine and I would rather do this without proprietary software anyway: http://www8.garmin.com/support/download_details.jsp?id=545 The device's manual doesn't specify any key combo. So is there any way to retrieve a screenshot of its screen under *nix? The new Garmin Oregon and Colorado units can take a screenshot by pressing the power button (if properly configured), but as far as I know, xImage is the only way to grab a screenshot from the older units. So, unless someone has reverse-engineered the protocol for extracting images (doubtful) and then written a *nix compatible utility, xImage is the only way you'll be able to do it. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM on Garmin - raster tiles?
On Tue, Jan 6, 2009 at 9:34 AM, Gervase Markham gerv-gm...@gerv.net wrote: When I heard about the possibility of OSM on Garmin, I imagined something like the Mapnik Slippy Map on my GPS screen. Now I have a Legend HCx, it turns out that I get the Garmin vector rendering with OSM data behind it. This is clearly much better than nothing, but does the gmapsupp.img format support stuffing in a load of raster tiles, or is it vector data only? (Obviously, you'd lose the ability to route with raster.) Gerv The new Colorado and Oregon models seem to support some sort of raster images natively, as evidenced by the Ordnance Survey maps recently released (Garmin GB Discoverer) [1]. However, the format of those is not publicly known. If you want to use raster images, the new Delorme PN-40 (and the older, slower PN-20) support raster nicely, and with a $100 add-on called XMap, you can add your own georeferenced images to your GPS, so you could use something like slippy map tiles. Caveat if you're looking to use Delorme maps: The currently available maps and aerial imagery from Delorme seem to cover only the US. Karl [1] http://forums.groundspeak.com/GC/index.php?s=showtopic=205902view=findpostp=3778507 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] US borders, watch out!
On Mon, Jan 5, 2009 at 12:51 PM, Juan Lucas Dominguez Rubio jldoming...@prodevelop.es wrote: Hi list, If someone is mapping the US national borders... forget it! Within a few weeks, the US will look like this: http://s.wsj.net/public/resources/images/P1-AO116_RUSPRO_NS_20081228191715.gif Regards, Lucas That's awesome. Looks like Sarah Palin will finally have a chance to get some foreign policy experience with her new Russian overlords. ;-) Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] US Route Tagging With Relations
On Wed, Dec 24, 2008 at 1:44 PM, Zeke Farwell ezeki...@gmail.com wrote: Yeah we're getting a little ahead of ourselves with the shields. The first step is tagging the highways in a standard scheme which would give a renderer sufficient data to draw shields. Then someone has to actually build a renderer that draws the shields. Thats a whole other can of worms. I don't think that the Slippy Map on openstreetmap.org will ever draw custom shields beyond blue interstate shields, white US highway shields, and white ovals for state routes. I think it would be great to have a map with custom shields for every state. What we need for that to happen is someone to set up a US based Open Street Map renderer. In addition to custom shields, the highway colors could be drawn in more US centric way: varying shades of red, orange, and yellow with green reserved for toll roads. I think this would really help people in the US get involved with OSM because the map would look more familiar to them. The main slippy map is never going to do this though, because it is international. 2) I don't like the is_in approach - the US:CA approach seems to offer all the appropriate information in the same place. However, if there was a way to explicitly state that this is a state route, that would help in the situation mentioned above. The UC:CA approach does offer all the appropriate information in the same place. I don't think that is necessarily desirable though. For example, Vermont Route 30 is never called US Vermont Route 30. The network is just Vermont, not United States: Vermont. This is even more true for county roads. If Windham county in Vermont had it's own numbered routes one would not call a route United States, Vermont, Windham County Route 10. In short, I like the is_in approach because keeps the network name simple. I'd rather not have to bother with the is_in tag at all. For someone mapping there is no confusion as to whether a highway is Canadian Route 10 or California Route 10 (unless they are really bad at geography), but I suppose this could get confusing for the renderers. Ideally, I would say a renderer should be smart enough to know where the US Canada boundary is and to render routes tagged with network: CA as a California route when in the US, and as a Canada route when in Canada. I don't know the details of how the renderers work though. Zeke I've never liked the is_in tag. It seems like a poorly-thought-out kludge, because the contents are not strictly defined, so it's useless for automated parsing. Instead of having the state name in the network tag, why not have network=us_county, state=CA, county=Marin, operator=Marin County, CA or something like that. The operator tag seems appropriate here, but I'm not sure about the contents. Alternate values for network could be us_interstate, us_highway or us_state. The interstate modifier (alternate, business, etc.) could go into a interstate_modifier tag. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Rendering of Place Names in Mapnik
On Thu, Dec 18, 2008 at 12:57 AM, Pieren pier...@gmail.com wrote: On Thu, Dec 18, 2008 at 1:37 AM, Karl Newman siliconfi...@gmail.com wrote: Maybe we need a tag for cultural value :-P Or use the admin_level tag. Pieren That wouldn't work in this case, because as the OP mentioned, San Jose and San Francisco have equal admin_level rankings (county seat) and San Jose is larger in both area and population. As an aside, San Francisco is unique in the USA (as far as I know) in that the city and county have the same extents. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Place Names in Mapnik
On Thu, Dec 18, 2008 at 6:37 AM, Adam Killian vi...@bonius.com wrote: Karl Newman wrote: That wouldn't work in this case, because as the OP mentioned, San Jose and San Francisco have equal admin_level rankings (county seat) and San Jose is larger in both area and population. As an aside, San Francisco is unique in the USA (as far as I know) in that the city and county have the same extents. Philadelphia is like this, too. It is the county seat of Philadelphia County http://en.wikipedia.org/wiki/Philadelphia_County,_Pennsylvania (with which it is coterminous) http://en.wikipedia.org/wiki/Philadelphia Hey, I learned something today. Guess I can stay home now. ;-) Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Place Names in Mapnik
On Thu, Dec 18, 2008 at 7:29 AM, Iván Sánchez Ortega i...@sanchezortega.eswrote: El Jueves, 18 de Diciembre de 2008, Karl Newman escribió: Maybe we need a tag for cultural value :-P Or use the admin_level tag. That wouldn't work in this case, because as the OP mentioned, San Jose and San Francisco have equal admin_level rankings (county seat) and San Jose is larger in both area and population. So, cultural_level tag? Ah, yes, I can see it now. The values could range from Barkada, Arkansas to Paris, France (Apologies to residents of Barkada) Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Place Names in Mapnik
On Thu, Dec 18, 2008 at 7:59 AM, Pieren pier...@gmail.com wrote: On Thu, Dec 18, 2008 at 4:29 PM, Iván Sánchez Ortega i...@sanchezortega.es wrote: El Jueves, 18 de Diciembre de 2008, Karl Newman escribió: Maybe we need a tag for cultural value :-P Or use the admin_level tag. So, cultural_level tag? Nothing more subjective ? ;-) Say the truth : we need a tag for rendering in case of name collision when the category (city) and admin_level (county seat) are the same (forget population which is even worst in this example). Just an idea : why not reusing the tag layer applying for same place levels ? San Francisco node: layer=1 Daly City node: (layer can be ommited) Pieren The discussion was between San Francisco and San Jose. The Daly City strangeness could be fixed by checking population. (Daly City ~100k, San Francisco ~800k). If we're going to tag for the renderer, why not just do it explicitly and call it render_priority (instead of abusing another tag with a different purpose)? Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Place Names in Mapnik
On Thu, Dec 18, 2008 at 8:12 AM, Gustav Foseid gust...@gmail.com wrote: On Thu, Dec 18, 2008 at 1:37 AM, Karl Newman siliconfi...@gmail.comwrote: That's the sort of thing automated renderers have difficulty sorting out. Maybe we need a tag for cultural value :-P (I would hazard a guess that San Jose has a larger economic impact, though.) I have suggested that the number of values for the hamlet/village/town/city hiearchy is incerased. Adding major_* and minor_* for village, town and city could be one way to solve some of the problems. - Gustav You're still missing the point about San Jose--it's larger in both area and population (and probably in economic activity as well), and is located within an hour's drive of San Francisco, but San Francisco is better known around the world and should arguably take priority in rendering. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Place Names in Mapnik
On Thu, Dec 18, 2008 at 8:43 AM, Gustav Foseid gust...@gmail.com wrote: On Thu, Dec 18, 2008 at 5:24 PM, Karl Newman siliconfi...@gmail.comwrote: You're still missing the point about San Jose--it's larger in both area and population (and probably in economic activity as well), and is located within an hour's drive of San Francisco, but San Francisco is better known around the world and should arguably take priority in rendering. My idea was that major_ could be used for a city of greater importance of some kind. Someone also suggested a value metropolis for the large metropolitan areas. I do not agree that using population or area is a good way to solve this problem. Finding population data for all named places is not easy (this problem extends beyond the largest cities) and population is not necessarily a good way to find the most important place name in an area. - Gustav Sure it is. If a lot of people want to live in a place, in general that should make it more notable. Besides, I was only suggesting using population as a tiebreaker for equal place key values. It's not the final answer, but it's objective and it goes a long way toward fixing the problem. I don't like your _major and _minor suffixes because they imply different population, which is not how you described it. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Place Names in Mapnik
On Thu, Dec 18, 2008 at 9:05 AM, Gustav Foseid gust...@gmail.com wrote: On Thu, Dec 18, 2008 at 5:58 PM, Karl Newman siliconfi...@gmail.comwrote: Sure it is. If a lot of people want to live in a place, in general that should make it more notable. Besides, I was only suggesting using population as a tiebreaker for equal place key values. It's not the final answer, but it's objective and it goes a long way toward fixing the problem. I don't like your _major and _minor suffixes because they imply different population, which is not how you described it. How do you suggest we find population for places? I can tell that a town is a regional center, without having to know it's population. Maybe major/minor is not the best names, however. How many values should we have for populated places? We have 4 now (hamlet/village/town/city). Should we add more? Reduce to fewer? Maybe just one? - Gustav Well, in the US, the population for cities is posted on the city limit signs. Or widely available in the internet, etc. Understand that this wouldn't be necessary for most places. If the population tag is missing, then we just get the behavior we have now, which isn't terrible but could be improved. I would argue for more granularity in place values. It's dominated on the low end of population (everything over 100k population is a city). And to me, there's plenty of room to subdivide town, too--there's a big difference in a place with 10,000 people vs. 99,999 people. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New mass imports over existing data
On Thu, Dec 18, 2008 at 6:16 PM, Beej Jorgensen b...@beej.us wrote: Hey all, This is sort of a general question with a specific example, namely, Marin County. Marin County (just north of the Golden Gate Bridge and San Francisco, California) already exists in OSM. It's made of bad TIGER data that has been partially corrected (by myself and others). Streams and trails have been added. Parks have been outlined. Now it has recently come to light that Marin County provides Free data covering the county, and this Free data is of excellent quality. Roads, trails, hydro, and even structure footprints are included. Now, there are a few courses of action I can imagine. 1. Indiscriminately blow away all of Marin and replace it with County data. If you made changes, tough luck. 2. Discriminately blow away specific pieces of the data and replace them with County data. For example, maybe just Mill Valley's roads could be replaced, because very little correction has been done there. 3. Using JOSM or somesuch, visually overlay the OSM data over the County data and manually adjust and add ways (cut-n-paste to add) as appropriate. I doubt there's a specific course of action that would work for all cases like we have in Marin County, but are there any other approaches people can think of, or pros or cons? -Beej Sonoma county (just to the north of Marin) seems to have free data available, too. As discussed with the Canada import, this would be a great opportunity to improve JOSM with tools for selective data merging. One of the better ideas I've seen is the possibility to copy individual elements from a GIS source layer to an OSM editing layer. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Place Names in Mapnik
On Wed, Dec 17, 2008 at 4:33 PM, Scott Atwood scott.roy.atw...@gmail.comwrote: On Wed, Dec 17, 2008 at 4:20 PM, Karl Newman siliconfi...@gmail.comwrote: I looked a bit at the osm.xml file for Mapnik. It currently orders them by the place tag hierarchy (city, town, suburb, village, hamlet/locality), but there doesn't seem to be any sorting within equal hierarchies (which is probably why you see Daly City instead of San Francisco at certain zooms). Ideally it could do this by population, with a bonus for capitals. The documentation for Mapnik indicates that it supports value comparisons, but it looks like the population would have to be stored in a column. Anyway, that seems like it would be the way to go. I don't think simple population ranking is necessarily the best option. There are other, more subjective factors that are important as well. For instance, San Francisco is smaller in terms of both population and land area than San Jose, and both are the county seat of their respective counties, yet due its economic, cultural, and historical importance, San Francisco should trump San Jose in case of a rendering collision. -Scott That's the sort of thing automated renderers have difficulty sorting out. Maybe we need a tag for cultural value :-P (I would hazard a guess that San Jose has a larger economic impact, though.) Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Viking vs. GMaps
On Sat, Dec 13, 2008 at 4:51 PM, Iván Sánchez Ortega i...@sanchezortega.eswrote: Hi all, It has come to my attention that Viking (that piece of software some of us use to see and manage our GPX tracks) has been banned from using Google Maps as a map background: http://sourceforge.net/mailarchive/forum.php?thread_name=492FFE74.6060405%40gmail.comforum_name=viking-devel Just so you know. -- -- Iván Sánchez Ortega i...@sanchezortega.es As some users on the forum posted, that's just more incentive to improve OSM. I've found it very useful to use OSM maps as a background in Viking when cleaning up my GPX tracks to see where existing data is and also to see if the track is reasonably accurate. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
On Wed, Nov 26, 2008 at 9:38 AM, John07 [EMAIL PROTECTED] wrote: Marc Schütz schrieb: Am Mittwoch 26 November 2008 17:56:15 schrieb Steffen Vogel: As a user and mapper of OpenStreetMap, I often use OpenStreetBugs. Unfortunatly this project is quity poor in features like: - email notification - duplicate handling - user handling - attachements (pictures, links, etc...) - search - filters - reports, charts statistics etc. Bug trackers like Bugzilla can cope with these requirements a lot better. What do you think about a migration of OpenStreetBugs to Bugzilla? Nevertheless OpenStreetBugs has a also some pros: - simplicity - integration in a slippy map and JOSM But I think it would'nt be hard to implement these pros to Bugzilla. Bugzilla as a backend would certainly be nice, but as a frontend it is obviously inappropriate. I don't know whether Bugzilla supports alternate frontends; if so, it could be worthwhile building one that fits our needs. IMO the most important advantage of OSB is its ease of use: there's no login required, you don't need to categorize your bug report etc. I think these features are important to keep in any new bug tracker we are going to use. +1 If it's tying in to a proper bug management system, classification could be a powerful addition. This classification could be done by bug wranglers based on the description typed by the reporter. So, I agree, the ease of use should be kept, but if desired, there could be an alternate Advanced form where the reporter could add the classification or other details (maybe a spot to optionally add their email address to track the bug status?). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Recommendations for a new GPS Device?
On Thu, Oct 16, 2008 at 10:42 AM, Johann H. Addicks [EMAIL PROTECTED] wrote: Someone is bound to say eTrex Legend HCx so let me be the first. Don't do that. I own one and can definitly say: The receiver is VERY crappy in terms of accuracy. As i use this device (Vista HCx) for geocaching, i was rather unsatisfied with the recorded tracks when i started comparing to the bigger GPSmap60 CSx of my mates. so i am running now in parallel for the osm-recording a SIRF3 logger (Royaltek RGM3800) which records decent tracks. So i can present you lot's of tracks to compare the quality. But off course, if you do not like to carry 2 devices, get a 60CSx and you will be happy. -jha- There was an issue with drift with the Vista HCx and Legend HCx with GPS chipset software versions 2.6 and 2.7 (note, not the same as the system software). The recently released GPS Chipset software 2.8 seems to have fixed these problems. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] barrier=gate
On Sun, Nov 9, 2008 at 10:33 AM, Nic Roets [EMAIL PROTECTED] wrote: On Sun, Nov 9, 2008 at 8:12 PM, Karl Newman [EMAIL PROTECTED]wrote: This is one of the major problems with the OSM community. Someone proposes or just starts using a particular tagging scheme which has some flaws. When those flaws are pointed out, That is by no means unique to OSM. Unix / C had a function called 'creat' for almost 30 years. The problem is that OSM has a lot of momentum (users remembering tags, tags being hardcoded into all kinds of software, hundreds of wikipages etc). So changing tags should not be done lightly. the OSM pragmatists just say Oh, we can always change it later. It's a Wiki, after all. But the truth is, you can't change it, because when someone does come up with an alternative tagging scheme (like barrier= or path= or crossing=) that shows some merit over the original, those same pragmatists come back and say What!? That tag is wrong/invalid/stupid because the database already has ten thousand entries of X. And besides, you'll break everything! Karl This is a strong argument for careful consideration before putting something into widespread use. Of course, this risks death by discussion but at least some opportunity for discussion should be given. In any case, definitely don't tell people Oh, we can always change it later when in fact we can't. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] barrier=gate
On Sun, Nov 9, 2008 at 11:14 AM, Dave Stubbs [EMAIL PROTECTED]wrote: On Sun, Nov 9, 2008 at 6:12 PM, Karl Newman [EMAIL PROTECTED] wrote: On Sun, Nov 9, 2008 at 2:24 AM, Dave Stubbs [EMAIL PROTECTED] wrote: On Sun, Nov 9, 2008 at 8:46 AM, Nic Roets [EMAIL PROTECTED] wrote: According to the wiki redirects, barrier=gate is replacing highway=gate. According to tagwatch, the latter is 10 times more popular than the former. Yes, because the barrier=gate people decided it makes more sense. I'm not sure a wiki redirect is the correct way of going about it... but they're essentially the same thing. Obviously highway=gate has been around much longer. Is the community OK with this ? Meh. If yes, why aren't we running a bot to perform the changes ? Because that would imply the One True Way is to tag gates with barrier=gate. Because it would break every existing gate out there relying on a legacy renderer. To get 1/10th already suggest to me shenanigans though. It's not completely impossible to have two tags for the same thing you know. Just leave it be. Dave This is one of the major problems with the OSM community. Someone proposes or just starts using a particular tagging scheme which has some flaws. When those flaws are pointed out, the OSM pragmatists just say Oh, we can always change it later. It's a Wiki, after all. But the truth is, you can't change it, because when someone does come up with an alternative tagging scheme (like barrier= or path= or crossing=) that shows some merit over the original, those same pragmatists come back and say What!? That tag is wrong/invalid/stupid because the database already has ten thousand entries of X. And besides, you'll break everything! There's a difference between coming up with a new tagging scheme, and changing every existing instance in the database. Note that I haven't actually at any point said that you shouldn't use barrier=gate. I've actually used it a few times myself, and it's not destructive on highway=gate. With path and crossing the proposals are somewhat incompatible with what was there already, and the merit in not making it compatible wasn't ever obvious. But there's an expectation here (or more lack of one): I know that if I use barrier=gate it's not going to get rendered on a lot of stuff. Fine, my choice, when enough data collects someone will probably patch the renderer. On the otherhand if I bot change everything immediately, I'm doing two things: I'm forcing everyone to do what *I* say, and also I'm making damn sure that gates won't be rendered. As a render author I have two choices... patch my renderer, or accuse you of blatent vandalism and revert your bot... which probably isn't somewhere we want to go. Dave My point is it's disingenuous to say There is no right or wrong or recommended tags on one hand, and then say Don't change X, you'll break everything. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] barrier=gate
On Sun, Nov 9, 2008 at 2:24 AM, Dave Stubbs [EMAIL PROTECTED]wrote: On Sun, Nov 9, 2008 at 8:46 AM, Nic Roets [EMAIL PROTECTED] wrote: According to the wiki redirects, barrier=gate is replacing highway=gate. According to tagwatch, the latter is 10 times more popular than the former. Yes, because the barrier=gate people decided it makes more sense. I'm not sure a wiki redirect is the correct way of going about it... but they're essentially the same thing. Obviously highway=gate has been around much longer. Is the community OK with this ? Meh. If yes, why aren't we running a bot to perform the changes ? Because that would imply the One True Way is to tag gates with barrier=gate. Because it would break every existing gate out there relying on a legacy renderer. To get 1/10th already suggest to me shenanigans though. It's not completely impossible to have two tags for the same thing you know. Just leave it be. Dave This is one of the major problems with the OSM community. Someone proposes or just starts using a particular tagging scheme which has some flaws. When those flaws are pointed out, the OSM pragmatists just say Oh, we can always change it later. It's a Wiki, after all. But the truth is, you can't change it, because when someone does come up with an alternative tagging scheme (like barrier= or path= or crossing=) that shows some merit over the original, those same pragmatists come back and say What!? That tag is wrong/invalid/stupid because the database already has ten thousand entries of X. And besides, you'll break everything! Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=track and motorcar=yes/no
On Sat, Nov 8, 2008 at 2:55 AM, Pieren [EMAIL PROTECTED] wrote: On Sat, Nov 8, 2008 at 9:52 AM, Mario Salvini [EMAIL PROTECTED] wrote: you mean: http://wiki.openstreetmap.org/index.php/OSM_tags_for_routing/Access-Restrictions http://wiki.openstreetmap.org/index.php/OSM_tags_for_routing/Maxspeed Exactly ! Great job. My point is that: - such tables should be grouped in a way that software applications could easily parse the data into their configuration; On Fri, Nov 7, 2008 at 5:43 PM, Karl Newman [EMAIL PROTECTED] wrote: Because using borders to locate entities within countries/states/regions/cities is a Hard Problem which has yet to be solved satisfactorily in OSM Locate entities for gis applications is easy, not a hard problem. The problem is only that many countries haven't closed borders today. But locating entities within a country will work properly soon or later in OSM. Pieren Well, OSM has not solved this yet, so it's apparently not easy. There still is some disagreement over what constitutes a country border. Also, you assume that a user has all the borders for the entire planet loaded into a GIS application or database, and also that all the borders are good (which they're not). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=track and motorcar=yes/no
On Fri, Nov 7, 2008 at 8:00 AM, Pieren [EMAIL PROTECTED] wrote: On Fri, Nov 7, 2008 at 4:30 PM, sylvain letuffe [EMAIL PROTECTED] wrote: highway=pedestrian ; bicycle=yes/no = see [[Country specific default values]] Well, the wiki page didn't exist - it was just an idea/suggestion ... World-wide only defaults and no country defaults will simply not work: If you don't have a country specific default then your application will use the worl-wide default. Back to the example, highway=pedestrian is by default not allowed for bicycles (bicycle=no). This can be documented in the wiki page Tag:highway=pedestrian. If later, we see that many, many countries allows bicycles on pedestrian highways then we might decide to change the world-wide default as 'bicycle=yes' and the few countries where it's not allowed should appear in the page [[Country specific default values]]. Pieren Because using borders to locate entities within countries/states/regions/cities is a Hard Problem which has yet to be solved satisfactorily in OSM, what about tagging the ways with access_rules=ruleset? Then the rules could easily be changed by country or region if the respective government decides to modify the rules. Absent the tag, it would mean the global defaults apply (along with any explicit modifiers). Yes, it would mean an extra tag on every way, but only one extra, not 5. If it were done cleverly, you could make it hierarchical, with global default access rules at the top, followed by, for example, modifications for Germany, followed by modifications for Bavaria, followed by modifications for Munich. Then you would just tag the ways access_rules=Munich (or Muenchen, whatever). It has the advantage over using government borders in that it could even support variations which may not be locality-based (i.e., US_rural or US_urban). Something similar could be done for applying national speed limits. Instead of just maxspeed=national, make it maxspeed=UK_national or England_national or however it works. Sincerely, Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] footway vs. path [Was: highway=track and motorcar=yes/no]
On Thu, Nov 6, 2008 at 3:28 PM, Thomas Wood [EMAIL PROTECTED]wrote: 2008/11/6 Rainer Dorsch [EMAIL PROTECTED]: Am Mittwoch, 5. November 2008 schrieb Alex Mauer: Rainer Dorsch wrote: I am wondering what is the difference between footway and path? sac_scale on http://wiki.openstreetmap.org/index.php/Map_Features seems to apply for both. Does that mean a mountain hiking path can be a path or a footway? Are paths larger than footways? Is it for paths required that any other vehicle/horse can use the path otherwise it is a footway? There is no defined physical difference between footway and path. The difference is that footways are primarily or exclusively for use by foot traffic, while paths are not. That seems to be in contrast to josm presets: In Presets-Ways all Hiking paths are highway=path, none of them is highway=footway. Rainer = The JOSM presets are wrong. Come on, you should know better than that. This is OSM. There is no right and wrong. Sheesh. Absolutist. ;-) Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Weird Osmosis/ROMA/pgsql issue
On Thu, Nov 6, 2008 at 10:15 AM, Milenko [EMAIL PROTECTED] wrote: Hey all, I've been trying to get a local ROMA server working and I've run into an issue with getting osmosis working. I've patched osmosis as per the instructions on the wiki (http://wiki.openstreetmap.org/index.php/Read_Only_Map_API), but when I import data into the pgsql database, I'm still seeing statements in the db log files that reference commands taken out by the patch. One specific command is UPDATE ways SET bbox = (SELECT Envelope(Collect(geom)) FROM nodes JOIN way_nodes ON way_nodes.node_id = nodes.id WHERE way_nodes.way_id = ways.id), seen in PostgreSqlWriter.java. I've verified that it's removed from that file but it still runs when I try to import data. This command takes days when trying to import the full planet. Anyone have any idea how this is happening? I've searched every file in the osmosis directory and can't find that command, and yet it still somehow gets run during the import. Any help would be greatly appreciated. -Jeremy Are you sure you're actually executing your patched version and not an unpatched version that's somewhere on your path? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Weird Osmosis/ROMA/pgsql issue
On Thu, Nov 6, 2008 at 10:42 AM, Milenko [EMAIL PROTECTED] wrote: I thought able that, but this is a freshly loaded machine and I've only ever downloaded this one copy of osmosis. Just for fun, I just did a file search for osmosis-0.29 and found only the one directory that I've been working in. -Jeremy *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Karl Newman *Sent:* Thursday, November 06, 2008 1:16 PM *To:* Milenko *Cc:* talk-us@openstreetmap.org *Subject:* Re: [Talk-us] Weird Osmosis/ROMA/pgsql issue On Thu, Nov 6, 2008 at 10:15 AM, Milenko [EMAIL PROTECTED] wrote: Hey all, I've been trying to get a local ROMA server working and I've run into an issue with getting osmosis working. I've patched osmosis as per the instructions on the wiki (http://wiki.openstreetmap.org/index.php/Read_Only_Map_API), but when I import data into the pgsql database, I'm still seeing statements in the db log files that reference commands taken out by the patch. One specific command is UPDATE ways SET bbox = (SELECT Envelope(Collect(geom)) FROM nodes JOIN way_nodes ON way_nodes.node_id = nodes.id WHERE way_nodes.way_id = ways.id), seen in PostgreSqlWriter.java. I've verified that it's removed from that file but it still runs when I try to import data. This command takes days when trying to import the full planet. Anyone have any idea how this is happening? I've searched every file in the osmosis directory and can't find that command, and yet it still somehow gets run during the import. Any help would be greatly appreciated. -Jeremy Are you sure you're actually executing your patched version and not an unpatched version that's somewhere on your path? I don't know anything about the patch, but did you look in the script directory, at the pgsql_simple_load_0.5.sql file? That command is in there (spread over multiple lines, which is why a grep may not have found it). Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Proposed Relations
On Wed, Nov 5, 2008 at 3:38 PM, Frederik Ramm [EMAIL PROTECTED] wrote: 2. Make sure the big three editors support ordering. Nobody will notice, nobody has to change what he does. Also, try and get Osmosis and the various mirror services (ROMA, XAPI) to support ordered relations. I can confirm that Osmosis already maintains the order of relations. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
On Mon, Nov 3, 2008 at 4:34 PM, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, Shaun McDonald wrote: Relations are unordered. You could load the relation and all the ways referenced by it, then check to see if each way has another way that has the same start and end nodes, through a process of stitching. 1. Shaun is right BUT 2. I want relations to become ordered and will try to sneak this into API 0.6; there will be no noticeable change for any API client, just that it so happens that things are returned in the order you put them in, rather than in any order. The rationale behind that is that people start (ab)using the role attribute for that (e.g. a bus route with nodes that have the roles stop1, stop2, stop3 etc.), which of course is a pain to modify. If you're sneaking relation changes into the API, could you also allow a member to be repeated? This would be useful in describing a prohibited U-turn on a single carriageway. The same way would need to be in both the from and to roles, which I believe is currently prohibited. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] labels for roads with or without sidewalks
If you try sidewalk:left=true, it might work. I know someone put some work into automatically switching tags on way reversal, but I'm not sure if it went into a plugin or the core. Karl On Sun, Nov 2, 2008 at 5:33 PM, Dale Puch [EMAIL PROTECTED] wrote: Quick test of JOSM = nope I tried footpath, cycleway, sidewalk = left and it did not alter it at all with reversing the way. Being in the US there is also tiger:zip_left and zip_right that were not changed either. So this is an area that at least JOSM could be improved on. Dale On Sun, Nov 2, 2008 at 7:04 PM, Russ Nelson [EMAIL PROTECTED] wrote: Adam Schreiber writes: [1] http://wiki.openstreetmap.org/index.php/Proposed_features/Sidewalk Ooohh, I wonder if JOSM[1] knows about these kinds of tags? In particular if I say Reverse Way, will it change the lefts to rights and the rights to lefts? [1] Or your favorite OSM editor. -- --my blog is athttp://blog.russnelson.com | Delegislation is a slippery Crynwr sells support for free software | PGPok | slope to prosperity. 521 Pleasant Valley Rd. | +1 315-323-1241 | Fewer laws, more freedom. Potsdam, NY 13676-3213 | Sheepdog | (Not a GOP supporter). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] hospital with emergency=yes/no
On Tue, Oct 28, 2008 at 2:55 PM, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, there was a proposal on the Wiki about two years ago about a possible extra tag emergency for hospitals, to signal whether they have an AE (or ER, U.S.) facility. The proposal was voted through at the time but there were procedural doubts (something like 5 pro and 1 contra vote or so) and the proposal remained in limbo and was recently flagged abandoned by User:Chriscf. Meanwhile, since the emergency tag obviously makes a lot of sense, it has been used about 80 times in conjunction with hospitals in Europe. I'll therefore move that on to the Map Features page unless someone has a good reason against it. See here for details of the old proposal: http://wiki.openstreetmap.org/index.php/Proposed_features/Hospital:_Emergency Bye Frederik What about a possible emergency access tag? It could cause a name conflict. At the least, the tag could be vague if it appears separate from a hospital node. What about emergency_service or emergency_department or emergency_room? Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Tiger 2007 Data
On Tue, Oct 28, 2008 at 7:12 AM, Nick Hocking [EMAIL PROTECTED]wrote: Well, #2 would be nice but it would be tricky to detect a collision with an existing way. Frankly, because the first TIGER import was done, the number of completely new ways that would be added in a new import would be small, and the number of those ways that conflict with ways added manually by editors would be even smaller. So, I think it's a small sacrifice to have to remove a few duplicated roads in exchange for county-wide improved accuracy. Karl, I agree #2 could be tricky but I believe it is essential. I don't think you can corrupt someones edits and then say to them sorry, we decided to sacrifice your hard work because we determined that it was for the greater good. I don't see it as corrupting. It's not mangling the mapper's work in any way. If they don't like the new overlapping road, then just delete the TIGER one. It hope that is not the OSM way. My sense is that the OSM way is do it your damn self. Also I despute your statement of a few but notwithstanding that, this is not a numbers game.. I have to admit I don't have hard numbers to back up my statement, but intuitively, how many roads would have been added in 2 years? I'm sure there are some statistics somewhere stating the number of roads in TIGER 2005 (2004?) and in TIGER 2007. That would give a magnitude to the issue. gee officer - I only killed a few people - there are hundreds left is not going to get you very far. Really? You're going to compare overlapping ways with a capital crime? Still, I will say that if the numbers of duplicated way are so few then I think that the person who creates the duplicated ways should also fix them up. Then I'd have no problem with the uploads so long as rules 1 and 3 are also kept. That goes back to *detecting* the overlapping ways. Can be done by JOSM's validator, so maybe there's hope. Maybe it could be done like Dave handled the last import--if anyone is concerned about conflicts, they can handle their county themselves. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] [Talk-us] Tiger 2007 Data
On Sun, Oct 19, 2008 at 10:54 AM, Dave Hansen [EMAIL PROTECTED] wrote: Has anyone looked at importing the TIGER 2007 data yet? I was going to start coding up the conversion utilities to get started. It appears that this shapefile format may have existing OSM converters out there. Anyone want to admit to having one? ;) -- Dave What were you looking to import? I thought your TIGER import was a one-shot deal. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Tiger 2007 Data
On Sun, Oct 19, 2008 at 11:14 AM, Dave Hansen [EMAIL PROTECTED] wrote: On Sun, 2008-10-19 at 11:10 -0700, Karl Newman wrote: On Sun, Oct 19, 2008 at 10:54 AM, Dave Hansen [EMAIL PROTECTED] wrote: Has anyone looked at importing the TIGER 2007 data yet? I was going to start coding up the conversion utilities to get started. It appears that this shapefile format may have existing OSM converters out there. Anyone want to admit to having one? ;) -- Dave What were you looking to import? I thought your TIGER import was a one-shot deal. I *wish* it was a 1-shot deal. That darn Steve C. seems to think that maps should be both accurate *and* up to date. The nerve! Anyway, it seems that the new data is substantially better than the old in some places. What I'd like to do is twofold: 1. regenerate .osm files for all the new TIGER data 2. Compare new .osm files to old TIGER data plus stuff edited in OSM Then, decide how if/when it is appropriate to write over the old TIGER stuff with new. Or, to merge it somehow. -- Dave Ah. Quite a trick... I seem to recall that somebody had wanted to do that earlier, but I think they got discouraged by the difficulty. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Tiger 2007 Data
On Sun, Oct 19, 2008 at 11:14 AM, Dave Hansen [EMAIL PROTECTED] wrote: On Sun, 2008-10-19 at 11:10 -0700, Karl Newman wrote: On Sun, Oct 19, 2008 at 10:54 AM, Dave Hansen [EMAIL PROTECTED] wrote: Has anyone looked at importing the TIGER 2007 data yet? I was going to start coding up the conversion utilities to get started. It appears that this shapefile format may have existing OSM converters out there. Anyone want to admit to having one? ;) -- Dave What were you looking to import? I thought your TIGER import was a one-shot deal. I *wish* it was a 1-shot deal. That darn Steve C. seems to think that maps should be both accurate *and* up to date. The nerve! Anyway, it seems that the new data is substantially better than the old in some places. What I'd like to do is twofold: 1. regenerate .osm files for all the new TIGER data 2. Compare new .osm files to old TIGER data plus stuff edited in OSM Then, decide how if/when it is appropriate to write over the old TIGER stuff with new. Or, to merge it somehow. -- Dave Ah. Quite a trick... I seem to recall that somebody had wanted to do that earlier, but I think they got discouraged by the difficulty. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Yet another street number scheme
On Thu, Oct 16, 2008 at 9:28 AM, Andy Allan [EMAIL PROTECTED] wrote: On Thu, Oct 16, 2008 at 6:28 AM, Karl Newman [EMAIL PROTECTED] wrote: Just to reiterate my perspective, the Karlsruhe schema is fine for what it is, but it's not sufficient for all uses. Perhaps not natively, but I don't see why it can't be converted into interpolated-on-street during processing? I don't know of any use of OSM data that doesn't require *some* level of processing. On the other hand, putting the information directly on the street limits the ability to produce useful things like maps with numbers on the building outlines. So I'd say we should go for numbers on houses (e.g. Karlsruhe scheme), and downgrade using post-processing to numbers on streets whenever there's such desire / technological limitations. Cheers, Andy That's the problem--the Karlsruhe schema does not lend itself to that sort of transformation very well. And it requires a stupid amount of preprocessing if it's going to be used. There is nothing to associate the node to the street other than MAYBE the name, which is pretty poor for a relational data model. It could be misspelled or linked to the wrong street with a similar name or even just the wrong section of the street. Also, consider the case where a road makes a tight U-turn, and the address node is placed somewhere in the middle. It's entirely possible (in fact, I can guarantee it will happen somewhere in the world) that the the node will be associated with the wrong portion of the street. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Yet another street number scheme
On Tue, Oct 14, 2008 at 10:36 PM, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, Karl Newman wrote: No, that would be tagging for actually being able to use the data. Without the odd/even/both information, it's actually a loss of data. Sounds quite strange to me. Any interpolation rule and odd/even/both rule is only a workaround for devices or schemes unable to fully depict reality - it is not information added, but an attempt at generalization dictated by shortcomings in devices or algorithms. Bye Frederik You might call it a workaround, but it's certainly a common approach. Many major GIS systems (including the TIGER data set) use this exact methodology. Not including this information will make OSM data less useful on these legacy devices. Garmin is the #1 handheld GPS manufacturer by a wide margin, and if we can get fully-featured OSM maps (including routing, turn restrictions and street addresses) onto Garmin GPS receivers, we can attract a lot of dedicated, detail-obsessed mappers (especially the geocaching crowd). Just to reiterate my perspective, the Karlsruhe schema is fine for what it is, but it's not sufficient for all uses. You can pretend that address numbers don't belong to the street they're on (!) but there are a ton of existing navigational devices and software (probably all of them) that do, in fact, treat them like that. And even future devices designed from the start to use OSM data might want to have some optimizations to limit the amount of storage processing dedicated to address numbers. It's a reality we should accept and accommodate. I mean, really, are we trying to guide a smart bomb to someone's doorstep? For navigational devices, locating the spot a relative distance along a street is exactly what users expect. They're not going to drive to the front door. (I'll grant you that there are other uses for that data than just for navigational devices.) Sorry for the rambling. I'm sleep-deprived with a newborn. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Yet another street number scheme
On Mon, Oct 13, 2008 at 5:41 PM, Frederik Ramm [EMAIL PROTECTED] wrote: snip As for the efficiency in storage, I suggest you take the long-term view: I am 100% sure that at some point in the future, OSM will have at least one node for every house, more likely a building outline for every house. Look at this if you don't believe me: http://informationfreeway.org/?lat=51.03267406093207lon=13.718639663339111zoom=15layers=BF000F At this point it will be trivial (easy to edit, easy to handle, and requiring little extra storage) to simply add a house number tag to every one of these buildings. Any sort of complex relations for roads with interpolation rules for house numbers will then simply be unnecessary. That's not really true, because there are devices (such as Garmin GPS receivers) on which we would like to use OSM data, which need address numbers in a compact format with interpolation rules. Trying to reverse-engineer the scheme (odd, even, both, etc.) from single nodes that aren't even part of the way is nigh-impossible, or at the least, wastefully compute-intesive and error-prone. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Yet another street number scheme
On Tue, Oct 14, 2008 at 9:17 AM, Andy Robinson (blackadder-lists) [EMAIL PROTECTED] wrote: Karl Newman wrote: Sent: 14 October 2008 4:59 PM To: Frederik Ramm Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] Yet another street number scheme On Mon, Oct 13, 2008 at 5:41 PM, Frederik Ramm [EMAIL PROTECTED] wrote: snip As for the efficiency in storage, I suggest you take the long-term view: I am 100% sure that at some point in the future, OSM will have at least one node for every house, more likely a building outline for every house. Look at this if you don't believe me: http://informationfreeway.org/?lat=51.03267406093207lon=13.718639663 339111zoom=15layers=BF000F At this point it will be trivial (easy to edit, easy to handle, and requiring little extra storage) to simply add a house number tag to every one of these buildings. Any sort of complex relations for roads with interpolation rules for house numbers will then simply be unnecessary. That's not really true, because there are devices (such as Garmin GPS receivers) on which we would like to use OSM data, which need address numbers in a compact format with interpolation rules. Trying to reverse- engineer the scheme (odd, even, both, etc.) from single nodes that aren't even part of the way is nigh-impossible, or at the least, wastefully compute-intesive and error-prone. However, houses are not part of the road network, so the house number node should not be part of the highway, that would be tagging for the Garmin or whatever. The house numbers need to go on the houses (or the object representing them). Cheers Andy No, that would be tagging for actually being able to use the data. Without the odd/even/both information, it's actually a loss of data. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On Tue, Oct 14, 2008 at 11:05 AM, Tristan Scott [EMAIL PROTECTED] wrote: If this catches on not only do we have a well-defined and easily-processed value for speed to use in all manner of things, we also have a template for defining other data types (bridge height? maxweight?) which might (or might not) make the job of the data processor for an map consuming application (satnav etc) much easier. Tristan 2008/10/14 David Earl [EMAIL PROTECTED] On 14/10/2008 18:26, Tristan Scott wrote: Given that SI units are standard across OSM could be define a speed value in addition to Numeric String etc like so: (default to kmh as specified before (also means not adding millions of pointless kmh strings to the db) Factor means multiply by this to convert to SI - interpreters would either use value as-is or multiply by Factor for that suffix to get SI units. Suffix is the entire string after the numerical value, with whitespace trimmed - so spaced/not spaced suffix wouldn't matter - defining this rigidly would be ignored by most users, i suspect My proposed table: Unit - Factor - 1 kmh - 1 mph - 1.609 knots - 1.852 +1. I really don't see what all the fuss is about. It's not exactly novel to do it this way: CSS puts units as part of the value. It's what I've been doing all along, except some pedant comes along and changes it to some incomprehensible decimal number almost as soon as I add them to the map (which means I can carry on doing it that way even if others think differently, as they'll get converted automatically as far as i am concerned and I don't have to think about a magic number in km/h). David What about just using the maxspeed tag with just a number and having a separate tag for the units. i.e., maxspeed=30; maxspeed_units=mph Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] lanes
On Sun, Oct 12, 2008 at 9:13 AM, Gervase Markham [EMAIL PROTECTED]wrote: graham wrote: - Say I have a bus lane (or cycle lane) running along one side of a two-way road (the most common situation where I am). Just attaching a 'left' tag to it makes it dependent on nobody ever reversing the arbitrary direction attached to the way. No, it doesn't, because editors would make flipping the left/right part of the reverse way command, just as they now flip oneways and so on. There are various consistency checks editors need to do when making changes - this is just another one. - More serious, I think: it just feels quite arbitrary as a solution: I would have to tag a lane as being 'left' in relation to the random direction the arrows on the way happen to be pointing, rather than in relation to anything in the real world. How else do you unambiguously intrinsically define the side of a way? Unless it's a closed way, where you have inside and outside, the only way is to give it a direction (which it has) and say right or left. You can define it extrinsically using things like north or west but that runs into problems with roads which curve, or even run in a circle. 2. have an 'origin' tag to be used on the first node of a way independent of direction; if the way direction flipped, the origin would stay in place. 'Left' or 'right' would be in relation to the origin node. Still completely arbitrary where the origin goes, and how do you find it on a long way? If my proposal has disadvantages, then this has them all but adds some new ones too :-) 3. Make more of a separation between internal representation of ways and user views in josm/potlatch. All ways have a direction which is independent of the 'arrowed' direction which can be displayed to users, and is fixed - a totally arbitrary value used only as a fixed reference. Why? Why not just use the arrowed direction? After all, it's not exactly complicated to flip tags when you change the direction of the way. That's why the scheme is generic :left and :right - so it can be used on any tags. Gerv Just as a note, someone already added automatic left/right tag changing to JOSM when a way is reversed. It works for a few different schemes, including :left and :right. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] NHD status?
On Thu, Oct 2, 2008 at 7:57 AM, Ian Dees [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 9:51 AM, Doug Morrison-Cleary [EMAIL PROTECTED]wrote: Nooo. I live in northern MN and all we have around here are lakes! I really want them in yesterday grin. Please :-) Ok I suppose I should have been more explicit. The lakes and river areas seem to be the easiest to tag in OSM. They are bodies of water. The sticky parts are the marshes and canals/drainage ditches. Perhaps we could just start an import with tags that make sense for these things (e.g. natural=marsh). Either that or we only import the FCode/FTypes that have an obvious OSM tagging scheme right now and import the other stuff later. I think you should import everything. Maybe. I'm not fully versed in the NHD, and I understand it has some things like flood channels which are filled only during 100-year floods or something... But even the more obscure water features might be useful to someone. Anyway, where the OSM tags line up, use those, otherwise you could invent some tags (like someone mentioned, hydrology or hydrography as a key name is a possibility, especially for things like flowlines which probably shouldn't be on the default map). I think you should always include a nhd:ftype and/or nhd:fcode tag to link back to the source. Otherwise you might force fit a bunch of fine-grained NHD categories into one broader OSM tag and then we would lose detail. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] clean gpx tracks
On Thu, Sep 25, 2008 at 5:35 AM, Lambert Carsten [EMAIL PROTECTED] wrote: Hi, I tried to upload a couple of gpx tracks that I had cleaned up with Josm. They were refused with a message that seems to suggest thy are missing time stamps (possibly missing altitude). Why does openstreetmap want timestamps? There is no reason for this. I want to clean up my tracks to prevent uploading garbage from when I forgot to switch off my logger. I know in time (in theory at least) the garbage will be lost as noise behind good data. But where I collect data (mostly Amsterdam) there is already so much garbage and bad tracks in many area's rendering those tracks useless. In other area's there are no tracks at all and and these are exactly the area's I am trying to locate and track. Also I hope by adding more good tracks the balance will tip in favor of the good data. What is the reasoning here? There is also a privacy advantage not uploading the unnecessary time stamps. I am sure there are many that hesitate to upload tracks for privacy reasons. If the problem is with the missing altitude: some of my original trackpoints had an altitude of of over 6km in the Netherlands!! I can solve my problem by not uploading my tracks anymore and just use them personally to enter osm data. At least with my own tracks I know which bits are good, which are so so and which bits are bad. But I thought the whole point was to share all this data. Maybe someone can point me to some editor with which I can easily clean up the tracks without clearing out the time stamps (personally I don't have a problem uploading that info). Lambert Carsten Check out Viking (viking.sf.net). I've used it to clean up my tracks (for the privacy reasons you mention). It supports OSM tiles for background map display, and allows you to upload your tracks to OSM from within the program, too. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] clean gpx tracks
On Thu, Sep 25, 2008 at 8:45 AM, Lambert Carsten [EMAIL PROTECTED] wrote: On Thursday 25 September 2008 17:21:59 Richard Fairhurst wrote: Lambert Carsten wrote: This decision needs more thought. Although I personally don't have a privacy issue here there are clearly those that do Just don't set your track as public - then the timestamps won't be exposed. I am not looking to just solve my own personal 'problem'. What concerns me is that someone has made a decision that doesn't seem to be motivated and it is unclear (to me at least) who made it. I think that is a problem for an organization like openstreetmap. The issue itself is not insignificant for more than one reason. My concern is about good data and this 'rule' makes it a lot harder for me to upload clean data. Others might be concerned about privacy and change the data. And others again might not make their data available to save themselves the hassle of changing the data. Lambert The GPX tracks are intended to show the basis for the ways and other data that is in the database, so I think one motivation for timestamps hearkens back to a desire to show your work to defend the source of OSM data against potential future claims of copyright infringement. In other words, with timestamps, it's more plausible that it was collected with an actual GPS receiver, instead of mocked up into GPX from some tainted source (with a license not compatible with OSM). Obviously timestamps could be synthesized (and I think there are even scripts that will do it for you if you want to upload your timestamp-less GPX tracks to OSM), but anyway, that's one reason I seem to recall why timestamps are required. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] US GPS Set for Mapping Parties
On Thu, Sep 25, 2008 at 9:03 AM, Adam Schreiber [EMAIL PROTECTED] wrote: On Thu, Sep 25, 2008 at 11:49 AM, Ian Dees [EMAIL PROTECTED] wrote: On Thu, Sep 25, 2008 at 10:46 AM, Adam Schreiber [EMAIL PROTECTED] wrote: On Thu, Sep 25, 2008 at 11:12 AM, Ian Dees [EMAIL PROTECTED] wrote: On Thu, Sep 25, 2008 at 10:02 AM, Adam Schreiber [EMAIL PROTECTED] wrote: Would there be any interest in getting together a box of GPS devices to be sent around for North American mapping parties similar to what they have across the pond? [1] Maybe Garmin would sponsor something? [2] I will start a sponsorship request form now unless someone else has already done so. Does anyone know if the OSM Foundation is a 501(c)3 org here in the US? Perhaps we should start one... I'm not sure how non-profits incorporated in a different country are handled in the US. I suppose you're saying set up a OSM US Foundation to facilitate such donations? This might also be good if there were ever to be a US mirror of the API/tile serving. Also, what are our job titles and when are all of the US mapping parties? The currently planned Clemson, SC party is Oct 11, which is within their 6 week window. Adam If you're going to approach Garmin, and you have a choice, see if you can get the 60CSx series, because the new eTrex HCx series and the Garmin Colorado have significant drift problems where under challenging reception conditions (i.e., tree cover or urban canyons), the reported position can drift away from your true position by up to 700 feet in some cases. It will sometimes recover on its own after a long time, but a power cycle will fix the problem immediately. However, it's sometimes difficult to tell when it's occurring, so it would be bad to get invalid data for OSM use. There is also the new Oregon touchscreen device which uses a different GPS chipset and doesn't have the same problems, but it is still new and its accuracy not fully trusted yet. I'm not sure how excited Garmin will be to sponsor OSM anyway, since one of the ultimate uses of this project is to supplant the maps you currently have to buy from Garmin to use on their GPS receivers. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Using CDN for Tiles
On Mon, Sep 22, 2008 at 10:43 AM, Kyle Gordon [EMAIL PROTECTED]wrote: Dirk-Lüder Kreie wrote: Ian Dees schrieb: Hi list, Just saw this pop up in my RSS reader: http://aws.typepad.com/aws/2008/09/were-never-cont.html Maybe we could throw the Mapnik tiles up on Amazon's content delivery network so that they arrive quickly. There are other CDNs that we could use, and which might be cheaper, too, for example the Coral CDN, which works by simply appending .nyud.net to your URL's host part, and is AFAICS free, as in beer. Maximum TTL of objects on Coral seems to be 24hrs, soo that's nice for our tiles, too. Coral seems to be the obvious choice for this sort of thing. Can anyone come up with some more pros and cons for it? Pros: Has been seen to cope with major /. events, free, simple Cons: uurm... Cheers Kyle Cons: It's never, ever worked for me, across different computers and networks... I have no idea why. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Using CDN for Tiles
On Mon, Sep 22, 2008 at 11:44 AM, Ian Dees [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 1:36 PM, Karl Newman [EMAIL PROTECTED]wrote: Cons: It's never, ever worked for me, across different computers and networks... I have no idea why. It does some DNS magic that seems to be unstable for me, too. It never worked until I switched to using OpenDNS. Hmm... I don't think I've tried it from home since I switched my router to use OpenDNS. I'll have to try again. Regardless, because of the spotty availability, I don't think this is a good way to go for a primary OSM content delivery system. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Large Hadron Collider at CERN now in OppenStreetMap
On Wed, Sep 10, 2008 at 1:57 AM, Andy Robinson (blackadder-lists) [EMAIL PROTECTED] wrote: Its not perfectly positioned and I think the circumference is a tad short but I made a reasonably good insert of the CERN LHC (and SPS) into the database last night in time for the first full circle beam test of the LHC, which has just successfully completed. So, for anyone wanting to know exactly where the two accelerator rings are in the world it's now possible to point them to OpenStreetMap. Another first for community mapping :-) http://www.openstreetmap.org/?lat=46.2731lon=6.073zoom=12layers=0B00FTF I hope the data made the planet dump (JIT), in which case it should appear also on the Mapnik layer shortly. For now the two rings are tagged with highway=trunk and highway=primary respectively. They also carry tunnel=true of course. There are a couple of big notes tagged as well that confirm the highway tag is less than ideal and that something better needs to be used. But for now, since they don't connect with the road network I don't think anyone will be routing over them ;-) enjoy Cheers Andy Not sure if you should be chastised for tagging for the renderer or commended for the PR effort :-P Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] amenity=vending_machine AND amenity=post_box: what about?
On Sun, Sep 7, 2008 at 10:53 PM, Norbert Wenzel [EMAIL PROTECTED] wrote: Shaun McDonald wrote: The problem with this is that none of the editors support having duplicate key values, even so the 0.5 API supports it. The 0.6 API will not support duplicate key values. I think the support of duplicate keys is a very much needed feature and I personally would drop it only, if there are really good reasons (e.g. breaking fast queries, etc.) to drop it. It would be possible to tag something like amenity=supermarket; post_office; but as stated in another discussion yesterday that would make searching for entries much more complicated. Just to name a few very common cases where duplicate keys would be necessary I'd like to point out the very common case of hotels also having a publicly available restaurant. Of course one could draw a building and drop all needed amenities inside, but I think that wouldn't be routable unless you add the addr: properties to every node inside that building. So personally I think duplicate keys would be the easiest and best way to tag such double-uses. Norbert Just make two different nodes, each located closest to the amenity concerned. There's nothing that makes it non-routable. It's just a point--the routers will get you as close to the point on the road as possible. The addr: property definitely isn't going to help in making it routable. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] amenity=vending_machine AND amenity=post_box: what about?
On Mon, Sep 8, 2008 at 10:33 AM, Norbert Wenzel [EMAIL PROTECTED] wrote: Karl Newman wrote: Just make two different nodes, each located closest to the amenity concerned. There's nothing that makes it non-routable. It's just a point--the routers will get you as close to the point on the road as possible. The addr: property definitely isn't going to help in making it routable. You're right with the addr: property, that was not well thought from my side. But I'd nevertheless prefer the double amenities, just because the that's what those nodes are. One building or machine with multiple uses at the very same place. Norbert I understand your concern about overlapping icons, but in a device such as a GPS, it will be considered as two separate points of interest (POI), because it really is two different services (or amenities or whatever); they just happen to be at the same location. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tech/API] Accessing tags set by a user for traces
On Fri, Aug 29, 2008 at 5:48 PM, robin paulson [EMAIL PROTECTED]wrote: Robert (Jamie) Munro wrote: Scale wise we have about 250,000 tag records currently, and even if you remove the duplicates there are about 40,000 or so. I don't think people are going to want to download 40,000 tags even if we wanted to let them. Any chance of a report of the most popular tags, or would it lock up the database for ages just to query them? \http://wiki.openstreetmap.org/index.php/Tagwatch does just that The original question was about the tags used for GPX traces, not about general tagging. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tech/API] Accessing tags set by a user for traces
On Thu, Aug 28, 2008 at 9:08 AM, Tom Hughes [EMAIL PROTECTED] wrote: Guilhem Bonnefille wrote: I'm working on Viking[1], a GPS desktop application with OSM related features. In order to assist user when uploading its traces to OSM, I wish to contact OSM, retrieve the previously used tags, and propose these tags to the user for the new trace. Is there such API actually? No, and I don't think one would be practical. To start with we don't currently normalise the tags at all so there is lots of duplication in the tag table - the only way to get a list of tags is to select distinct on the tag column. Scale wise we have about 250,000 tag records currently, and even if you remove the duplicates there are about 40,000 or so. I don't think people are going to want to download 40,000 tags even if we wanted to let them. Tom What about getting a list of tags that the user had previously used? (i.e., SELECT DISTINCT ... WHERE UID = ...). That's certainly smaller than 40,000. Or maybe not even select distinct, so the client could sort by most commonly used tags. By the way, to Guilhem, thank you for your very cool app, but could you please release a Windows binary when you release new versions? I haven't been motivated enough to set up a ming installation to compile my own. Sincerely, Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mkgmap questions
On Tue, Aug 26, 2008 at 10:02 PM, Simon Wood [EMAIL PROTECTED] wrote: Hi, I made some really good progress last week and got a map together for the Crowsnest Pass. Unfortunately for the area I chose with a fair number of contours the map redraw was quite slow. I have worked out how to graduate the contours so more appear as the user zooms in, I'll have to wait to see if this speeds up rendering. I was thinking that the render might be quicker if I used a series of smaller maps. I used osmosis to split the '.osm' file into smaller tiles. However this was not putting any 'bound box' line into the file and mkgmap was therefore not cropping the tile neatly, instead it was including the ways which overhung the edge of the bounding box. Should this be the case, or am I mis-understanding? What version of Osmosis are you using, because I added that feature (writing of the bound element) a while ago, so it should work if your input file has a bound element. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mkgmap questions
On Wed, Aug 27, 2008 at 3:48 PM, [EMAIL PROTECTED] wrote: What version of Osmosis are you using, because I added that feature (writing of the bound element) a while ago, so it should work if your input file has a bound element. Hi Karl, I am use 'osmosis-latest'/version 0.29 downloaded yesterday. The problem may be that the source data files do not contain the bound element itself, and therefore it might not be transfer to the output. Source data is made with mkcntr2.pl (for contours) and OSM data requested via XAPI with: wget -O crowsnest.osm http://www.informationfreeway.org/api/0.5/*[bbox=-115,49,-114,50]http://www.informationfreeway.org/api/0.5/*%5Bbbox=-115,49,-114,50%5D Head of 'crowsnest.osm' is -- ?xml version='1.0' standalone='no'? osm version='0.5' generator='osmxapi: OSM Extended API' xmlns:osmxapi='http:#47;#47;www.informationfreeway.org #47;osmxapi#47;0.5' osmxapi:uri='#47;api#47;0.5#47;*%5bbbox=-115,49,-114,50%5d' osmxapi:planetDate='200808262236' osmxapi:copyright='2008 OpenStreetMap contributors' osmxapi:instance='zappy2' node id='26655039' lat='49.002' lon='-110.001' user='srw777' osmxapi:users='srw777' timestamp='2007-03-20T22:11:53Z' /node -- I am using osmosis to merge the OSM source with contours (after sorting both) with the command -- java -jar osmosis.jar --read-xml temp1.osm --read-xml temp2.osm --merge \ --bb completeWays=yes top=50 bottom=49 left=-115 right=-114 \ --write-xml temp.osm -- Head of 'temp.osm' is -- ?xml version='1.0' encoding='UTF-8'? osm version=0.5 generator=Osmosis 0.29 node id=27611078 timestamp=2007-04-25T03:42:36Z user=NytOwl lat=50.0015304 lon=-114.917867/ -- Hopefully it's something simple going wrong. Simon You're right. It's because the source files don't have bounds. If you have only a couple files, you could insert a dummy bound element before the first node. It should work as long as it includes the area that you're cropping with --bb. You could just make it span the entire planet, like bound box=-90,-180,90,180 origin=osmxapi/ and then Osmosis will cut it down to your bounding box. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
On Tue, Aug 26, 2008 at 1:30 AM, Andy Robinson (blackadder-lists) [EMAIL PROTECTED] wrote: Chris Morley wrote: Sent: 24 August 2008 8:51 PM Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] Left and Right? Karl Newman wrote: On Sun, Aug 24, 2008 at 9:53 AM, Rory McCann [EMAIL PROTECTED] Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. A similar thinking is obvious in the Karlsruhe House Address Scheme ( http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Ka rlsruhe_Schema), since the buildings that are numbered are not physically in the middle of the road, they are added as nodes to the left or right of the way. Yes, and that method is not topological, which makes it very difficult to associate that feature (bus stop, house number, whatever) with the way that it's actually located on. It should either be a node that is part of the way, or have a relation to connect the node with the way. I think that the topological aspect of OSM's data structure is important and well worth maintaining in nodes and ways as well as in relations. We are not just drawing pictures, we are also recording relationships. This is why the representation of a mooring - a stretch of canal where boats tie up - as a separate way not connected to the canal seems wrong to me. In this case and with bus stops or house numbers, if you convey which side it is on by having a separate node or way displaced an arbitary short distance to one side, then you lose this side information at lower scales, when it may still be important to a user. With a topological description it is still available. I totally agree on this approach, ie the node is part of the way, but only for features which have direct relationship to each other. This for a bus stop of a mooring I make the node part of the way because these are features that apply and have a relationship with the way itself. For house numbers however I make a separate node. I do this for two reasons, the first is that the house has no relevance to the way it is alongside. We think of house What? Of course it has relevance. The number means nothing without the street. Houses don't have GUIDs. It has to be associated with it's street if you ever want to look it up by address. numbers being part of a street but in reality they aren't, they are references for buildings. The second reason is that if we were to add nodes for every house on both sides of the street to every way we would soon find out ways totally unmanageable. As a further reason, houses are normally connected to the street with a driveway/footpath. In a fully featured map you would draw these in eventually. Its these that make the true relationship between building and street. There's no need to add house numbers at every node in a way (except for weird cases where the house numbers are not sequential). Put the numbers at intervals and let interpolation take care of the rest. Always try top keep things simple. Keep like with like and don't try to over engineer the result and generally the result will be more than sufficient. The Karlsruhe schema is an example of what you get without any engineering at all--just look how many different scenarios are presented on that page! The common method used by other systems which store house numbers (for example, TIGER) is to associate a house number with the way and indicate if it's on the left or right. This is done only at certain points, and linear interpolation takes care of the rest. This is also what's expected by existing navigational systems (e.g., Garmin GPS) and if we ever hope to be able to use our house number data there, it needs to be able to be transformed into that format. The Karlsruhe schema does not allow for that without a huge amount of work and a lot of uncertainty about the result. I'm not opposed to putting the house number on a separate node, but it needs to be topologically connected with the way using a relation in that case, because in real life, the house address *is* associated with the street it's on. Karl
Re: [OSM-talk] Left and Right?
On Mon, Aug 25, 2008 at 3:34 PM, Mark Williams [EMAIL PROTECTED]wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 robin paulson wrote: Rory McCann wrote: Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. the problem with this is that 'bus stop' (and canal mooring, etc,) implies a place where the bus stops, which is on the road. the fact the bus shelter, or sign, or bench, is some distance off to the side of the road shouldn't matter - the bus itself stops on the road, so the node imo should be part of the way if the bus stop is off to the side of the road, i.e. not connected to it, then the bus can't physically get to it, which seems very wrong or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way this problem is i think muddled by the fact we represent an area (a road) with a linear object (a way), which theoretically has zero width, so the natural step from this is to say: 'the way represents the centre of the road, and the bus stop/canal mooring is not in the centre of the road, it's at the side of the road, so I'll put it to one side of the way' as for placing the node to one side of the way in order to get the icon to be placed correctly, this sounds a lot like 'tagging for the renderer' I disagree with this view. Do you tag post boxes as way nodes? Shops? Telephones? No... So why bus stops? They aren't in the road. They are sites on the side, like all of the above. It makes no sense to tag them as way objects. I have seen the arguments about knowing which way they belong to; IMHO this is specious, no bus company works by looking at OSM to see where to route their buses, but a map user may well want to know just where the bus stop is - Anyone looking at a map of where they are who doesn't know which side they drive, is in trouble. The same goes for any navigation software. It really isn't hard to link from bus-stops as points to nearby ways - check out all the routing apps, not many need a hard node ID or way ID to commence from / get to - they find a nearby way from a lat/long. If Gosmore can do it, why not any other app? It just introduces a whole load of hassle working out which bus stop goes in which direction, sticking it in the middle of the road. It looks stupid in the renderers for a very good reason. My 2p, but I don't want this to look like everyone thinks that way nodes are good.. Mark If you happen to know exactly which nodes (which are not part of the way) are your start and end points, then routers can deal with that. If you want to know which bus stops you will pass while traveling along a way, that's a much more difficult problem if the nodes are not somehow topologically associated with the way. It's a more serious problem with house numbers because the data volume is so much higher (many more house numbers than bus stops), which makes it even more important to associate a number with a way (and not by using the street name--that's not topological, is subject to typos and is difficult to validate automatically). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Importing campsite in Oregon
On Mon, Aug 25, 2008 at 8:07 AM, Tom Brown [EMAIL PROTECTED] wrote: I'm going to be camping in Oregon in a week. OSM didn't seem to include any campsites in that area so I downloaded positions from the USFS and a private operator and imported them using ogr2ogr, gpsbabel and josm. The USFS data is public domain. I updated http://wiki.openstreetmap.org/index.php/Potential_Datasources#US_Forest_Service For the data I got from the google map at http://www.hoodoo.com/oregon_home.htm I emailed hoodoo and got this reply: -- Forwarded message -- From: [EMAIL PROTECTED] Date: Sun, Aug 24, 2008 at 2:28 PM Subject: Re: importing campsite locations into Open Street Map Our map comes from Google and I doubt that you need my permission, but if you do, you have it. Hope things go well, Chuck Do I need to ping this list for future tiny imports like this? Sorry for not asking first. I wanted to make sure I could do the import before asking and before I knew it the data was uploaded. ;-) http://toolserver.org/~kolossos/osm/osm-paths-gm.php?kml=http://tools.wikimedia.de/~kolossos/osm/cache/bm9kZVt0b3VyaXNtPWNhbXBfc2l0ZV1bYmJveD0tMTIzLDQzLC0xMjIsNDVd.kmzhttp://toolserver.org/%7Ekolossos/osm/osm-paths-gm.php?kml=http://tools.wikimedia.de/%7Ekolossos/osm/cache/bm9kZVt0b3VyaXNtPWNhbXBfc2l0ZV1bYmJveD0tMTIzLDQzLC0xMjIsNDVd.kmz http://openstreetmap.org/?lat=43.67149lon=-122.4316zoom=17layers=0B0FTFT If there is a problem look for nodes with tag source_ref= http://www.hoodoo.com/oregon_home.htm or source_ref= http://www.fs.fed.us/r6/data-library/gis/umpqua/documents/rec_site_pt.zip You need to be very careful about this to make sure the data you grabbed isn't tainted. The USFS public domain stuff should be okay, but if any of the actual campsite locations or data came from Google, then it should probably be removed, because OSM does not have permission to use information derived from Google maps. That's why OSM can't use geonames.org data, either. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Importing campsite in Oregon
On Mon, Aug 25, 2008 at 10:51 AM, Tom Brown [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 8:51 AM, Richard Weait [EMAIL PROTECTED] wrote: On Mon, 2008-08-25 at 08:07 -0700, Tom Brown wrote: I'm going to be camping in Oregon in a week. OSM didn't seem to include any campsites in that area so I downloaded positions from the USFS and a private operator and imported them using ogr2ogr, gpsbabel and josm. The USFS data is public domain. I updated http://wiki.openstreetmap.org/index.php/Potential_Datasources#US_Forest_Service Good find, Tom. For the data I got from the google map at http://www.hoodoo.com/oregon_home.htm I emailed hoodoo and got this reply: -- Forwarded message -- From: [EMAIL PROTECTED] Date: Sun, Aug 24, 2008 at 2:28 PM Subject: Re: importing campsite locations into Open Street Map Our map comes from Google and I doubt that you need my permission, but if you do, you have it. Hope things go well, Chuck Do I need to ping this list for future tiny imports like this? Sorry for not asking first. I wanted to make sure I could do the import before asking and before I knew it the data was uploaded. ;-) I suggest that you remove the hoodoo uploads from the OSM database for now. I have to guess, because you didn't include your email to Chuck, but his reply doesn't sound like, I collected the data on personal trips and authorize you to re-licence it for OSM. In fact, the only things he says is this, Our map comes from Google... While he doesn't distinguish between the underlying map which is probably to what he refers, and the campsite data which is probably what you uploaded, his email does not sound to me like the permission that we require. Good point regarding how he made his made. I'll ask him to clearify how he generated the lat,lng for his map. I suspect he used Google's geocoding + manual correction using Google map tiles and satellite images, which isn't kosher. I think this answers my question about asking before uploading :-/ Now, to remove... curl -g ' http://osmxapi.hypercube.telascience.org/api/0.5/node[source_ref=http://www.hoodoo.com/oregon_home.htm][bbox=-124,42,-121,46]http://osmxapi.hypercube.telascience.org/api/0.5/node%5Bsource_ref%3Dhttp://www.hoodoo.com/oregon_home.htm%5D%5Bbbox=-124,42,-121,46%5D ' returns a 500 error. Getting a single node works... curl -g ' http://osmxapi.hypercube.telascience.org/api/0.5/node[name=Secret][bbox=-124,42,-121,46]http://osmxapi.hypercube.telascience.org/api/0.5/node%5Bname=Secret%5D%5Bbbox=-124,42,-121,46%5D ' ?xml version='1.0' standalone='no'? ?xml version='1.0' standalone='no'? osm version='0.5' generator='osmxapi: OSM Extended API' xmlns:osmxapi='http:#47;#47;www.informationfreeway.org#47;osmxapi#47;0.5' osmxapi:uri='#47;api#47;0.5#47;node[name=Secret][bbox=-124,42,-121,46]' osmxapi:planetDate='200808251732' osmxapi:copyright='2008 OpenStreetMap contributors' osmxapi:instance='zappy2' node id='290956783' lat='43.540833' lon='-122.449493' user='Tom Brown' osmxapi:users='Tom Brown' timestamp='2008-08-25T14:39:20Z' tag k='name' v='Secret'/ tag k='source_ref' v='http:#47;#47;www.hoodoo.com #47;oregon_home.htm'/ tag k='tourism' v='camp_site'/ /node /osm but I can't get requests by user to work. [user=Tom Brown] seems to just search for user=Tom and user=Tom+Brown finds nothing. Instead I ran curl -g ' http://osmxapi.hypercube.telascience.org/api/0.5/node[tourism=camp_site][bbox=-124,42,-121,46]http://osmxapi.hypercube.telascience.org/api/0.5/node%5Btourism=camp_site%5D%5Bbbox=-124,42,-121,46%5D' campsites.osm loaded the osm in josm, did a search to select the hoodoo source_ref data, deleted and uploaded. Sweet! I think when you're requesting from osmxapi you have to encode special characters in your request. So, instead of a space in user=Tom Brown, you'd put %20, which is the URL encoding for a space (ASCII hex code 20), so you'd put user=Tom%20Brown. Similar for the colon and maybe also the slashes in your source_ref tag (I don't know the codes for those offhand). Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Left and Right?
On Sun, Aug 24, 2008 at 9:53 AM, Rory McCann [EMAIL PROTECTED] wrote: Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. A similar thinking is obvious in the Karlsruhe House Address Scheme ( http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Karlsruhe_Schema ), since the buildings that are numbered are not physically in the middle of the road, they are added as nodes to the left or right of the way. Rory Yes, and that method is not topological, which makes it very difficult to associate that feature (bus stop, house number, whatever) with the way that it's actually located on. It should either be a node that is part of the way, or have a relation to connect the node with the way. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] superways as relations ?
On Mon, Aug 18, 2008 at 9:00 AM, Robert (Jamie) Munro [EMAIL PROTECTED]wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Earl wrote: On 04/08/2008 11:14, vegard wrote: For naming of streets in cities, where properties change very often and you have to make many small ways, it sometimes gets annoying that the name is duplicated. I was wondering: How good/easy would it be to make a superway-relation to fix that? I.e. group several ways for labeling-intentions? I'm no expert on the inner workings in either of the renderers, but to me it sounds like a quick fix to a small annoyance. If someone that knows the renderers could either agree or disagree, I'd be happy anyways (well, obviously happier if they agree :) See http://wiki.openstreetmap.org/index.php/Relations/Proposed/Collected_Ways AFAIK this isn't rendered at present, so for the time being the names would have to appear on the ways themselves as well if you want to see them, but in principle, a renderer could take note of this, and if it becomes a widespread idiom, no doubt they will. I think that is a chicken and egg scenario. I think the renderers (and namefinder) need to support it before people will start using it. Then very quickly we could move all names (and refs and highway types...) to relationships, and we would have a much cleaner data structure. Lots of wierd cases where part of a road has more than one ref, more than one name, or more than one of any other property go away - the relevant ways just become a member of more than one relationship. Personally, I believe that most tagging should be on relationships not ways. Only small physical things like layer, bridge and tunnel should be specified at a way level. Robert (Jamie) Munro I think this is one point where the different data clients or consumers have different preferences. To my mind, you've got it backward. The small physical things like bridges and tunnels are the parts that should go into relations, because they have nothing to do with the physical continuity of the way. A routing app does not care about bridges and tunnels. However, your perspective is probably one of rendering, which would prefer to see the ways chopped up at bridges and tunnels. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] superways as relations ?
On Tue, Aug 12, 2008 at 1:58 PM, Matthias Julius [EMAIL PROTECTED]wrote: Karl Newman [EMAIL PROTECTED] writes: On Thu, Aug 7, 2008 at 2:11 PM, Matthias Julius [EMAIL PROTECTED] wrote: Karl Newman [EMAIL PROTECTED] writes: Sounds like you're looking for this: http://wiki.openstreetmap.org/index.php/Relations/Proposed/Segmented_Tag This can not cross way boundaries. If someone splits that way in between to and from there is a problem. Matthias That's exactly the point--that tagging scheme is intended to get away from splitting ways. If this were to be adopted, the need to split ways would be greatly reduced. Splitting ways would probably need to be made non-trivial by the editors and it would take some careful support for copying the relevant tags to new relations and modifying the old ones. Ways need to be split - we can not have the whole world in one single way. If some of the data has to be duplicated the usefulnes of the tagging scheme is allready greatly reduced. Matthias Umm... That's not what I was saying. It's not even possible to have the whole world in a single way. I was just arguing against splitting ways due to attribute changes which have nothing to do with the way itself (i.e., bridges, speed limits, etc.). A reasonable approach would be to split ways only if the name or major (highway) type changes. Obviously for dual carriageways, too... Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Bicycle facility tags (Class III bike route)
On Tue, Aug 12, 2008 at 4:11 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]wrote: How do we mark and tag Class II and Class III bike facilities? (I'm not sure if Class I, II, and III is a California specific designation, or if this is the standard terminology throughout the US) Class I is the separated bike path, with a physical separation between the bicycle path and vehicle traffic, or on a route which other vehicle traffic doesn't follwo. This one is easy, you trace in the path, and make it highway=cycleway; cycleway=track. It's just the same as drawing in separate roads for divided roads. Class II is the bike lane with its own lane markings, but it is immediately adjacent the vehicle lanes. This also seems to be pretty clear: just add a cycleway=lane tag to the road it is part of, right? Class III is a shared use facility with the cars, it just has the green bicycle route signs occasionally. Hopefully it has a wide outside lane, but not always. How do you put this one in? do you add a bicycle=designated tag to the road, or what? Thanks for the input, -Mike Mike, I think your suggestions line up with how I would tag it, too. I'm curious where you heard about the Class I, II, III designations, though. I'm a California native and occasional bike rider and I've never heard of these. And I'm not sure I've ever seen a Class I cycleway--any separated paths always seem to be shared with pedestrian other non-vehicle traffic (I would tag the ones I've seen as highway=path, bicycle=designated, foot=designated, etc.). Actually, now that I think about it, the west side of the Golden Gate Bridge might qualify as a pure cycleway (it's supposed to be for bicycles only). Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] OSM on Ubuntu UK podcast
On Fri, Aug 8, 2008 at 11:14 AM, [EMAIL PROTECTED] wrote: On Tuesday 05 August 2008 13:30:24 you wrote: On Tue, Aug 5, 2008 at 2:15 AM, Ævar Arnfjörð Bjarmason [EMAIL PROTECTED] wrote: There's a page on the wiki devoted to this[1], someone me produces a map for the UK[2] already but it looks like it isn't as frequently updated as you might like Weekly, when I remember to do so. I've updated it today with the maps from the 30th's planet. Thanks for the replies, I took the easy way and just dumped Andy Allen's uk-osm-080703.img file into the garmin folder on the sd card and renamed it gmapsupp.img, it's brilliant. Now who's clever enough to combine this osm map with Peter's (three minds in a can) contours from the smc site, I'd like both. I can see it was done with the cycle map for the SE England but that's fairly old now, although it too works well. Andrew You could open both img files with GpsMapEdit (www.geopainting.com --for Windows only) to combine them, save as Polish Map Format (.mp) and then compile the result with cGPSMapper (www.cgpsmapper.com) and put it back on your device as gmapsupp.img. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] superways as relations ?
On Thu, Aug 7, 2008 at 2:11 PM, Matthias Julius [EMAIL PROTECTED]wrote: Karl Newman [EMAIL PROTECTED] writes: Sounds like you're looking for this: http://wiki.openstreetmap.org/index.php/Relations/Proposed/Segmented_Tag This can not cross way boundaries. If someone splits that way in between to and from there is a problem. Matthias That's exactly the point--that tagging scheme is intended to get away from splitting ways. If this were to be adopted, the need to split ways would be greatly reduced. Splitting ways would probably need to be made non-trivial by the editors and it would take some careful support for copying the relevant tags to new relations and modifying the old ones. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] House numbers... One more suggestion
On Tue, Jul 29, 2008 at 4:06 AM, Andy Robinson (blackadder-lists) [EMAIL PROTECTED] wrote: snip The reason I don't like ideas like this is that the data you are adding to the way (or as Frederik pointed out possibly also the intersections) is not actually anything to do with the physical feature. There are no house numbers or other references on a road, only the name of the street and perhaps a road reference number. Accepted it's a nice easy way to make routing work more easily but that doesn't make it right for our dataset. If we keep and maintain the simple ideal that what we map is what we see then it keeps it all very simple. Routing algorithms may need to be more complex as a result but that doesn't give us an excuse to corrupt our data with misleading information. Cheers Andy To be clear, I don't have a problem with tagging the actual location of the house or building. I think it's unnecessary, but the problem I have with the scheme is that it doesn't definitively link the node with the way (what's a house number without an associated street?) My suggestion (the third on that page, and the first using relations) was to have a relation that marked one node with left and/or right addresses at that point in a particular street. Having only a single value instead of a range makes it more resistant to breakage if the way is split or merged or if nodes are changed. It's reasonably easy for mappers, too, because it's only one point and number to mark, and if more detail is desired later, more nodes, numbers and relations can be added in between existing points. Andy, you say it's a nice easy way to make routing work more easily but that doesn't make it right for our dataset. What is the purpose for adding house numbers, then? I hope it's for more than drawing numbers on the map, which really has limited usefulness (numbers at intersections might be helpful, and would be less clutter on a map). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] House numbers... One more suggestion
On Tue, Jul 29, 2008 at 10:27 AM, Jochen Topf [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 10:16:33AM -0700, Karl Newman wrote: To be clear, I don't have a problem with tagging the actual location of the house or building. I think it's unnecessary, but the problem I have with the scheme is that it doesn't definitively link the node with the way (what's a house number without an associated street?) My suggestion (the third on that Thats why you should not only tag the building/node with the house number, but with the full address. Yes, there is some duplication of data, but its still easier than relations and doesn't break as easy. Jochen I'm okay with data duplication. Could we do both, then--the Karlsruhe schema where actual locations are tagged with full address, and a relation to topologically link the house number with the closest node in the way? Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] A Swedish national server for OSM
On Tue, Jul 29, 2008 at 2:16 PM, Dave Stubbs [EMAIL PROTECTED]wrote: On Tue, Jul 29, 2008 at 7:57 PM, Inge Wallin [EMAIL PROTECTED] wrote: In the rather large thread Actually using OpenStreetMap and the usability of the current maps I got to understand a few things that I didn't grasp before. So to make a long story short, I have decided to check the viability of setting up a Swedish tile server + slippy map and some other services. To do that I am applying for some money from the Swedish Internet Society that has grants for such things. But to be able to write the application, I need to understand the size of the task. Things like: - How long does it take to render a typical tile set? Will a single machine be able to render all the tiles for Sweden, for instance? What's the size of the current render farm for the mapnik map on openstreetmap.org? - How much bandwidth will it use? - How difficult is it to set up a working server? I'm fairly skilled in deployment, but I have never worked with mapnik, nor osmarender or slippymaps. I am aware that the questions are fuzzy, but all data will be much appriciated. For the cyclemap we prerender the tiles and upload them to a cheap dumb webhost. The coverage of the cyclemap is quite large, but typically only goes as far down as zoom 13 (or zoom 14 for the UK), we do selected cities at higher zoom. We render on a box with the cheapest quad core processor available (Core2 Q6600), and 8GB RAM -- this does approximately 1 million tiles in about 5 hours (and includes contours -- the standard rendering is 2-3 times faster to render). Our main bottleneck is then uploading these tiles to the webhost. In July the cyclemap used approximately 200GB of bandwidth serving tiles -- but it is quite popular and the tile sizes are actually quite large... In terms of setup, if you're doing an on-demand modtile solution, then it relatively easy.. just follow the instructions on the wiki -- give it a try on a VM first to test out the process on the distro that you want to use. Relative is obviously relative... but it's easier than MythTV Dave What's hard about emerge mythtv? Unless you want a remote control (lirc), and a LCD display (LCDproc), and RAID (mdadm) and LVM... Oh, I guess it was a bit of a pain. ;-) Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Names, split streets and relations
On Mon, Jul 28, 2008 at 2:32 AM, Dave Stubbs [EMAIL PROTECTED]wrote: On Mon, Jul 28, 2008 at 6:23 AM, Karl Newman [EMAIL PROTECTED] wrote: On Mon, Jul 28, 2008 at 12:55 AM, Gervase Markham [EMAIL PROTECTED] wrote: Karl Newman wrote: I think the obvious thing is to quit splitting ways just because there's a bridge or the speed limit changed... IMHO, the only reason to split ways is if the name changes or if the major type changes. Er, correct me if I'm wrong, but it's not possible to apply a tag to only part of a way. So if the speed limit or anything else changes, you can't have a continuous way if you want to tag correctly. Gerv I was thinking about this (not my proposal, but I like the idea): http://wiki.openstreetmap.org/index.php/Relations/Proposed/Segmented_Tag Personally I classify that as more complicated, more surprise, and with the added danger of hiding information. It might work with very good editor support, but given how long we had segments, and how the interface for figuring out them was never really fixed, my hopes wouldn't be too high. I think fixing the renderers for this is much more preferable (rather than fixing the renderers to cope with these fake segments.. which doesn't sound too fun actually). Dave It's not just a rendering issue, although that's the topic of discussion. It makes it much easier for editing and later processing (it's easy to split a way, not as easy to recombine it). Currently, if you want to add or modify a tag on a long way, you have to click on each section to change the tag. In the degenerate case, you'd click on every single segment. I realize it would require good editor support, but it's disheartening to see the we've always done it that way; why should we change? crowd coming out already on a project this young. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] House numbers... One more suggestion
On Mon, Jul 28, 2008 at 10:21 AM, Charlie Echo [EMAIL PROTECTED]wrote: If things are clear, and if there is a consensus about using this Karlsruhe schema, let's have a vote on it. This will make things easier: we would then have a clean situation. This would enable people to enter the data. We may also adapt the tools then, e.g. create a function in JOSM that explodes a way by creating parallel ways (for each continuous segment) with pre-filled tags (street names, and so on) so that entering data is easy enough. Charlie Echo The Karlsruhe schema is fine for just showing numbers on a map, but I don't like it because it's not topological and therefore virtually impossible to use for other purposes. This is because the associated way is not directly encoded in the schema--it has to be derived by another means. That's just a whole lot more work for data consumers that are only trying to locate a street address a relative distance along a way (e.g., all current GPS navigation systems). Consider this use case: Given a street, I'd have to look through NN million nodes to find the closest ones (say within some radius, which may actually miss some!), and then for each of those nodes, check against MM million ways to make sure they aren't actually closer to another street. That's madness! A simple relation could tell you node X in way Y has the address number Z. (Obviously need a little more detail such as odd/even schemes to fully support interpolation). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Names, split streets and relations
On Sun, Jul 27, 2008 at 3:09 PM, Gervase Markham [EMAIL PROTECTED] wrote: I have a situation (which I suspect is very common) where a street is split into e.g. 3 ways, because the middle one is part of a bus route or other relation. If you label all three ways with name=Foo Street, you get Foo Street rendered 3 times along a fairly short length, at least in Osmarender. If you leave the name off the outer ends, then those ways are incorrectly assumed to be unnamed streets when they have a name. In other words, you've made the data bogus for rendering reasons. What is the correct response to this? The obvious thing to do is attach the street name to a relation which incorporates all three ways. Do the main renderers yet correctly render street names expressed as relations? Gerv I think the obvious thing is to quit splitting ways just because there's a bridge or the speed limit changed... IMHO, the only reason to split ways is if the name changes or if the major type changes. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Names, split streets and relations
On Mon, Jul 28, 2008 at 12:55 AM, Gervase Markham [EMAIL PROTECTED] wrote: Karl Newman wrote: I think the obvious thing is to quit splitting ways just because there's a bridge or the speed limit changed... IMHO, the only reason to split ways is if the name changes or if the major type changes. Er, correct me if I'm wrong, but it's not possible to apply a tag to only part of a way. So if the speed limit or anything else changes, you can't have a continuous way if you want to tag correctly. Gerv I was thinking about this (not my proposal, but I like the idea): http://wiki.openstreetmap.org/index.php/Relations/Proposed/Segmented_Tag Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-us] Clark County, Nevada Street Center Line data
On Fri, Jul 25, 2008 at 1:11 PM, Joseph Scanlan [EMAIL PROTECTED] wrote: On Thu, 24 Jul 2008, Ian Dees wrote: make sure that the data is better than the data that was already imported from TIGER. The data is quite good and gets updated weekly. So... I don't want to treat this as a one shot conversion. Updates should be part of my plan. snip Updates: 1 create scl.osm preserving attributes as ccgis: tags 2 extract working.osm from planet.osm with the same bounding box as scl.osm 3 create add.osm, delete.osm, and change.osm by comparing ccgis: tags in scl.osm and working.osm 4 review changes.osm with JOSM and upload 5 review add.osm with JOSM and upload 6 process delete.osm (but how?) Osmosis can create the diffs for you, if you keep a local copy of scl.osm (after you upload), then do a diff with a new, updated copy of scl.osm. That should help reduce your update burden. Karl ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
