Re: [Talk-us] exit_to vs destination
Anybody else think we should CC [talk-ca] in on this too? Main reason I'm suggesting this is because of how they (at least in Ontario) have been doing the exit tags, which is to add everything to the 'name' tag so it gets rendered on the map (at least I think that was why it was done this way, but not 100% sure).. https://www.openstreetmap.org/node/76478134 -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Sidewalks as footpaths
On Thu, 2014-05-08 at 05:58 -0400, Serge Wroclawski wrote: The problem (aside from the issue of data clutter) is that the sidewalk data can't be used for pedestrian routing because the information about the street is not captured. You can't tell someone to follow Main Street, because the path is not labeled as such. Could this problem be alleviated with a tag on the separately mapped footway, e.g. road_name? Or even just addr:street? James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] High res DigitalGlobe imagery open for tracing through Mapbox Satellite
Thank you Mapbox and DigitalGlobe. Just one little flaw with the feedback tool. The additional notes part doesn't show up when I'm selecting areas that need a refresh. I wanted to point out some major Interstate Highway projects that are being done that either are building brand new highways or massively reconfiguring other segments. I still submitted the two areas that I know need imagery updates badly (the final segment of I-485 being built in Charlotte, NC; the massive I-40/I-77 interchange reconfiguration + complete rebuild of I-40 in that area to Collector/Distributor lanes and other interchange reconfigurations in the Statesville, NC area), but wanted to add the extra note info but couldn't since that part didn't show up. So, I hope you can get the notes part fixed and working. I tried it in both IE-11 (patched all the way) and Firefox Beta 29. -James ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Global Admin Boundary Extracts
Hi all, I've been trying to find the best way to extract global admin boundaries for admin_level 2 - 4 (or more, depending on size). Up until now, XAPI has been my go-to, but that seems to tap out at anything more than 10 or 20 degrees square. [moreover, and this might be due to a mistake on my part, not XAPI's, after extracting and using osm2pgsql, the planet_osm_polygon table is often incomplete, though planet_osm_line is complete. Every time I experiment w/ semi-large (country-size) XAPI extracts, the results are slightly different] Anyone have any pointers on how to get global extracts (extracts of large areas, even if the resulting file is not itself large)? Thanks for the pointers. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] NAIP Imagery Servers -- Need Assistance Setting Up in JOSM
Hi Kristen, I was able to get it to work. I used North Carolina and use the WMS link from the NC page: http://gis.apfo.usda.gov/arcgis/services/NAIP/North_Carolina_2012_1m_NC/ImageServer/WMSServer?request=GetCapabilitiesservice=WMS In the WMS/TMS part of JOSM preferences I added a new WMS site, entered the above link in the service url section and clicked on the get layers button. I selected the image layer and then changed the image type to BMP as I have found that the default tiff's don't tend to work. Hope this helps, James On Mon, 2014-03-24 at 17:26 +, Kam, Kristen -(p) wrote: (cross-listed with JOSM-Dev Talk-US) Morning, The other week, I came across the directory of USDA's WMS NAIP Image Services (by state). QGIS renders the images with no problem, but it appears to fail in JOSM. I mentioned my difficulty to a fellow OSMer and he suspects JOSM cannot support these WMS services. That said I was wondering if anyone could shed some light on why I cannot get images to render in JOSM (me not configuring right or no support in JOSM?!). List of Image Servers -- http://gis.apfo.usda.gov/arcgis/rest/services/NAIP Thanks, Kristen --- Kristen Kam OSM Profile → http://www.openstreetmap.org/user/KristenK ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] MapQuest Open tiles not updating?
See this tweet I got back from them asking the same question: https://twitter.com/MapQuestTech/status/436876342861512704 -James ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-us] State ref tags on ways
I know that in some states that we don't add the state abbreviation (and use 'SR' or 'SH'), and other states we don't add anything at all expect just the number. I'm just curious if anybody thinks we should try to get them all standardized on the ways. For instance, we should start adding the 'FL' part to ways in Florida when we edit them since right now, all we have is just the number. I personally would love to see 'FL' in the ref tags properly as I think the main reason that one Florida user didn't add them (and maybe kept removing them if added by any other user) was to make the ref tags render in Mapnik if there was more than one route on the highway. And as we do know, tagging for the renderer is frowned upon. Now, I know we do want to move to using just relations to render the shields in the future, but as of right now, we still need to keep both ways working together. So, I thought we should just hase this out again so we can attempt to get each state on the same page if possible. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] maproulette.org
Martijn, the bad versions of the relation pages are back from the beginning of February. :( From: m...@rtijn.org Date: Thu, 6 Mar 2014 21:55:37 -0800 To: talk-us@openstreetmap.org Subject: Re: [Talk-us] maproulette.org Hi all, I fixed the relation pages problem. It turns out that the crontab entry on the database server, responsible for querying the live OSM database for the relation information and feeding that to the script that generates the pages, got erased. So the relation pages get updated once again. Yay! Full disclosure: I also added piwik web site analytics code in the process - I only use this to help me understand how people are using the pages, and nobody else has access to the piwik reports. If you want to get an idea of what these reports look like, check out http://piwik.org/docs/piwik-tour/#piwik-overview. osm.org uses piwik as well. I will also be installing piwik tracking on the Battle Grid and - soon - on the new version of MapRoulette. (Here is why piwik is cool and Google Analytics (which provides similar functionality) is not: https://piwik.org/privacy/) On Wed, Mar 5, 2014 at 2:32 PM, Martijn van Exel m...@rtijn.org wrote: Hi all, I am currently changing the DNS records for maproulette.org to point to a new server, which will contain a shiny new version of MapRoulette Very Soon Now. This means that the following services are currently only available through the old maproulette.org server's IP address: Relation Pages (maproulette.org/relationpages) -- http://184.73.220.107/relationpages Battle Grid (maproulette.org/battlegrid) -- http://184.73.220.107/battlegrid This will all be restored to normal over the next few days, hopefully. By the way, I am aware of an issue with the relation pages not being updated, I will work on that as soon as I get a chance. Best Martijn -- Martijn van Exel http://openstreetmap.us/ -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Telenav giving away iPad Mini or Galaxy Note to Editor with the Most Edits Made By March 10
Thanks for doing this Steve. However, is there a way to report script kiddies who are running a script to just rack up points that aren't doing anything to help out OSM and just want to win the prize? Should I just report them to the DWG, especially since he hasn't talked to talk-us about running the script? The reason I'm asking is because I've already spotted one of these type of users who is just running a script that is just changing tags from one to another type to rack up the edits. Heck, he's also somehow editing some nodes just to make them his without doing anything to them (no idea how he's doing that!). -James From: st...@asklater.com Date: Tue, 11 Feb 2014 11:15:16 -0700 To: talk-us@openstreetmap.org Subject: [Talk-us] Telenav giving away iPad Mini or Galaxy Note to Editor with the Most Edits Made By March 10 From; http://stevecoast.com/2014/02/11/telenav-giving-away-ipad-mini-or-galaxy-note-to-editor-with-the-most-edits-made-by-march-10/ As many of you probably know, I’m heading up OSM initiatives over at Telenav, the Bay Area-company that develops GPS navigation apps like Scout. For three years, Telenav has been dedicated to helping the community through map updates. Today, we’ve kicked off a contest to see if we can help drive even more edits over the next 30 days. Anyone can win and it’s pretty easy to enter. All you need to do is sign up here to register for the contest and make as many quality edits as you can by the end of March 10th! We’re asking that editors focus on the U.S. and to make edits either through OpenStreetMap.org or Battle Grid. We have created a point system for edits and the person with the most points between now and March 10 will win either an iPad Mini or a Samsung Galaxy Note (your choice!). Good luck and happy editing! Steve ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] South Carolina State Highways - primary overload
Thank you Frederik. Really appreciate it. -James Date: Wed, 5 Feb 2014 22:59:57 +0100 From: frede...@remote.org To: talk-us@openstreetmap.org Subject: Re: [Talk-us] South Carolina State Highways - primary overload All, On 09.12.2013 06:42, James Mast wrote: Is it just me, or are there way too many primary state highways when some of them should really be secondary instead? After this discussion has now more or less concluded that we should be reverting the edits in question, I have compiled a list of all highways where user mjbyars has changed the highway type at some point in the past, and reverted them to the previous highway type. Only the highway tag was changed in this process, everything else remained in the current state. The revert changeset is this: http://www.openstreetmap.org/changeset/20401446 There may be some situations where a way was split by the user (which to the database looks like a modification of one way and a new creation of another); in these cases, the new highway will likely still be of the former (higher) highway type and not be reverted. So if you do spot the odd remnant of primary overload, please do fix it by hand. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Allegheny County (Pennsylvania) real estate assessment website for addresses
I'm just wondering, do you guys think that Allegheny County's real estate assessment website is OdbL compatible to use to gain addresses to put into OSM? http://www2.county.allegheny.pa.us/RealEstate/Search.aspx I haven't taken any addresses from it, but if it's compatible with OSM, it could be a gold mine for getting a big area of addresses done for the OSM world. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Allegheny County (Pennsylvania) real estate assessment website for addresses
So, the data is compatible with OSM and the OdbL license? I personally don't have the time right now to even attempt an import (swamped big time in RL), but I know of somebody else that would possibly be interested in doing this (or at least a little bit of it) if the license is compatible. -James From: ian.d...@gmail.com Date: Tue, 4 Feb 2014 10:28:38 -0600 To: rickmastfa...@hotmail.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] Allegheny County (Pennsylvania) real estate assessment website for addresses If you want to go through the import process, I'd recommend using the address point file from Alleghany county:ftp://www.pasda.psu.edu/pub/pasda/alleghenycounty/AlleghenyCounty_AddressPoints201311.zip I found it while poking around for addresses to add to my address data index:https://docs.google.com/spreadsheet/ccc?key=0AsVnlPsfrhUIdEVZTzVFalFYYnlvTkc0R05wcUpsWVEusp=drive_web#gid=0 On Tue, Feb 4, 2014 at 10:23 AM, James Mast rickmastfa...@hotmail.com wrote: I'm just wondering, do you guys think that Allegheny County's real estate assessment website is OdbL compatible to use to gain addresses to put into OSM? http://www2.county.allegheny.pa.us/RealEstate/Search.aspx I haven't taken any addresses from it, but if it's compatible with OSM, it could be a gold mine for getting a big area of addresses done for the OSM world. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] South Carolina State Highways - primary overload
All right, I'll be sending the e-mail to the DWG in a few minutes then. Life has been a little crazy here preventing me from doing it sooner than this. -James From: mart...@openstreetmap.us Date: Wed, 29 Jan 2014 07:07:48 -0800 To: rickmastfa...@hotmail.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] South Carolina State Highways - primary overload I think you're making the right call, James. On Tue, Jan 28, 2014 at 11:33 PM, James Mast rickmastfa...@hotmail.com wrote: So, nobody else has a comment on how the repair work should be done? Last chance before I respond back to the DWG e-mail (and as of right now, will be recommending just the reverting of only the 'highway=xxx' upgrades). Just want to make sure the masses don't have a problem with this. -James From: rickmastfa...@hotmail.com To: talk-us@openstreetmap.org Date: Mon, 20 Jan 2014 05:01:19 -0500 Subject: Re: [Talk-us] South Carolina State Highways - primary overload Nobody else has a comment on what should be done here? If you don't remember the start of this discussion of this subject, here's the link to the original post I made on this subject to the list so you can see it: https://lists.openstreetmap.org/pipermail/talk-us/2013-December/012349.html -James Date: Thu, 16 Jan 2014 07:24:50 -0500 From: nice...@att.net To: talk-us@openstreetmap.org Subject: Re: [Talk-us] South Carolina State Highways - primary overload On 1/16/2014 12:16 AM, James Mast wrote: Anyways guys, post what you think should be done here so I can get back to the DWG on this subject. (I'm personally all for the reverting of the highway=xxx upgrades this user has done only and not a full scale revert of all his changesets as he did do some highway cleanup in some changesets while doing the 'highway=xxx' upgrades.) I would be for the revert of the highway=xxx changes. While the Wiki has no hard and fast rule on the 'right way' to tag these, clearly some information has been lost by eliminating a highway type. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Martijn van Exel President, US Chapter OpenStreetMap http://openstreetmap.us/ http://osm.org/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] South Carolina State Highways - primary overload
So, nobody else has a comment on how the repair work should be done? Last chance before I respond back to the DWG e-mail (and as of right now, will be recommending just the reverting of only the 'highway=xxx' upgrades). Just want to make sure the masses don't have a problem with this. -James From: rickmastfa...@hotmail.com To: talk-us@openstreetmap.org Date: Mon, 20 Jan 2014 05:01:19 -0500 Subject: Re: [Talk-us] South Carolina State Highways - primary overload Nobody else has a comment on what should be done here? If you don't remember the start of this discussion of this subject, here's the link to the original post I made on this subject to the list so you can see it: https://lists.openstreetmap.org/pipermail/talk-us/2013-December/012349.html -James Date: Thu, 16 Jan 2014 07:24:50 -0500 From: nice...@att.net To: talk-us@openstreetmap.org Subject: Re: [Talk-us] South Carolina State Highways - primary overload On 1/16/2014 12:16 AM, James Mast wrote: Anyways guys, post what you think should be done here so I can get back to the DWG on this subject. (I'm personally all for the reverting of the highway=xxx upgrades this user has done only and not a full scale revert of all his changesets as he did do some highway cleanup in some changesets while doing the 'highway=xxx' upgrades.) I would be for the revert of the highway=xxx changes. While the Wiki has no hard and fast rule on the 'right way' to tag these, clearly some information has been lost by eliminating a highway type. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] South Carolina State Highways - primary overload
Nobody else has a comment on what should be done here? If you don't remember the start of this discussion of this subject, here's the link to the original post I made on this subject to the list so you can see it: https://lists.openstreetmap.org/pipermail/talk-us/2013-December/012349.html -James Date: Thu, 16 Jan 2014 07:24:50 -0500 From: nice...@att.net To: talk-us@openstreetmap.org Subject: Re: [Talk-us] South Carolina State Highways - primary overload On 1/16/2014 12:16 AM, James Mast wrote: Anyways guys, post what you think should be done here so I can get back to the DWG on this subject. (I'm personally all for the reverting of the highway=xxx upgrades this user has done only and not a full scale revert of all his changesets as he did do some highway cleanup in some changesets while doing the 'highway=xxx' upgrades.) I would be for the revert of the highway=xxx changes. While the Wiki has no hard and fast rule on the 'right way' to tag these, clearly some information has been lost by eliminating a highway type. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] South Carolina State Highways - primary overload
I have finally heard back from the DWG group on this subject. They said that they lack the manpower to actually investigate these edits and find out what they should be. However, they said that they can identify *every* highway=xxx upgrade that the user did in a time frame and revert them. They would need to rely on us here in the talk-us community though to let them know if this seems like a sensible thing to do in this case before they do anything. So, do you guys think we should ask them to do a revert on all of the highway=xxx upgrade changes the user made in South Carolina (and also where he did it in Georgia too)? We would need to try to lock down the time period that he did this in changeset # wise so that there are no problems with the highway type revert. It just sucks that with the new OSM layout, that got rid of the page #'s in the URLs for a user's changesets. That would have made this job a tad easier to do allowing just url editing to get to older changesets he did. Anyways guys, post what you think should be done here so I can get back to the DWG on this subject. (I'm personally all for the reverting of the highway=xxx upgrades this user has done only and not a full scale revert of all his changesets as he did do some highway cleanup in some changesets while doing the 'highway=xxx' upgrades.) -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[OSM-talk] Interesting use of OSM data in Battlefield 4
I just recently got Battlefield 4 and noticed that in the leaderboards area, that they have a real map so you can add your location to see how others around you are ranked. To my surprise, they are using OSM data for the map. I confirmed this by going down to Corridor H (US-48) in West Virginia and it was exactly how I did it in the OSM data on the most recently opened segment of that highway. I just thought that this was interesting and wanted you guys to know about this. -James ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Proposal to Remove Two Duplicate Route Relations in Texas
And now that I've looked into this more, Cam4rd98 didn't cause any of the problems here this time. So, this should have been just brought to the group as how to fix it as a whole and not call out any specific user. The last editor isn't always the person who caused the problems. You should always take a look at the entire history of a relation/way/node to figure out who might need to be contacted to help resolve something. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Interesting use of OSM data in Battlefield 4
I just recently got Battlefield 4 and noticed that in the leaderboards area, that they have a real map so you can add your location to see how others around you are ranked. To my surprise, they are using OSM data for the map. I confirmed this by going down to Corridor H (US-48) in West Virginia and it was exactly how I did it in the OSM data on the most recently opened segment of that highway. I just thought that this was interesting and wanted you guys to know about this. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposal to Remove Two Duplicate Route Relations in Texas
From: skqu...@rushpost.com To: talk-us@openstreetmap.org Date: Wed, 8 Jan 2014 00:01:59 -0600 Subject: Re: [Talk-us] Proposal to Remove Two Duplicate Route Relations in Texas I don't think Cam4rd98 is still an active mapper. If you are absolutely, positively sure they are duplicates, I say go ahead and prune. -- Shawn K. Quinn skqu...@rushpost.com ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us He is still an active mapper. He's done over 20 edits in the last 17 days. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
I know awhile back I updated the ref tag on the short segment of I-77 that has I-74 cosigned with it from ref=I 74;I 77 to ref=I 77;I 74 because along that segment, they are using I-77's mile markers. Plus it helps to know that I-77 was there long before the two I-74 signs (one NB and one SB) were added along it. So, at least when it comes to Interstates with 2 or more Interstates posted on a segment, you should always put the one that the mile markers/exit numbers are based off of first in the way ref tag. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
I have no problems going with either : or ; for the separator for unsigned segments of highways in the role area. What does everybody else think? As this shouldn't be decided by just two people. We do still need the consensuses of [talk-us] before any mass changing of relations happen. Later tonight if I have time I'll do up an example route for this (US-19 Truck here in Pittsburgh) so everybody can see this in action at least and then we can link an example to the wiki page. The reason I selected the route above is because not only is it a short route, it does have it's middle segment hidden while on Interstates. Plus I have tons of experience with it having traveled it a lot in my life. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
Looks good to me Martin. I'm game with the role = north:unsigned tagging for unsigned segments. Now all we would need to do is get JOSM to show the cardinal directions the same way in the relation editor like forward/backward so that you can verify a route is all there and there are no gaps (unless there is one for real like I-49 currently has in LA since they are extending it). And on this subject it brings up an interesting problem. What to do when a highway has C/D lanes that are part of the main highway (like the 401 in Toronto, Ontario, Canada). I know a few Interstates have these, like I-80 I-95 in NJ. There should be a way to have something like role = east:express role = east:local in a directional relation (I fully support Interstates to have separate relations for each direction on 2di's; but on 3di's they should stay one relation unless it's like a 30+ mile route like I-476/I-376 here in PA) and have JOSM's relation editor show a split in the highway so you can verify there are no gaps in those areas for the relation. Also, I have noticed you've been doing some editing for the Highway Directions In The United States wiki page [1] and mention the role = north;south idea for single carriageways so that the routes could tell people which direction the way goes. I think that might still need a little more discussion here on [talk-us] before we attempt to implement it and mention it on that page (maybe have a vote for that part on the talk page??). I personally think it could work, but we would need all of the editors (JOSM, iD, Potlatch2) to have support to be able to reverse those roles correctly if somebody reverses the way. Can't allow those to get messed up once added. (On a side note, iD doesn't alert you if you delete a way that's part of a relation yet, which isn't good at all.) -James From: m...@rtijn.org Date: Tue, 10 Dec 2013 18:16:54 -0800 To: rickmastfa...@hotmail.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] Separate relations for each direction of US State highways. Hmm yes, on second thought, a second key on role members may not be so straightforward ;) How silly of me to suggest such a thing. Let's keep things pragmatic then and let me suggest we go with role=north:unsigned for unsigned sections. I don't particularly like the ; because it suggests a list of things that are of similar nature (like apple;pear;mango) whereas a colon to me suggests a further scoping which is what this is. So role=north / role=west / role=south / role=east for relation members to indicate cardinal directions, and role=north:unsigned / role=west:unsigned / role=south:unsigned / role=east:unsigned for unsigned segments, unless the entire numbered route is unsigned, in which case unsigned_ref would do the job. Any more insights and comments? Thanks Martijn On Fri, Dec 6, 2013 at 5:31 PM, James Mast rickmastfa...@hotmail.com wrote: Well, to add a second role to an item in a relation would require an entire overhaul of relations, the editors, and even the OSM database I would think to do it. That's why I suggested doing the ; or | because data consumers already know how to deal with the ; at least in the ref tags on normal ways (look @ Mapquest Open and their rendering of highway shields based off the ref tags on ways). Heck, maybe even a : might work (role = north:unsigned). -James From: m...@rtijn.org Date: Thu, 5 Dec 2013 23:01:09 -0700 Subject: Re: [Talk-us] Separate relations for each direction of US State highways. To: rickmastfa...@hotmail.com On Thu, Dec 5, 2013 at 6:17 PM, James Mast rickmastfa...@hotmail.com wrote: Martijn, How would you suggest using the role:signed = yes/no (or is this just for completely unsigned highways like I-124 in TN where we can add this info into the main tags of the relation)? We would still need a way to keep the direction for the unsigned segment of the route in the role so that the relation editor in JOSM (and other analyzers) would be able to know that the route is still going North/East or South/West, especially on a dual-carriageway (like what happens with US-52 on I-94 in MN and US-19 Trunk on I-279/I-376 here in Pittsburgh, PA) and would let you know it's still in one piece. My idea was to just use role=north/east/south/west for the regularly signposted sections and role=north/east/south/west role:signed=no for the hidden sections. It feels contrived but I also don't see a much better solution in terms of striking a balance between keeping relation complexity in check and information redundancy / ease of maintenance. If you don't like the | separating the role = north|unsigned, maybe use the ; or , instead? I could see the ; working just as good as the |. I just want to follow whatever practice is most common for more
Re: [Talk-us] South Carolina State Highways - primary overload
Tim, I sent the user a message inside of OSM that did all of this changing of the state highways in SC to primary/trunk and haven't gotten a response back yet in over 24h. I'll be contacting the DWG later tonight (giving the guy another ~5 hours to respond before I e-mail the DWG) about this subject. So please don't try to do many more changes just in case they decide a mass revert of this users changesets is the best way to fix all of this. That way, there will not be any major conflicts when they try to do this if possible. -James Date: Tue, 10 Dec 2013 11:13:10 -0500 From: tim.huem...@gmail.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] South Carolina State Highways - primary overload I found this to be very annoying. I did a lot of work on the SC Highways some time back. I noticed that in a few counties most of the state highways were marked as primary. I reverted most of them back to secondary except for the ones that were truly trunk routes. Its frustrating to see work that you spent a lot of time and effort on get vandalized as such On Mon, Dec 9, 2013 at 7:49 AM, Mike N nice...@att.net wrote: On 12/9/2013 12:42 AM, James Mast wrote: So, does anybody else agree with me on this subject of primary overload in South Carolina? If so, how do we go about fixing this with a reasonable approach? Looking at some of the history of some of the ways, it seems that only one user was doing the upgrade from secondary to primary/trunk over the past 4+ months. Disclaimer: I'm not familiar with DOT classifications in general. At first, the user seemed to be knowledgeable about highway classifications for the segments in question. But I agree - now that nearly everything was just changed to primary, it seems to be both less useful and inconsistent with most of the rest of the US. It seems that the intent was to match some other map rendering or road classification which has fewer classification levels. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Tim Huemmer Webmaster Owner RRPictureArchives.NET ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] The new OpenStreetMap.org design
To: talk@openstreetmap.org From: o...@malenki.ch Date: Wed, 4 Dec 2013 18:31:44 +0100 Subject: Re: [OSM-talk] The new OpenStreetMap.org design A regression is the inability to browse the changesets of users efficiently. Example: From time to time I need to have a look at what I mapped e.g. about two years ago. Until now I could skip several pages of my edit history by clicking the according links [page 1 2 3 ...11] or editing the url like it is still used on nodes and ways of changeset. Now browsing the distant history of edits is a pita. [Load more]period I fully agree with this. There is now no way to link somebody to a specific page if a user has several questionable edits that aren't within his last ~20 edits. This is something IMO that needs to be brought back ASAP. -James ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-us] South Carolina State Highways - primary overload
Is it just me, or are there way too many primary state highways when some of them should really be secondary instead? The US Highways should normally be the primary/trunk highways and only a few select State Highways should be primary or trunk. To be honest, it seems that 98% of all the State highways segments in SC are marked as primary right now. There is no way almost all of the State Highways in SC can be primary. Just look at almost any other state. None are overloaded with primaries. One of the major routes that sticks out to me is SC-64 near the Savannah River Site where it's marked as trunk going to the security gate [1]. Now, if the Savannah River Site didn't exist and the highway was still open to the public past that point, I wouldn't agrue the point of it being trunk or primary. But since that segment of state highway goes nowhere anymore after leaving US-278 going West, this would be a classic case of it having to be secondary, or maybe even being tertiary. So, does anybody else agree with me on this subject of primary overload in South Carolina? If so, how do we go about fixing this with a reasonable approach? Looking at some of the history of some of the ways, it seems that only one user was doing the upgrade from secondary to primary/trunk over the past 4+ months. He also did some of this in Georgia, but not to the extent as in South Carolina. Unfortunately, this user did it over 200+ changesets, so, if reverting was the option, it would take forever I would think. -James [1] - http://www.openstreetmap.org/#map=14/33.2388/-81.4205layers=N ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
Well, to add a second role to an item in a relation would require an entire overhaul of relations, the editors, and even the OSM database I would think to do it. That's why I suggested doing the ; or | because data consumers already know how to deal with the ; at least in the ref tags on normal ways (look @ Mapquest Open and their rendering of highway shields based off the ref tags on ways). Heck, maybe even a : might work (role = north:unsigned). -James From: m...@rtijn.org Date: Thu, 5 Dec 2013 23:01:09 -0700 Subject: Re: [Talk-us] Separate relations for each direction of US State highways. To: rickmastfa...@hotmail.com On Thu, Dec 5, 2013 at 6:17 PM, James Mast rickmastfa...@hotmail.com wrote: Martijn, How would you suggest using the role:signed = yes/no (or is this just for completely unsigned highways like I-124 in TN where we can add this info into the main tags of the relation)? We would still need a way to keep the direction for the unsigned segment of the route in the role so that the relation editor in JOSM (and other analyzers) would be able to know that the route is still going North/East or South/West, especially on a dual-carriageway (like what happens with US-52 on I-94 in MN and US-19 Trunk on I-279/I-376 here in Pittsburgh, PA) and would let you know it's still in one piece. My idea was to just use role=north/east/south/west for the regularly signposted sections and role=north/east/south/west role:signed=no for the hidden sections. It feels contrived but I also don't see a much better solution in terms of striking a balance between keeping relation complexity in check and information redundancy / ease of maintenance. If you don't like the | separating the role = north|unsigned, maybe use the ; or , instead? I could see the ; working just as good as the |. I just want to follow whatever practice is most common for more specific information related to a tag, and thinking of the lanes and access tagging systems I thought the role:signed approach would make the most sense. I just want to find a solution to keep the route all in one piece instead of having to have two separate relations for it's signed segment and one covering the entire route with the unsigned_ref tag. Annoying and easily broken by new users who don't know why there are two relations for the exact same route on some segments. I agree 100%. -- Martijn van Exel http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Bing imagery update
According to http://www.ncgicc.com/Default.aspx?tabid=135 and links
therein, they are doing 1/4 of the state per year on a rolling basis.
This year they photographed the eastern Piedmont and are currently
getting it ready for release, probably in early 2014. In 2014 they are
photographing northern Piedmont and mountains, so I presume 2015 will be
southern piedmont and mountains, including Mecklenburg County.
I have the following wms link working to serve all the latest
orthoimagery.
wms:http://services.nconemap.com/arcgis/services/Imagery/Orthoimagery_Latest/ImageServer/WMSServer?FORMAT=image/tiffVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=Orthoimagery_LatestSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
James
On Wed, 2013-12-04 at 21:59 -0500, Mike N wrote:
On 12/4/2013 9:07 PM, Kam, Kristen -(p) wrote:
James,
I located NAIP imagery for the state of North Carolina.
That prompted my recall of an open NC state-run offleaf imagery source.
It worked in JOSM back in 2010. I see that they have updated some
coastal imagery in 2012; I'm not sure how far this comes. They're in
the process of updating the whole state for 2013, so it might include
Charlotte.
They restructured the server, and I can't even get JOSM to work with
the 2010 imagery; it goes into an endless downloading loop and displays
nothing. Are there any WMS / JOSM gurus who can get this working?
Try adding the
WMS:
http://services.nconemap.com/arcgis/services/Imagery/Orthoimagery_2012/ImageServer/WMSServer
More info on the web site
http://www.nconemap.com/OrthoimageryforNorthCarolina.aspx
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
Martijn, How would you suggest using the role:signed = yes/no (or is this just for completely unsigned highways like I-124 in TN where we can add this info into the main tags of the relation)? We would still need a way to keep the direction for the unsigned segment of the route in the role so that the relation editor in JOSM (and other analyzers) would be able to know that the route is still going North/East or South/West, especially on a dual-carriageway (like what happens with US-52 on I-94 in MN and US-19 Trunk on I-279/I-376 here in Pittsburgh, PA) and would let you know it's still in one piece. If you don't like the | separating the role = north|unsigned, maybe use the ; or , instead? I could see the ; working just as good as the |. I just want to find a solution to keep the route all in one piece instead of having to have two separate relations for it's signed segment and one covering the entire route with the unsigned_ref tag. Annoying and easily broken by new users who don't know why there are two relations for the exact same route on some segments. -James From: m...@rtijn.org Date: Thu, 5 Dec 2013 09:25:11 -0700 To: rickmastfa...@hotmail.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] Separate relations for each direction of US State highways. Hi James, I had not thought of the Case of the Hidden Segments. It makes sense to tag them, but would it not be more in line with general OSM tagging practice to use role:signed = yes/no? I think it's a valuable extension on the role discussion, perhaps you can add a paragraph to the wiki page http://wiki.openstreetmap.org/wiki/Highway_Directions_In_The_United_States with an example? I found this photo (not ideal and I'm not sure if we could use it on the wiki, but it's something ;) http://www.ajfroggie.com/roadpics/mn/us052/nb-i94e.jpg Best Martijn On Thu, Nov 28, 2013 at 3:43 PM, James Mast rickmastfa...@hotmail.com wrote: We also have to come up with a way to designate hidden segments of a route so we don't have to have two separate relations for highways that have segments that are hidden. Some of the examples I'm thinking of are like US-52 in MN when it's on I-94 and US-19 Trunk here in Pittsburgh, PA while it's on I-279/I-376. Both states have signs for theses routes telling people to follow said Interstates for those routes and then no more reference to them till when they leave the Interstates. I'm thinking that we could possibly tag the roles for them in the relations this way: role=north|unsigned. This would also help for the renders that use the relations to add the shields. They would be able to use the |unsigned part to know not to add the shields along that way. As for the highways that are completely hidden, the unsigned_ref tag in the relation will work perfectly for them still (US-85 in NM as an example). Anybody else agree with me that this might work better than the two relations for the highways that have segments that are hidden? -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Bing imagery update
I just wish Bing would update the imagery around Charlotte, NC. Especially because of the building of the missing link of I-485. And I can't forget to mention I-85 as well since it's being widened from 2 to 4 lanes going North from I-485. I so want to clean that major turbine interchange of I-85/I-485 up since we still have the old pre-construction configuration in OSM. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Welcome box on the new map page
Well, I do know with the new map page change, all the changeset search feeds are now completely broken. For instance, this url [1] used to create a feed for the for following area -80.54,40.358,-79.526,40.779 and let me know if there were any changesets that in that bounding box. Now, all I get are the last 20 changeset in all of OSM!!! That isn't good at all if you're trying to keep a watch on your home area for changes!! There should have been a built in feed redirection from the old style here to the new style instead being broken the first time a user used the old style. And when I try to access the new history menu [2] and pull the RSS FEED from the site, Firefox's build in Subscribe feature gives me this feed URL [3]. The OSM site should be giving the user a valid feed url for the area you're viewing, not just the base feed. Thankfully, I've figured out what the new feed link is for my watch area manually and updated it in my RSS feed reader [4]. Still, there needs to be some tweaks to the history part of the new design. -James [1] - http://www.openstreetmap.org/browse/changesets/feed?bbox=-80.54%2C40.358%2C-79.526%2C40.779 [2] - http://www.openstreetmap.org/history#map=10/40.4433/-79.6893layers=N [3] - http://www.openstreetmap.org/history/feed [4] - http://www.openstreetmap.org/history/feed?bbox=-80.54%2C40.358%2C-79.526%2C40.779 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Separate relations for each direction of US State highways.
Peter, it would just be for the relations. It would stay the current status-quo for the ways using at all times the ref unsigned_ref tags (see I-394 example below). In your example with I-394 and US-12, if you look at the way's tags [1], you can see that US 12 is still mentioned, but under the tag of unsigned_ref. That's how we have to so it as too many other data users wouldn't understand anything special in the normal ref tag on ways saying something is unsigned. That's why the east|unsigned stuff would only work in the relations. Here's an example of what I did for US-19 Truck here in Pittsburgh which has it's multiplex with I-279 I-376 hidden (except for the small segment South of the Fort Pitt Tunnels because of how the ramps are). First, here's the relation for the signed poartion of the route [2], and here's the relation for the entire route [3]. As you can see, on the entire route relation, I have the unsigned_ref tag for the route number, while in the signed relation, it has the normal ref tag with the route number. I had to do it this way so that all the data users who use the relations for adding shields didn't erroneously add the Truck US-19 shields to I-279/I-376. Sure, you could say this is tagging for the render, but it also is mapping the ground truth since there are no US-19 Truck shields along those two Interstates. This sign [4] on Southbound I-279 is the only mention of US-19 Truck along the Interstates till it leaves I-376 just after the Fort Pitt Tunnels. (NOTE: for those who don't know, US-19 Truck used to be mutliplexed with just I-279 till I-279 was shortened to the Point in Downtown Pittsburgh and I-376 was extended from that point over the Parkway West segment of I-279 in 2009.) (Also another little history lesson here, but Pittsburgh's US-19 Truck is the only officially approved Truck route with the AASHTO and shows up in the logs.) So, if we all agree on how to handle short segments of unsigned highways in relations, I could then re-combine the route into just one relation and tag the unsigned ways as role=north|unsigned and role=south|unsigned along the I-279/I-376 multiplexes. HOWEVER, on routes that are completely unsigned (like hidden I-124 in TN [5]), we would just keep use the unsigned_ref tag in the relations as we are currently doing since it doesn't have a signed segment. But I wouldn't be totally opposed to doing it like the hidden segment of US-19 Truck mentioned above inside of the relation. I hope this fully explains what I'm suggesting to do Peter and everybody else. ;) -James [1] - http://www.openstreetmap.org/way/43147401 [2] - http://www.openstreetmap.org/relation/571349 [3] - http://www.openstreetmap.org/relation/3078417 [4] - http://goo.gl/maps/4fJYC [5] - http://www.openstreetmap.org/relation/1861175 Date: Sat, 30 Nov 2013 01:01:29 -0800 From: peter.dav...@crc-corp.com To: rickmastfa...@hotmail.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] Separate relations for each direction of US State highways. James, I have a question about this, though it all sounds good to me in principle. Is your proposal just about the relations? What would we do on the refs of the ways? For example, on I-394 in Minneapolis and western suburbs, a mapper has left off US 12 because it is at least partly unsigned. So we have way ref I 394 instead of I 394;US 12. For my applications I'd prefer it said I 394;US 12, because we need to track the overlaps (which we and our 10 state DOT customers call double banding). But if you also want to suppress shields from maps in such areas, could we enter the way ref as I 394;US 12|unsigned ? Peter On Thu, Nov 28, 2013 at 2:43 PM, James Mast rickmastfa...@hotmail.com wrote: We also have to come up with a way to designate hidden segments of a route so we don't have to have two separate relations for highways that have segments that are hidden. Some of the examples I'm thinking of are like US-52 in MN when it's on I-94 and US-19 Trunk here in Pittsburgh, PA while it's on I-279/I-376. Both states have signs for theses routes telling people to follow said Interstates for those routes and then no more reference to them till when they leave the Interstates. I'm thinking that we could possibly tag the roles for them in the relations this way: role=north|unsigned. This would also help for the renders that use the relations to add the shields. They would be able to use the |unsigned part to know not to add the shields along that way. As for the highways that are completely hidden, the unsigned_ref tag in the relation will work perfectly for them still (US-85 in NM as an example). Anybody else agree with me that this might work better than the two relations for the highways that have segments that are hidden? -James ___ Talk-us mailing list Talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
We also have to come up with a way to designate hidden segments of a route so we don't have to have two separate relations for highways that have segments that are hidden. Some of the examples I'm thinking of are like US-52 in MN when it's on I-94 and US-19 Trunk here in Pittsburgh, PA while it's on I-279/I-376. Both states have signs for theses routes telling people to follow said Interstates for those routes and then no more reference to them till when they leave the Interstates. I'm thinking that we could possibly tag the roles for them in the relations this way: role=north|unsigned. This would also help for the renders that use the relations to add the shields. They would be able to use the |unsigned part to know not to add the shields along that way. As for the highways that are completely hidden, the unsigned_ref tag in the relation will work perfectly for them still (US-85 in NM as an example). Anybody else agree with me that this might work better than the two relations for the highways that have segments that are hidden? -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
However, with the split Interstates (I-35W/I-35E in both TX and MN I-69E/I-69C/I-69W in TX) US Highways (and a few state highways), the letters are part of the route number. So, they wouldn't have any effect on the role part for relations. When given routing info, they'd act just like their non-lettered siblings. Turn left onto Northbound I-35E on-ramp or something similar. Also, I don't know why some people put the letter as a modifier in some of the relations[1]. Maybe we could also remove that line (since the ref line has the proper number still) when we convert everything to the cardinal directions. -James [1] - http://www.openstreetmap.org/browse/relation/416519 Date: Wed, 27 Nov 2013 22:22:47 -0500 From: saiarcot...@gmail.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward The same applies for I-35 in the DFW area; I-35E runs through Dallas while I-35W runs through Fort Worth. Saikrishna Arcot On Wed 27 Nov 2013 03:56:51 PM EST, Richard Welty wrote: On 11/27/13 2:46 PM, John F. Eldredge wrote: You also have compass-point letters used to distinguish between branches of the same route. For example, US 31 runs north/south. A portion of it branches off as US 31W, which runs roughly parallel, some miles westward of US 31, and eventually merges back into it. in the Hudson Valley of NY, we have US 9/US 9W, which behave similarly; 9 is on the east side of the river south of Albany, and 9W is on the west side. (on top of that, NYS has a thicket of state routes which are spurs and loops off of 9/9W, e.g. NY 9A, 9B, ... 9H, 9J... mapping in NY is fun. whee!) richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[OSM-talk] Key:highway it's talk page moved?
Does anybody know why they were moved the other day on the wiki? I think it might have just been an honest mistake by the user, but is there any way to revert it so that the original history is back in place for Key:highway? -James ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:highway it's talk page moved?
Pieren, I don't think it was moved back per say. It seems to me that somebody just copied the last good version from before the move and then pasted it over the redirect. Thus, that's why the history [1] the talk page [2] didn't return to the main page. -James [1] - http://wiki.openstreetmap.org/w/index.php?title=Key:highwayaction=history [2] - http://wiki.openstreetmap.org/w/index.php?title=Talk:Key:highwayredirect=no Date: Tue, 26 Nov 2013 11:58:31 +0100 From: pier...@gmail.com To: talk@openstreetmap.org Subject: Re: [OSM-talk] Key:highway it's talk page moved? On Tue, Nov 26, 2013 at 11:50 AM, James Mast rickmastfa...@hotmail.com wrote: The page has been moved yesterday and restored yesterday as well. But surprisingly, the page history is lost... A mediawiki bug ? Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Separate relations for each direction of US State highways.
Yes, that is correct Martijn. Would allow us to make sure relations are intact inside of JOSM if the cardinal directions segments got the same split graphic that forward/backward does in the relation editor. :) I think that was one of the major reasons most of the relations in the USA got the forward/backward roles in the first place since the north/south east/west roles didn't. Also, here again is the link to the ticket on JOSM that added those graphics for the forward/backward roles if it will help you to see how feasible cardinal direction graphics would be. https://josm.openstreetmap.de/ticket/5109 - James From: m...@rtijn.org Date: Tue, 26 Nov 2013 09:26:27 -0700 Subject: Re: [Talk-us] Separate relations for each direction of US State highways. To: rickmastfa...@hotmail.com CC: talk-us@openstreetmap.org You mean that in the relation editor, you would be able to see the same split between north / south and east / west that you currently see for forward/backward? (like here https://www.dropbox.com/s/dwi2gx8tixsuva2/Screen%20Shot%202013-11-26%20at%209.25.08%20AM.jpg ) Yes, that makes sense to me. I can look into how much work that would be. On Mon, Nov 25, 2013 at 6:14 AM, James Mast rickmastfa...@hotmail.com wrote: So, nobody has a comment on my idea (from the 22nd) of getting JOSM to show north/south or east/west splits in the relation editor to be displayed the same way as the forward/backward gets shown already? I would try to do some coding to allow that to happen in JOSM, but I don't know how to code in Java. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
So, nobody has a comment on my idea (from the 22nd) of getting JOSM to show north/south or east/west splits in the relation editor to be displayed the same way as the forward/backward gets shown already? I would try to do some coding to allow that to happen in JOSM, but I don't know how to code in Java. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
From: lordsu...@gmail.com Date: Thu, 21 Nov 2013 03:27:21 -0500 To: marti...@telenav.com CC: krist...@telenav.com; talk-us@openstreetmap.org; h...@telenav.cn; vladim...@telenav.com; chr...@telenav.com Subject: Re: [Talk-us] Separate relations for each direction of US State highways. The only problem I can anticipate with this tagging scheme is that it's possible some editors don't understand anything other than left/right/forward/backward (I think), we could end up in data loss situations fairly easily. For example: way X pointing east is marked in relation Y as east (presumably we could assume that east = forward and the opposite cardinal direction west is backward). User reverses way X. Now the relation role is potentially backward. JOSM seems to understand at least north/south and east/west and offers to fix it (see http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayTagCorrector.java); no idea if iD or Potlatch do. We'd also need to make the validation tools smarter to recognize lossage (for example, realizing that the route is unbroken only if the chain of role tags once you account for the directions of the underlying ways is monotonic), Chris -- Chris Lawrence lordsu...@gmail.com Website: http://www.cnlawrence.com/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us However Chris, there is a pretty big problem that JOSM has with cardinal directions, and it has to do with the relation analysis. We need JOSM to be able to split the lines with cardinal roles when looking at a relation just like how it does it currently with the roles forward/backward [1]. That would be a major step forward it making sure relations have no gaps if/when we fully go cardinal from forward/backward. If you want to see an example, download US-30's WV relation [2] into JOSM and change the cardinal roles all back to forward. You can then see the value of those splits in relation analysis inside of JOSM that the roles forward/backward have in making sure the relation has no gaps. -James [1] - https://josm.openstreetmap.de/ticket/5109#comment:18 [2] - http://www.openstreetmap.org/browse/relation/1593699 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-ca] Why does a search for Edmonton show the city out in the country?
If you look at the history, you'll see that way back in the dark ages (Nov 2008), I tried creating a way that defined the city limits of Edmonton. Actually I was creating a way that defined the boundary of Strathcona County, and part of that way was coincident with the City of Edmonton boundary. In the process I decided to create the outline of Edmonton. I was also trying to figure out how to share nodes and ways between two different entities. (Which to this day, I still don't really understand.) This is a remnant of that effort. I would create a way defining the city limits in an attempt to get it to show up on the map. Someone would come along and break it, I would try to fix it, someone would break it, I would try to fix it, etc... I gave up trying to fix it, so you get what you have now... Here's another remnant of part of the boundary between Strathcona County and Lamont County. I see it was just touched a few months ago by someone deciding that the way needed to be named Strathcona County when in fact it is not the county, but rather an administrative boundary between two adjacent entities... but on the brighter side I see Strathcona County is still intact! http://www.openstreetmap.org/browse/relation/50382 There is a city limits boundary (called a county boundary) that looks like it defines Edmonton properly. http://www.openstreetmap.org/browse/relation/2564500 If you look at the history for way 28295454 which you are talking about, you'll see that some dingleberry back in 2008 put a name tag on the way, which then takes you to the center of that way when pointing at Edmonton. http://www.openstreetmap.org/browse/way/28295454/history I just removed the name, type, and area tags from the way. That should stop nominatim from falsely finding it. Yup, now you get a psuedo node in the middle of the relation defining the outline of Edmonton, and a physical node in the reflecting pool at the Legislature with a bunch of tags on it. I really would like to have all of the municipal boundaries on the map of Alberta, but the data is locked up under copyright law. I thought I found a free source of the data, but when I queried why I couldn't access the data, I got a response that said Oops, the note you saw saying the data is freely available is wrong... so sorry, we'll fix that! Interestingly enough, that was a verbal response via telephone. No automated email response, a real live person! -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] Separate relations for each direction of US State highways.
Well, one of the main reasons I brought this up is because I've noticed another user changing some relations from forward/backward to west/east/south/north without discussing this here on talk-us. That user would happen to be KristenK. This user has been doing this since the 11th at least all across the US. Maybe a block is needed so he can explain here on talk-us why he's doing all these mass edits? (or was this a challenge on Battle Grid that I wasn't aware of?) Only reason I just noticed this was because a recent change of his edits finally triggered in one of my RSS feed watch areas (US-30 WV relation). Another reason is for those rare US highways that change posted cardinal directions within one state (US-98 is posted both North/South and East/West in Florida), or change at state borders (US-35 and US-52 do this several times). We need to figure out a way to account for this so that the routers give the person the correct info. As we do know, diagonal routes can be a major pain in this area. -James (rickmastfan67) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Separate relations for each direction of US State highways.
I'm just curious, but what's everybody's opinion on this? I know it's acceptable for the Interstates (some are setup this way, some aren't) since they are all divided, but what about for US Highways and State Highways? I know that we want to eventually have the cardinal directions in OSM for the routers so they can properly tell people which direction the of the highway they need to turn onto (like turn left onto Westbound US-30). So, how do we do this and also how do we let people know that aren't part of talk-us about any possible change so that relations don't get broken after they've been converted into separate directions? I mean, we can turn the current state relations for a highway into a super relation for each state once we create a new relation for each direction. Also how are we going to name each relation? Something like this: US 48 (WV - eastbound) US 48 (WV - westbound) US 48 (WV - super) Plus we can't forget to add in the direction=* tag in the relations as well as the role area (or should we just use forward there or even tag nothing there, and leave the direction in the tag area) as we can't expect the routers to get the direction info from the name tag. So for detecting relations that get broken after they've been converted (we should do all the Interstates first, then US highways, and then State highways), we need a way to let dedicated mappers know when they've been broken (aka, a gap) so they can be fixed quickly. An idea of having a something automatically annalizing the relations whenever they are modified, kinda like the OSM Relation Analyzer [1], would work best IMO. Except with this analyzer, it produces a RSS feed that will let people subscribed to it know that there is a broken relation that needs to be repaired. And once it's been fixed, it will send out a new post on the feed saying that the relation no longer has a gap so people who see the feed later know it's been already fixed and don't waste their time checking to see if it has been fixed. And the feeds would be separate based on the network type. One for all Interstates (this would include the Business Interstates), one for US Highways (including the bannered US highways), and one for each of the 50 state highway networks. That way, you can then just subscribe to the RSS feeds that you'd want to pay attention to only instead of being flooded with updates from every highway system in one feed. If you guys want, later today, I could do a test US highway in this setup. I would recommend US-48 in WV/VA as it's one of the shorter US Highways out there, plus it mostly a divided highway in WV as it's been built that way and I think it's completely un-divided in VA. Also, on a side note, do you guys think we should remove the symbol tags in the relations from all the Interstates/US highways they show up in at the same time? So, let's get this discussion going! -James (rickmastfan67) [1] - http://ra.osmsurround.org/analyzeRelation?relationId=455420 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Railroads and Railroads (Historic)
On Sun, 2013-11-10 at 18:26 -0600, John F. Eldredge wrote: We probably need a value such as railway=inactive for routes that are not in use, but still have the rails in place. The only problem is that, if someone erroneously tags an active but little-used route as inactive, this could lead to an accident if someone went hiking or rail-biking on the route. The wiki suggests, and I have seen frequently used, railway=disused -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. Dr. Martin Luther King, Jr. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Complex intersection mapping
From: marti...@telenav.com Date: Sat, 9 Nov 2013 11:31:55 -0500 To: rickmastfa...@hotmail.com CC: ste...@telenav.com; krist...@telenav.com; robe...@telenav.com; chr...@telenav.com; talk-us@openstreetmap.org Subject: Re: [Talk-us] Complex intersection mapping James, Thanks for the feedback. This is of course not good. I will make sure we will be more careful with both the lane counts and the relations not getting broken! I apologize. Did you fix the relations? If not I will. I hadn't yet since I wanted to wait till you responded on the list first so you could see what I was talking about (Changeset 18789658). The case you highlighted - I agree this one would be just fine as a single node. That's how I'm going to repair that intersection the relations that were effected, by just reverting Changeset 18789658 to return it to the way it was before yesterday. The guidance I have been giving, based on previous discussion in this thread, was to only 'dualize' the intersection when the dual carriageway clearly continues past the intersection. Does that make sense? Yep, that does make perfect sense to me. That's how I've personally been doing it. I will make sure we adhere to that guideline and not overcomplexify situations that don't require it from a ground trouth perspective. Martijn Sounds good Martijn. Thanks again for responding back on this subject. :) I'll now go ahead and do the revert of Changeset 18789658. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] AARoads
I'm one of the Admins on the forums for that site. If you want to pop onto the forums, we have a thread there dedicated to OSM. http://www.aaroads.com/forum/index.php?topic=4420.0 When/If you register @ the forums, I can personally fast track your account activation. Just shoot me a message off-list and I'll make sure it's approved quickly. ;) -James From: marti...@telenav.com Date: Thu, 31 Oct 2013 17:32:06 -0600 To: talk-us@openstreetmap.org Subject: [Talk-us] AARoads Hey all, I've been eyeballing AARoads, they have very detailed information on most of the Interstates, US highways as well as state routes, with detailed descriptions of the exits and many pictures of the signs as well. Example page here: http://www.aaroads.com/west/i-084_ut.html I am wondering if any of you are involved with that web site and also, if any of you have previously derived information from there for your mapping. I am trying to figure out if that would be legal / permitted. (I am also trying to get in touch with them directly, but if anyone here knows anyone there, that may help.) Specifically useful would be information on the signs (exit_to=, destination= on lanes) as well as the cardinal direction info that I was talking about last week. Best Martijn -- -- Martijn van Exel OSM data specialist Telenav http://www.osm.org/user/mvexel http://wiki.openstreetmap.org/wiki/User:Mvexel http://hdyc.neis-one.org/?mvexel ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[talk-au] Tagging beach driving info
Hi, Recently I was 4wding with some people and collected some info to add to OSM. I think that the access tracks to the beach and realted campsites should be tagged with: highway=track surface=sand maxspeed=NN tracktype=grade7 4wd_only=yes access=permit How should I tag the maxspeed and permit information on the beach itself? Should I be using highway=track, even though there is no track as such, just the beach sand? I've tagged it like that at http://osm.org/go/ueH4JoA~ for the moment (ignore the track-water alignment for now), but is there a better way of tagging information about driving on the beach? -- James Doc Livingston ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [OSM-talk] Mapping of multiple-lane toll areas
Here's what I did for the Gateway Toll Plaza on the PA Turnpike (I-76): http://www.openstreetmap.org/#map=17/40.90416/-80.49337 I know it isn't perfect, but at least it has the correct # of lanes for the toll plaza. Till we can a agree on a proper tag for Toll Tag Only lanes when there are still Cash lanes, I'm betting the routers direct everybody onto the E-ZPass Express lanes. -James___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Complex intersection mapping
From: marti...@telenav.com Date: Mon, 21 Oct 2013 17:40:11 -0600 To: nel...@crynwr.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] Complex intersection mapping One followup question I do have is about one of the other examples of elaborate intersections Minh raised, the Continuous Flow or or XDL intersections (example http://www.openstreetmap.org/browse/relation/1284976), I would prefer to put a no-U-turn restriction on http://www.openstreetmap.org/browse/node/1002992385 - agreed? Thanks again for all your feedback. -- Martijn van Exel OSM data specialist Telenav http://www.osm.org/user/mvexel http://wiki.openstreetmap.org/wiki/User:Mvexel http://hdyc.neis-one.org/?mvexel ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us Wouldn't splitting the primary_link at the light and adding an only_straight_on restriction be better here? -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Freeway directions
Chris, the QEW has three destinations on the counterclockwise direction. In addition to having Niagara and Fort Erie, between Toronto and Hamilton, it's posted for Hamilton. After Hamilton, it then becomes Niagara. I should know, I've traveled the QEW several times in my life. -James From: lordsu...@gmail.com Date: Fri, 18 Oct 2013 18:59:58 -0400 To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Freeway directions On Thu, Oct 17, 2013 at 3:39 PM, Brad Neuhauser brad.neuhau...@gmail.com wrote: From http://en.wikipedia.org/wiki/Interstate_Highway_System#Primary_.28one-_and_two-digit.29_routes_.28contiguous_U.S..29 : In the numbering scheme, east-west highways are assigned even numbers and north-south highways are assigned odd numbers. Odd route numbers increase from west to east, and even-numbered routes increase from south to north (to avoid confusion with the U.S. Highways, which increase from east to west and north to south), though there are exceptions to both principles in several locations.Field signage is sometimes inconsistent with the official rules; for example, US 68 is mostly (entirely?) signed north-south, and I-69 becomes east-west between Lansing and Port Huron. States may have their own rules; some states (MS, FL) follow the even-odd rules that the national routes do, some use an opposite pattern (even N-S, odd E-W), and some have no pattern at all (GA, TN). There are also cases of signage by loop nesting (inner clockwise/outer counterclockwise for RHD) - I-495 around Washington and I-440 around Raleigh NC are examples, along with GA 10 Loop around Athens GA. And in Canada the QEW is directionally signed by destination (Toronto on the clockwise carriageway, Niagara and then Fort Erie on the counterclockwise one). There may be a few more oddballs I've missed. IMO preferred practice should be a relation for each continuous cardinal direction, to keep validation simple; undivided roads should use forward/backward roles to distinguish which relation applies to the underlying way's forward/backward traversal. It shouldn't be too terribly hard to come up with an algorithm to fixup the existing single-relation cases, particularly for the ones where the routes are entirely dual carriageway, although occasionally the heuristics will be wrong and need a manual edit. Chris ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Complex intersection mapping
After hands down. That's how I do intersections like that with one minor difference. If the road on the right (as in the example) doesn't have a divider, I merge the ways before leaving the intersection so I would have 3 traffic light nodes instead of 4. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-ca] Larder Lake, Ontario completely missing
1. I don't have access to the Canvec data that includes the road names.
2. I didn't know if somebody was planning an import in that area.
3. I tend to stay out of areas that I'm not really failure with in Ontario as
I've never been that far North in Ontario (Canada Wonderland is about as far as
I've ever gone).
So, in other words, I wanted to leave it to somebody that knows the Canvec data
better as I've never done an import.
-James
Date: Tue, 1 Oct 2013 19:04:53 -0600
From: ve6...@gmail.com
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Larder Lake, Ontario completely missing
On Tue, Oct 1, 2013 at 4:15 PM, James Mast rickmastfa...@hotmail.com wrote:
Anybody want to import this town? It's completely missing in OSM data
except for {66}.
Why ask someone else to import the town? OSM makes it possible for
everyone and anyone to edit the map. That's one of the main premises
behind the OSM model.
--
James
VE6SRV
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Larder Lake, Ontario completely missing
Anybody want to import this town? It's completely missing in OSM data except
for {66}.
http://www.openstreetmap.org/browse/note/32942
-James
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Larder Lake, Ontario completely missing
On Tue, Oct 1, 2013 at 4:15 PM, James Mast rickmastfa...@hotmail.com wrote:
Anybody want to import this town? It's completely missing in OSM data
except for {66}.
Why ask someone else to import the town? OSM makes it possible for
everyone and anyone to edit the map. That's one of the main premises
behind the OSM model.
--
James
VE6SRV
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] Shields are up!
In a previous e-mail to the list, he said that relations for Turnpikes were based off the name tag for the relation, while the ones that had numbers shields were based off the network + ref tags in the relations avoiding the name tag entirely. -James From: lordsu...@gmail.com Date: Mon, 5 Aug 2013 23:30:24 -0500 To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Shields are up! On Mon, Aug 5, 2013 at 7:44 PM, James Mast rickmastfa...@hotmail.com wrote: I'm curious, but has a solution been found for the problem with the PA Turnpike because of having to split up the ways into separate ones for each direction because of the relation getting close to the 1000 way limit we've imposed? I still think that using the super relation I created to tie the route together could be used instead for applying the shields over the separate ways for each direction. I'm not sure why/how directional relations would be a problem; I have the signed part of I-22 labeled with separate east/west relations yet there aren't 2x the number of I-22 shields as there are US 78 shields (which is a single relation). http://tile.openstreetmap.us/osmus_shields/preview.html#13/33.6875/-87.0588 (For routing applications we probably want directional relations anyway, since directional heuristics based on geography aren't always right in terms of the signed/logical route direction.) Chris-- Chris Lawrence lordsu...@gmail.com Website: http://www.cnlawrence.com/ ___ 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: [Talk-us] Shields are up!
I'm curious, but has a solution been found for the problem with the PA Turnpike because of having to split up the ways into separate ones for each direction because of the relation getting close to the 1000 way limit we've imposed? I still think that using the super relation I created to tie the route together could be used instead for applying the shields over the separate ways for each direction. -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shining example of OSM use, tarnished.
I've seen some data in there that I clearly added back in March of 2012 in the Pittsburgh, PA area (new exit numbers on PA-28). So, the data isn't 4 years old like some people suggest. -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Upgraded map controls
I'm personally not liking that they now have hidden the long/short links to the map location behind buttons. Instead of just one click to get the map location, now it's two clicks and is really annoying and slowing down work for me. :( -James ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Upgraded map controls
Good to know that. Hope it can be fixed soon as I don't like having to add a second comment to the note, just to subscribe myself to it for e-mail updates. (At least the follow-up comment part is still working when you're logged in.) Anyways, I had already submitted a ticket on Trac before your e-mail arrived. I bet TomH will probably mark it as a duplicate very soon. lol. -James From: t...@macwright.org Date: Sat, 20 Jul 2013 19:09:27 -0400 To: dave...@madasafish.com CC: talk@openstreetmap.org Subject: Re: [OSM-talk] Upgraded map controls Hi James, That issue has been reported and is being worked on: https://github.com/openstreetmap/openstreetmap-website/issues/356 On Sat, Jul 20, 2013 at 6:55 PM, Dave F. dave...@madasafish.com wrote: On 20/07/2013 12:57, Paul Norman wrote: Whoops - resending to the right talk@ list Which list? All rails port pull requests and issues automatically goes to the rails-dev@ list, which is the list for discussion of rails port (web site) development If you prefer a format other than email, I believe if you watch the repo (where the source is) though github you can get all the updates. Rails port pull requests?!?! wtf. How about posting it to a real world, end user forum that speaks in English? And also not to an instant chat one that only certain people, in certain time zones, can see. I really think some developers are living in their own world. Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Application error at openstreetmap.org
Simple, something is wrong with the website. lol. I got nailed by it after I had typed up a long response to a PM. :( Seems everything else is working fine, just not the website. So, I'm thinking there were doing a change to the site, and it fubared it unfortunately. :( -James Date: Mon, 15 Jul 2013 11:15:37 +1000 From: stevag...@gmail.com To: talk@openstreetmap.org Subject: [OSM-talk] Application error at openstreetmap.org -- Application error The OpenStreetMap server encountered an unexpected condition that prevented it from fulfilling the request (HTTP 500) Feel free to contact the OpenStreetMap community if your problem persists. Make a note of the exact URL / post data of your request. This may be a problem in our Ruby On Rails code. 500 occurs with exceptions thrown outside of an action (like in Dispatcher setups or broken Ruby code) Surprised not to see anything about it on this mailing list. Can anyone explain? Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Application error at openstreetmap.org
And now it's back up. :) -James From: rickmastfa...@hotmail.com To: stevag...@gmail.com; talk@openstreetmap.org Date: Sun, 14 Jul 2013 21:58:58 -0400 Subject: Re: [OSM-talk] Application error at openstreetmap.org Simple, something is wrong with the website. lol. I got nailed by it after I had typed up a long response to a PM. :( Seems everything else is working fine, just not the website. So, I'm thinking there were doing a change to the site, and it fubared it unfortunately. :( -James Date: Mon, 15 Jul 2013 11:15:37 +1000 From: stevag...@gmail.com To: talk@openstreetmap.org Subject: [OSM-talk] Application error at openstreetmap.org -- Application error The OpenStreetMap server encountered an unexpected condition that prevented it from fulfilling the request (HTTP 500) Feel free to contact the OpenStreetMap community if your problem persists. Make a note of the exact URL / post data of your request. This may be a problem in our Ruby On Rails code. 500 occurs with exceptions thrown outside of an action (like in Dispatcher setups or broken Ruby code) Surprised not to see anything about it on this mailing list. Can anyone explain? Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Future Interstate Relations
That looks legit enough to qualify IMO for the US:I:Future network. Looks like some of the I-74 signs that are posted out there in NC [0]. Still., those signs need to be posted along a segment to qualify for the network. If the signs are the Future Interstate Corridor type [1], then that segment would NOT qualify for the US:I:Future network as it means there is a slim possibility that alignment might be bypassed. That's happened with several Future I-74 Corridor alignments. -James [0] - http://goo.gl/maps/mMIHW [1] - http://www.texasfreeway.com/houston/photos/59sw/59sw.shtml (need to scroll down some) Date: Sat, 13 Jul 2013 19:23:52 -0400 From: kken...@nycap.rr.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations On 07/11/2013 01:57 PM, James Mast wrote: Is there picture proof of how they are signing it? Would http://www.upstatenyroads.com/submit/region-8/Reg8-2.JPG do? That's in Monroe, New York (and not my picture). If my word is no good, will my camera be any better? I plan to be down that way in another week or so, and I could probably grab another picture. I can certainly state that I've seen the sign pictured there. -- 73 de ke9tv/2, Kevin ___ 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: [Talk-us] Shield rendering and detours; tagging nicknames?
Nah, the best place to test route shield hell is in GA. :) hehe. http://elrond.aperiodic.net/shields/?zoom=14lat=30.85477lon=-82.01919layers=B Still, I think detour routes might be a good idea, but only if somebody is willing to keep track of the projects and fix everything once the construction is finished. -James Date: Sat, 13 Jul 2013 18:52:00 -0500 From: ba...@ursamundi.org To: talk-us@openstreetmap.org Subject: [Talk-us] Shield rendering and detours; tagging nicknames? OK, wonder if we can get orange detour banners for routes as well? Example relations can be found in the downtown Tulsa area, which has an interstate (244), two US routes (64, 75) and an Oklahoma state highway (51) detoured through the end of next year. Also, thanks to the serious overload on route multiplexing, exacerbated by the construction, this would be a good area to test route shield hell. I've also finally gotten around to adding relations for the LL Tisdale Parkway (http://www.alpsroads.net/roads/ok/cool_j/) and the Gilcrease Expressway (http://www.aaroads.com/shields/show.php?image=OK19720071) to test out city route shields. Also, what would be an appropriate tag for a completely informal name for something that is getting uptake by way of traffic reports? Tulsa's Inner Dispersal Loop has been called the Inner Detour Loop by some reporters. ___ 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: [Talk-us] US Historic Route shield rendering
Maybe we could add a ref:year tag? -James Date: Sat, 13 Jul 2013 19:07:53 -0500 From: ba...@ursamundi.org To: talk-us@openstreetmap.org Subject: [Talk-us] US Historic Route shield rendering I'm wondering if we can broaden the tagging for US Historic Route 66 and perhaps retag the existing relations for it's various routes, since the shields for this route are the same for other US Historic Routes (such as former alignments of US 30 in Oregon), save for 1 2-block segment of US 66 in my neighborhood (which rather than saying HISTORIC ROUTE says MINGO GREENWAY for reasons unknown). I propose rather than going with no ref and US:US for the network, we go with the ref on the sign, and US:US:Historic for the network. Not entirely sure how to handle bannered segments of this network, though: For example, in my neighborhood, two different routes are bannered as 1926-1932 and 1932-1974 (the *-1988 alignments are currently signposted as either I 40 Business or OK 66, with no historic signage, but could potentially fit the 1974-1988 banner in Tulsa for historical completeness if we're going to add relations for unsigned segments of historic highways). Thoughts? ___ 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: [Talk-us] Update on highway shield rendering
Hey Phil. Found another little bug. That or you forgot to add this in, not sure. In GA, it seems you're not supporting the US:GA:Connector network. I just had added the :Connector part to a relation for GA-40 Connector, and then all the GA-40 shields disappeared from the way and weren't replaced by the connector shields. http://elrond.aperiodic.net/shields/?zoom=16lat=30.83972lon=-81.99971layers=Bhttp://www.openstreetmap.org/browse/relation/2145405 Think you could get this fixed? -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [talk-au] Taking OSM to the Garmin
On 12/07/13 12:42, Brett Russell wrote: Hi All Trouble I been Windows based means even simple things like reading the type file is made hard until you wake up that Windows default Notepad is useless as it does not understand line feeds. You want to get yourself Notepad++ then, it will do everything that MS Notepad wont. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-us] Future Interstate Relations
Is there picture proof of how they are signing it? -James Date: Wed, 10 Jul 2013 21:43:47 -0400 From: kken...@nycap.rr.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations On Wed, Jul 10, 2013 at 7:40 AM, Phil! Gold phi...@pobox.com wrote: Given that previous list consensus was for tagging of the form: network=US:I:Future ref=number modifier=Future and that only one person offered a variant opinion this time around, I'd recommend tagging as above. Also, from your earlier emails, I have future interstates 26, 73, 74, and 840. Are there any others? 86 in New York, so signed for various segments of NY 17. https://www.dot.ny.gov/regional-offices/multi/i-86 ___ 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: [Talk-us] Update on highway shield rendering
I know that there is a US 1-9 in NJ, but this error is showing up in NC. ;) -James Date: Wed, 10 Jul 2013 10:07:17 -0500 From: toby.mur...@gmail.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] Update on highway shield rendering On Wed, Jul 10, 2013 at 9:44 AM, James Mast rickmastfa...@hotmail.com wrote: Well, I've found a bug in the rendering engine. What's up with these US 1-9 shields? http://elrond.aperiodic.net/shields/?zoom=16lat=35.52081lon=-79.18442layers=B This is a real thing. Welcome to the insane variety of how we do highways in this country :)http://www.alpsroads.net/roads/nj/us_1-9/n46.jpg Phil actually mentioned this in his sotm-us talk which everyone in this discussion might find interesting:http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013/video/68097487 Toby ___ 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: [Talk-us] Update on highway shield rendering
Well, it is ONLY posted in the field as US-21 Bypass, and it was that way last month. (I was down in Charlotte for the Coca-Cola 600, so I traveled on that segment of I-77.) I don't know who added that segment to the main US-21 relation, but might have been NE2, but can't be sure. Anyways, here's a quick link to StreetView showing this: http://goo.gl/maps/DiSfn. Just chock it up to one of those NCDOT quirks. I mean, they have a Bypass, Business, Alternate, and vanilla US-70 in the same area (Smithfield, NC)! -James Date: Wed, 10 Jul 2013 16:15:44 -0400 From: phi...@pobox.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Update on highway shield rendering * James Mast rickmastfa...@hotmail.com [2013-07-10 10:44 -0400]: http://www.openstreetmap.org/browse/way/172380289 There are some interesting things going on here. Is this road really part of both US 21 and US 21 Bypass? That seems weird to me, but if someone says that's how the road's signed I'll believe it (see: US 1-9 signage...). Also, the map really ought to show bypass shields for the roads that are part of US 21 Bypass.[0] My rendering is not doing so because US 21 Bypass has network=US:US (not network=US:US:Bypass), so it's treated as mainline US 21. [0] Like US 341 Bypass here: http://elrond.aperiodic.net/shields/?lat=32.4739lon=-83.7315zoom=14 ___ 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: [Talk-us] Update on highway shield rendering
Just so you know Phil, I've fixed up US-21 and it's children in the Elkin/Jonesville area a few minutes ago. I removed US-21's relation from the US-21 Bypass route and added a note=* tag explaining the gap. Hopefully that will prevent anybody else from re-adding it again. I also took the chance to add in the :Business and :Bypass to the two children of US-21 there (but kept the modifier tag). So, those will now render properly on your renderer. -James Date: Wed, 10 Jul 2013 16:15:44 -0400 From: phi...@pobox.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Update on highway shield rendering * James Mast rickmastfa...@hotmail.com [2013-07-10 10:44 -0400]: http://www.openstreetmap.org/browse/way/172380289 There are some interesting things going on here. Is this road really part of both US 21 and US 21 Bypass? That seems weird to me, but if someone says that's how the road's signed I'll believe it (see: US 1-9 signage...). Also, the map really ought to show bypass shields for the roads that are part of US 21 Bypass.[0] My rendering is not doing so because US 21 Bypass has network=US:US (not network=US:US:Bypass), so it's treated as mainline US 21. [0] Like US 341 Bypass here: http://elrond.aperiodic.net/shields/?lat=32.4739lon=-83.7315zoom=14 ___ 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: [Talk-us] Update on highway shield rendering
Done. Changed it to README=*. Thanks for that suggestion. -James Date: Thu, 11 Jul 2013 16:30:06 -0400 From: rwe...@averillpark.net To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Update on highway shield rendering On 7/11/13 4:20 PM, James Mast wrote: Just so you know Phil, I've fixed up US-21 and it's children in the Elkin/Jonesville area a few minutes ago. I removed US-21's relation from the US-21 Bypass route and added a note=* tag explaining the gap. Hopefully that will prevent anybody else from re-adding it again. if i seriously want people to read something, i find that README= works well because both JOSM and Potlatch sort it to the top, and the all caps make it really noticeable. note= is technically correct, but likely to be buried in the tags. richard ___ 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: [Talk-us] Update on highway shield rendering
I'm just curious, but how are you going to add shields for all of the Turnpikes out there that have their shield posted alongside another route shield (like the PA Turnpike, New York Thruway, Ohio Turnpike as examples)? Will there need to be some tweaks to the relations for those said routes so this can happen? If so, I'd be more than willing to do some tweaking at least with the PA Turnpike's relation (right now I'm splitting it up into WB and EB for the main route) and adding a super relation to also tie in all of the sections that the PA Turnpike controls (PA Turnpike 43, PA Turnpike 66, PA Turnpike 576, NE Extension I-476, + a segment of the extended I-376 that use to be PA Turnpike 60). Also, do you guys think for the PA Turnpike XXX routes, that the network tag for them should be US:PA:Turnpike (also for the mainline PA Turnpike relation and NE Extension)? I know I would need to spilt up PA-66 and PA-43 relations since both have segments that aren't part of the PA Turnpike network. (Yes, there is a free segment of PA-43 posted with normal PA shields, which is between Exit #8 and US-40/US-119. Have pictures of it, but too tired to dig them up and resize to upload right now, so here's a StreetView link instead: http://goo.gl/maps/GeZzo) I was planning on changing them to that network when I split them from the non-Turnpike segments. -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Future Interstate Relations
There is one other. I mentioned it in my e-mail from yesterday (07-09-13). That is I-295 in Fayetteville. http://gribblenation.net/ncfutints/fut295.html And to be honest, I thought some people wanted the :Future part dropped out and just put in the modifier area. -James Date: Wed, 10 Jul 2013 08:40:58 -0400 From: phi...@pobox.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations * James Mast rickmastfa...@hotmail.com [2013-07-09 01:40 -0400]: So, does anybody else have any more comments on how we should deal with tagging these Future Interstates? Given that previous list consensus was for tagging of the form: network=US:I:Future ref=number modifier=Future and that only one person offered a variant opinion this time around, I'd recommend tagging as above. Also, from your earlier emails, I have future interstates 26, 73, 74, and 840. Are there any others? ___ 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: [Talk-us] Update on highway shield rendering
I could fix the PA Turnpike relation with the US:PA:Turnpike network tag in a moment. Would that work instead of just fixing the name tags for both directions? I only split it up because it was getting close to 1,000 ways and thought it would be easier to edit in the future having two smaller relations, one for each direction. -James Date: Wed, 10 Jul 2013 09:14:40 -0400 From: phi...@pobox.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Update on highway shield rendering * James Mast rickmastfa...@hotmail.com [2013-07-10 03:18 -0400]: I'm just curious, but how are you going to add shields for all of the Turnpikes out there that have their shield posted alongside another route shield (like the PA Turnpike, New York Thruway, Ohio Turnpike as examples)? Yes. http://elrond.aperiodic.net/shields/?zoom=16lat=41.23953lon=-80.99077 I've got shields for the PA Turnpike, but a recent edit of yours broke the rendering. :) See below. For all that I've got most (hopefully all) of New York's parkways prepped, I seem to have missed the New York Thruway; I'll have to add that. Will there need to be some tweaks to the relations for those said routes so this can happen? The way I'm handling this at the moment (documented at http://elrond.aperiodic.net/shields/supported.html ) is that the relation needs: * an appropriate network tag, usually one matching the state's routes (US:PA, US:NJ, etc.); * the name tag set to the name of the route; and * *no* ref tag The recent edit to the PA Turnpike added (eastbound) and (westbound) to the name tag for the relations, which broke the rendering because it just expects name=Pennsylvania Turnpike. I'm not sure I want to change this aspect of the rendering, because Pennsylvania Turnpike is the name of the route and Pennsylvania Turnpike (eastbound) is merely the designation for a partiular relation. Also, I note that someone has added ref=NJTP to the New Jersey Turnpike, which breaks my rendering there. I do support ref=initials tags for some New York parkways, because that's basically how the signs look, but I'm not sure how reasonable it is for the New Jersey Turnpike. Anyone want to offer an opinion here? Also, do you guys think for the PA Turnpike XXX routes, that the network tag for them should be US:PA:Turnpike (also for the mainline PA Turnpike relation and NE Extension)? I've already got shields available for PA routes 43, 66, and 576 under the US:PA:Turnpike network. (Also, the Pennsylvania Turnpike will get a shield with either US:PA or US:PA:Turnpike, since I thought a reasonable argument could be made for either case.) ___ 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: [Talk-us] Update on highway shield rendering
Date: Wed, 10 Jul 2013 09:40:22 -0400 From: phi...@pobox.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Update on highway shield rendering * James Mast rickmastfa...@hotmail.com [2013-07-10 09:22 -0400]: I could fix the PA Turnpike relation with the US:PA:Turnpike network tag in a moment. Would that work instead of just fixing the name tags for both directions? That wouldn't affect my rendering as it currently stands. The rendering, right now, will only make a shields for a relation with the exact name Pennsylvania Turnpike. Is it possible that it could take the name from the Super relation for both directions? I didn't put the word (super) In it.http://www.openstreetmap.org/browse/relation/270032 Also, how will you deal with the PA Turnpike's NE Extension which also should have the shields on it? Before today, it didn't have a relation (just the base I-476 one) till I added it. However, I did split it up with a relation for each direction, and then a super tying it up together.http://www.openstreetmap.org/browse/relation/3075654 Or maybe you could somehow tweak your script to ignore anything in () in the name tag? That might be the best solution here, IMO. -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
Well, I've found a bug in the rendering engine. What's up with these US 1-9 shields? http://elrond.aperiodic.net/shields/?zoom=16lat=35.52081lon=-79.18442layers=B Is it because there are two different US 1 relations tagged on those ways? http://www.openstreetmap.org/browse/way/11177 No idea why there are two there, maybe somebody thought that they needed to keep all of US-1 together in NC, even though some segments are Bypass/Business with no vanilla US-1? Then again, I know US-21 has this happen in Jonesville with the Business route going into town and the main route being a Bypass along I-77 and this rendering bug isn't happening there. http://elrond.aperiodic.net/shields/?zoom=14lat=36.24215lon=-80.83527layers=B http://www.openstreetmap.org/browse/way/172380289 -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Future Interstate Relations
So, does anybody else have any more comments on how we should deal with tagging these Future Interstates? I just remembered there was one other Interstate in NC posted this way, I-295 [1] in Fayetteville, NC. So, I've fixed that relation as well to follow the network way I originally suggested till we all, once and for all, have decided on the way to tag these. -James [1] - http://gribblenation.net/ncfutints/fut295.html From: rickmastfa...@hotmail.com To: talk-us@openstreetmap.org Date: Tue, 25 Jun 2013 00:15:36 -0400 Subject: [Talk-us] Future Interstate Relations Later tonight, I'm planning on splitting up the relations for the following Interstates (I-26, I-73, I-74) in North Carolina to separate the segments of said Interstates into normal and the parts that are posted as Future. (will also update the ref tags on the ways since they are still being used too) Now, the Future ones will only be for segments that have signage clearly stating they are Future Interstates. I'm not going to be doing anything like this for ones signed as Future Interstate Corridors. The signage has to be like the following to qualify (blame different NCDOT divisions for the different styles): I-26: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-26/Img_2043s.jpg I-73: http://goo.gl/maps/G0qOG I-74: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-74/P1030940s.jpg I-840: http://goo.gl/maps/K20Hs Now, I'm going to initially use the following to tag the Future segments inside of relations:network=US:I:Future However, somebody else suggested this: network=US:I modifier=Future Which do you guys think would be the better way to go? I can always change the relation tags later once we all agree on a proper tagging scheme for these types of Interstates that aren't true Interstates just yet. -James (rickmastfan67) ___ 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: [Talk-us] Future Interstate Relations
Wouldn't the Business routes of Interstates count as 'children'? From: m...@rtijn.org Date: Tue, 25 Jun 2013 10:07:52 -0600 To: ba...@ursamundi.org CC: rickmastfa...@hotmail.com; talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations But that would not apply to the Interstate network, which otherwise has no 'children', right? If the modifier paradigm also applies to State Routes, then there would be the possibility of confusion between US:UT:Future as a future state route and US:UT:Future as a county highway in 'Future County'. I guess it is imaginable. Not likely, but imaginable. On Tue, Jun 25, 2013 at 8:50 AM, Paul Johnson ba...@ursamundi.org wrote: I prefer the modifier proposal, since it prevents Future from being confused with a county level network. On Jun 24, 2013 11:16 PM, James Mast rickmastfa...@hotmail.com wrote: Later tonight, I'm planning on splitting up the relations for the following Interstates (I-26, I-73, I-74) in North Carolina to separate the segments of said Interstates into normal and the parts that are posted as Future. (will also update the ref tags on the ways since they are still being used too) Now, the Future ones will only be for segments that have signage clearly stating they are Future Interstates. I'm not going to be doing anything like this for ones signed as Future Interstate Corridors. The signage has to be like the following to qualify (blame different NCDOT divisions for the different styles): I-26: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-26/Img_2043s.jpg I-73: http://goo.gl/maps/G0qOG I-74: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-74/P1030940s.jpg I-840: http://goo.gl/maps/K20Hs Now, I'm going to initially use the following to tag the Future segments inside of relations: network=US:I:Future However, somebody else suggested this: network=US:I modifier=Future Which do you guys think would be the better way to go? I can always change the relation tags later once we all agree on a proper tagging scheme for these types of Interstates that aren't true Interstates just yet. -James (rickmastfan67) ___ 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 -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.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: [Talk-us] Future Interstate Relations
I thought the modifier would be the type of Business route? Remember, we do have Business Spurs and Business Loops for Interstate highways. Sometimes both types in the same city. -James Date: Wed, 26 Jun 2013 20:06:58 -0500 From: ba...@ursamundi.org To: rickmastfa...@hotmail.com CC: m...@rtijn.org; talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations That'd be modifier=Business, no? US:US has no lower level, unlike say, US:TX, which has US:TX:FM* or US:OK, which would also contain US:OK:Turnpike (Oklahoma's secondary toll highway system) or a county, like US:CA:San_Bernardino, or a city, like US:OK:Tulsa:Tulsa... On Wed, Jun 26, 2013 at 5:49 PM, James Mast rickmastfa...@hotmail.com wrote: Wouldn't the Business routes of Interstates count as 'children'? From: m...@rtijn.org Date: Tue, 25 Jun 2013 10:07:52 -0600 To: ba...@ursamundi.org CC: rickmastfa...@hotmail.com; talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations But that would not apply to the Interstate network, which otherwise has no 'children', right? If the modifier paradigm also applies to State Routes, then there would be the possibility of confusion between US:UT:Future as a future state route and US:UT:Future as a county highway in 'Future County'. I guess it is imaginable. Not likely, but imaginable. On Tue, Jun 25, 2013 at 8:50 AM, Paul Johnson ba...@ursamundi.org wrote: I prefer the modifier proposal, since it prevents Future from being confused with a county level network. On Jun 24, 2013 11:16 PM, James Mast rickmastfa...@hotmail.com wrote: Later tonight, I'm planning on splitting up the relations for the following Interstates (I-26, I-73, I-74) in North Carolina to separate the segments of said Interstates into normal and the parts that are posted as Future. (will also update the ref tags on the ways since they are still being used too) Now, the Future ones will only be for segments that have signage clearly stating they are Future Interstates. I'm not going to be doing anything like this for ones signed as Future Interstate Corridors. The signage has to be like the following to qualify (blame different NCDOT divisions for the different styles): I-26: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-26/Img_2043s.jpg I-73: http://goo.gl/maps/G0qOG I-74: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-74/P1030940s.jpg I-840: http://goo.gl/maps/K20Hs Now, I'm going to initially use the following to tag the Future segments inside of relations: network=US:I:Future However, somebody else suggested this: network=US:I modifier=Future Which do you guys think would be the better way to go? I can always change the relation tags later once we all agree on a proper tagging scheme for these types of Interstates that aren't true Interstates just yet. -James (rickmastfan67) ___ 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 -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Future Interstate Relations
There are two Interstate Business Routes in Winslow, AZ for I-40 that intersect each other. I-40 Business Spur http://www.openstreetmap.org/browse/relation/1933534 I-40 Business Loop http://www.openstreetmap.org/browse/relation/1933535 -James Date: Wed, 26 Jun 2013 21:41:06 -0500 From: ba...@ursamundi.org To: rickmastfa...@hotmail.com CC: m...@rtijn.org; talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations Modifier would be able to handle both situations, but is there a situation where a business loop or spur with the same number meet that would necessitate getting to that level of specificity? On Wed, Jun 26, 2013 at 9:34 PM, James Mast rickmastfa...@hotmail.com wrote: I thought the modifier would be the type of Business route? Remember, we do have Business Spurs and Business Loops for Interstate highways. Sometimes both types in the same city. -James Date: Wed, 26 Jun 2013 20:06:58 -0500 From: ba...@ursamundi.org To: rickmastfa...@hotmail.com CC: m...@rtijn.org; talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations That'd be modifier=Business, no? US:US has no lower level, unlike say, US:TX, which has US:TX:FM* or US:OK, which would also contain US:OK:Turnpike (Oklahoma's secondary toll highway system) or a county, like US:CA:San_Bernardino, or a city, like US:OK:Tulsa:Tulsa... On Wed, Jun 26, 2013 at 5:49 PM, James Mast rickmastfa...@hotmail.com wrote: Wouldn't the Business routes of Interstates count as 'children'? From: m...@rtijn.org Date: Tue, 25 Jun 2013 10:07:52 -0600 To: ba...@ursamundi.org CC: rickmastfa...@hotmail.com; talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations But that would not apply to the Interstate network, which otherwise has no 'children', right? If the modifier paradigm also applies to State Routes, then there would be the possibility of confusion between US:UT:Future as a future state route and US:UT:Future as a county highway in 'Future County'. I guess it is imaginable. Not likely, but imaginable. On Tue, Jun 25, 2013 at 8:50 AM, Paul Johnson ba...@ursamundi.org wrote: I prefer the modifier proposal, since it prevents Future from being confused with a county level network. On Jun 24, 2013 11:16 PM, James Mast rickmastfa...@hotmail.com wrote: Later tonight, I'm planning on splitting up the relations for the following Interstates (I-26, I-73, I-74) in North Carolina to separate the segments of said Interstates into normal and the parts that are posted as Future. (will also update the ref tags on the ways since they are still being used too) Now, the Future ones will only be for segments that have signage clearly stating they are Future Interstates. I'm not going to be doing anything like this for ones signed as Future Interstate Corridors. The signage has to be like the following to qualify (blame different NCDOT divisions for the different styles): I-26: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-26/Img_2043s.jpg I-73: http://goo.gl/maps/G0qOG I-74: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-74/P1030940s.jpg I-840: http://goo.gl/maps/K20Hs Now, I'm going to initially use the following to tag the Future segments inside of relations: network=US:I:Future However, somebody else suggested this: network=US:I modifier=Future Which do you guys think would be the better way to go? I can always change the relation tags later once we all agree on a proper tagging scheme for these types of Interstates that aren't true Interstates just yet. -James (rickmastfan67) ___ 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 -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.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 ___ 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: [Talk-us] Cam4rd98 just doesn't get it
I'll let his comments here[1] on a note page speak. - James [1] - http://www.openstreetmap.org/browse/note/3173 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Route relation pages
Not bad! Does this mean that any new relations would automatically be added to the page (like one for the new I-2 in TX when it's posted this year)? Also, thanks to that new Interstate page, I noticed right away that the I-495 (DE) relation's ref tags weren't correct (it had ref=I 495 (DE)). So, I was able to quickly fix it to put it back to the current tagging scheme. This might give me a reason to go cleaning up some Future Interstate relations where the highway is really posted with Future I-XX shields in NC (segments of I-26, I-73, I-74, and all of I-840). Can't wait to have a render properly put the word Future above the shields! -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] ref tags
Date: Sat, 22 Jun 2013 15:28:12 -0400 From: phi...@pobox.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] ref tags * James Mast rickmastfa...@hotmail.com [2013-06-22 07:22 -0400]: the segment of I-26 between I-240 and Exit #9 is still considered to be a Future Interstate and it is posted as such with FUTURE tabs above all I-26 shields on that segment (and missing the word Interstate in the shields itself. Would it be worthwhile to declare a separate network for these (US:I:Future seems natural) and give them their own relations? If there are signs on the ground, I could see about putting images in my rendering for them. Yep, here's picture proof that I personally took a few years ago of a Future I-26 shield: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-26/Img_2043s.jpg And here's one for I-74 in NC along the Rockingham US-74 Bypass when I was on it a few years ago: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-74/P1030940s.jpg And for quick reference, here's a I-840 from StreetView: http://goo.gl/maps/K20Hs And a Future I-73/I-840 combo from StreetView: http://goo.gl/maps/G0qOG It seems that only NC seems to do it this way. Don't know of any other states that post Future Interstates except for those Future I-xx Corridor signs (NC does that too on highways that aren't going to be part of a future Interstate). -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] ref tags
Date: Thu, 20 Jun 2013 15:15:02 -0400 From: phi...@pobox.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] ref tags * Clay Smalley claysmal...@gmail.com [2013-06-20 09:26 -0700]: Also, even if it were the case that they were the same network, it makes sense to keep them separate because that is how the shield renderer determines which shield to put on the road. My shield renderer is pretty flexible. I can assign shields on a ref-by-ref basis, if need be (though it means that networks' shields require more maintenance in the long run).[0] As long as the solution has local consensus I'll find a way to work with it.[1] [0] See, for example, Georgia route 515, which gets a blue sign because it's part of an Appalachian Highway Development System corridor: http://elrond.aperiodic.net/shields/?zoom=12lat=34.66561lon=-84.48668layers=B [1] Or throw up my hands and say, I don't know how to handle that, but that shouldn't impede consensus. There are still a bunch of things I don't have a good way to handle yet, like the way Tennessee does primary and secondary state highways, or the way Maryland signs Business US Highways. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Well, for the Tennessee State Highways, as long as we can find out which are secondary, we could tag them in the relations as US:TN:SR or US:TN:Secondary and then use a Super relation to tie together routes that have segments with both primary and secondary segments types. The kicker is how to find out which segments are which. I don't know if TDOT has any GIS data out there to download that would be compatible with OSM that would allow us to figure out which is which. -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Turn restriction dispute, NE2
Date: Wed, 12 Jun 2013 08:34:18 -0400 From: nice...@att.net To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Turn restriction dispute, NE2 On 6/12/2013 7:53 AM, Josh Doe wrote: I'm disappointed that the above recommendation didn't acknowledge that NE2 has done good work. I would say that on the whole his contributions in terms of data are definitely a net positive, including a great deal of geometry improvement, addition of new roads, etc. +1 - He got many of the major Interstate, US and state highway relations and routing connectivity in order. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us I'll 2nd what both Mike and Josh have to say. -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Neighborhoods / Zillow
Interesting discussion, I've been working at thinking how to approach doing this in my hometown of Tempe, AZ http://www.tempe.gov/index.aspx?page=792 They classify neighborhoods two ways, homeowners associations (the classic HOA) and neighborhood associations. The former is usually set up by the developer and the latter is more organic, either historically significant or like minded individuals band together to improve the community. Now I think I could import these boundaries without worry because they are city defined but I've been struggling with how it would impact the database. After reading this discussion I'm going to move forward and import them. -- James Fee 480-225-2287 @cageyjames On Wed, Jun 12, 2013 at 9:49 AM, Clifford Snow cliff...@snowandsnow.uswrote: On Tue, Jun 11, 2013 at 9:21 PM, Serge Wroclawski emac...@gmail.comwrote: Your reply really doesn't address what William is saying, which is that neighbourhood boundaries are subjective. I think we all agree that neighbourhoods are useful, but they're worse than political boundaries in terms of being unsurveyable. I agree that most neighborhood boundaries are subjective. Of the cities I've lived in, some neighborhoods are clearly define, usually by natural or man made artifacts, others are definitely fluid. When importing addresses into Seattle we considered adding a neighborhood tag to each address or building node but decided against it. Administrative boundaries seemed like a better plan. After this discussion I'm not longer so certain. So what are the pro and cons for importing boundaries? Cons: Neighborhood boundaries are fluid Most neighborhood boundaries can not be surveyed 3rd party data users and overlay their own boundary polygons Pros: Helpful when doing queries Search results show neighborhood boundaries Irregularly shaped neighborhoods better depicted by a polygon than a node Personally I don't have any objection if someone wanted to import neighborhood boundaries for their city. -- Clifford OpenStreetMap: Maps with a human touch ___ 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
[OSM-talk] Re-opening a note if necessary?
I'm curious, but does anybody think that notes should be able to be re-opened if necessary? Like if somebody falsely closes it when it shouldn't have been? That or at least allow people to post follow up comments in case somebody needs to add more info to if the person who closed/fixed it didn't correctly fix the map. -James ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] User Cam4rd98 gun-jumping new highways + adding fictional alignments
Well, it seems Changeset: 16397959 is legit (minus the missing changeset comment) since I-269 IS under-construction in that area, well, at least on the MS side for sure. http://www.desototimes.com/articles/2013/03/23/news/doc514cf7ea1d8d0663837988.txt -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [talk-au] Newcastle Inner Bypass - Motorway or not ?
On 01/06/13 14:32, Ian Sergeant wrote: On 1 June 2013 09:29, Michael James m.ja...@internode.on.net wrote: There is a legal difference between a divided highway and a freeway in Australia, so if it is not actually called a freeway/motorway via signage then it really isn't one. Firstly, I'm a little sceptical of there actually being a legal difference. Can you point to a source that would make this clear? The Australian road rules (on which each states rules are based) :- RR 97 Road access signs RR 177 Stopping on a freeway There are also rules that reference these rules such as the exceptions for a garbage truck stopping does not include an exception to RR 177 Any sign that has the following is considered a freeway :- freeway motorway tollway expressway ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Newcastle Inner Bypass - Motorway or not ?
On 29/05/13 22:51, Ian Sergeant wrote: I'd like to indicate freeway class sections as motorways, however, I can see the argument to just objectively use the RMS classifications. Will save edit wars down the track to just have one easy rule. There is a legal difference between a divided highway and a freeway in Australia, so if it is not actually called a freeway/motorway via signage then it really isn't one. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-us] User Cam4rd98 gun-jumping new highways + adding fictional alignments
This user has been brought to my attention with him gun-jumping highways marking them as open when they aren't yet (I-74/US-311 [1] - I've already fixed this one), or adding completely fictional alignments for highways that aren't even under-construction yet or proposed (I-66 in IN [2], and an alignment of NC-540 [3]). I'm pretty sure these aren't the only ones he's done, so this could be just the tip of the iceberg. Has anybody had any prior contact with this user? Just wish that all the editing programs forced a comment before upload. Really hate the no comment changesets. -James [1] - http://www.openstreetmap.org/browse/note/2725 [2] - http://www.openstreetmap.org/browse/note/3136 [3] - http://www.openstreetmap.org/browse/note/3160 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [talk-au] Newcastle Inner Bypass - Motorway or not ?
On 29/05/13 10:40, Ben Johnson wrote: Any thoughts on whether the completed sections of the Newcastle Inner City Bypass (now being referred to by the RMS as A37 - Newcastle Outer Ring Road) should be classified as type Motorway …? If they're calling it A37 then they're not calling it a motorway. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [OSM-talk] [Talk-us] Google Maps being praised for removing I-5 colasped bridge quickly
Well, when I did my original edit in that area because of the collapse, somebody had already deleted the small section that collapsed. So, I just added the missing access=no tags on the other ways. Plus, it didn't hurt that I was on my PC already and watching the local 11PM (EDT) news and they mentioned that there was a bridge collapse on an Interstate. -James (rickmastfan67) From: cliff...@snowandsnow.us Date: Mon, 27 May 2013 16:36:44 -0700 CC: talk@openstreetmap.org; talk...@openstreetmap.org Subject: Re: [Talk-us] Google Maps being praised for removing I-5 colasped bridge quickly Let's forget about Google Maps for a moment that give thanks to the contributors who updated I-5 on OpenStreetMap. Alan, rickmastfan67, Sundance and katpatuka have all contributed to the update. It is dedicated mappers like these that make OSM great. -- Clifford OpenStreetMap: Maps with a human touch ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Google Maps being praised for removing I-5 colasped bridge quickly
Well, when I did my original edit in that area because of the collapse, somebody had already deleted the small section that collapsed. So, I just added the missing access=no tags on the other ways. Plus, it didn't hurt that I was on my PC already and watching the local 11PM (EDT) news and they mentioned that there was a bridge collapse on an Interstate. -James (rickmastfan67) From: cliff...@snowandsnow.us Date: Mon, 27 May 2013 16:36:44 -0700 CC: t...@openstreetmap.org; talk-us@openstreetmap.org Subject: Re: [Talk-us] Google Maps being praised for removing I-5 colasped bridge quickly Let's forget about Google Maps for a moment that give thanks to the contributors who updated I-5 on OpenStreetMap. Alan, rickmastfan67, Sundance and katpatuka have all contributed to the update. It is dedicated mappers like these that make OSM great. -- Clifford OpenStreetMap: Maps with a human touch ___ 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
[OSM-talk] Google Maps being praised for removing I-5 colasped bridge quickly
http://www.nbcnews.com/technology/collapsed-i-5-bridge-gone-google-maps-almost-quickly-it-6C10067906 If I remember correctly, we had it marked as access=no and the segment removed about an hour faster than on Google. Somebody needs to get ahold of Rosa from NBC (who did the article) and let them know about OSM pawning Google here. -James ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-us] Google Maps being praised for removing I-5 colasped bridge quickly
http://www.nbcnews.com/technology/collapsed-i-5-bridge-gone-google-maps-almost-quickly-it-6C10067906 If I remember correctly, we had it marked as access=no and the segment removed about an hour faster than on Google. Somebody needs to get ahold of Rosa from NBC (who did the article) and let them know about OSM pawning Google here. -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] User randomly upgrading highways in the Carolina's
Just happened to come across the other night a user (mjbyars) who has been upgrading the highways type when it shouldn't be. For instance, he's upgrading several state highways from secondary to primary when they have no business being upgraded that high, especially with a near by parallel US highway that is the primary highway there. I've already contacted him, but haven't gotten a response back yet. He's also been upgrading small segments of 4 lane US highways that are primary up to trunk when they have no business being that highway. In fact, I had to repair US-301 last night in an area where it seems he just copy and pasted tags from one way to another and made a section 4 lanes when it's only a 2 lane highway. Here are some examples: http://www.openstreetmap.org/browse/way/16510484/history http://www.openstreetmap.org/browse/way/85693479/history http://www.openstreetmap.org/browse/way/132057986/history http://www.openstreetmap.org/browse/way/12104456/history http://www.openstreetmap.org/browse/way/12530763/history http://www.openstreetmap.org/browse/way/119881971/history Anybody willing to help out and fix some damage if he doesn't respond to messages (couldn't hurt to have a second person contact him as well, maybe Mike N since he lives in SC). -James (rickmastfan67) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Bike route network levels: East Coast Greenway
A discussion has arisen regarding the proper tagging of this bicycle route. I thought it would be interesting to get some input from the community. The East Coast Greenway is a bike route that has been developed by the private nonprofit East Coast Greenway Alliance. The Greenway is a developing network that runs the entire east coast of the US. The question is what network level should it, if at all, be tagged. Currently, there are three network levels, local/regional/national that have been used. In other countries, these apply to different levels of government that officially sanction the cycle route. In the US there are several bicycle routes that are sanctioned by AASHTO. In contrast, an analagous tag for hiking networks applies these levels simply according to the spatial extent of the hiking trail and optionally adds a operator tag for the organization that plans and maintains the trail. Any preference in the community for how one should tag privately sanctioned bicycle routes of large extent? James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-ca] Routing tool for openstreetmap.ca?
On Mon, Apr 22, 2013 at 3:33 PM, Samuel Longiaru longi...@shaw.ca wrote: It seems to me that the OSRM routing could benefit greatly by a 0.6 penalty for unpaved roads as had been suggested a few time before, but they don't seem to want to go that way. Why incur a penalty just because the roadway is unpaved? A better solution would be to have the ability to request paved roads only when routing. That way the user could decide whether an unpaved roadway should be selected or not. I suppose the best solution would be to allow the user to select whether unpaved roads can be used for routing, and also allow the user to select the penalty to apply for unpaved. I fight with my GPS all the time. I tell it to never use unpaved roads, but it will put me onto them quite often. Then on the other hand it can try and send me on long detours some times when I know I want to take that 2 mile shortcut on gravel to save 40 miles on pavement. It's pretty tough to teach a computer to be as wishy-washy as a human! -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Routing tool for openstreetmap.ca?
On Mon, Apr 22, 2013 at 7:57 PM, Samuel Longiaru longi...@shaw.ca wrote: If your GPS had that, then maybe you wouldn't be fighting with it so much. :) Or if the database contained road surface information, proper speed limit data, and other valuable information, then the routing engine would have a chance at knowing where to send you. It's a challenge to determine whether the routing engine or the database is to blame for the routing choices. With OSM, we have access to the database, and only ourselves to blame if the information required is not in the database! :) -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-us] Tiger 2012 Data imagery layer
Is anybody else having any problems right now accessing it in JOSM? I keep getting Error messages instead of the tiles. -James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
