Re: [Talk-us] Tagging "next exit" services
Tag the first node of the offramp as highway=motorway_junction. As far as the sign itself goes, there's a proposed relationship for signs in the UK and EU at http://wiki.openstreetmap.org/wiki/Relation:destination_sign that may be of some help. Chris On Thu, Nov 12, 2009 at 12:26 AM, Alan Mintz > wrote: > Along freeways, particular interstates with long distances between exits, > there are usually signs that indicate what types of services (food, fuel, > lodging, etc.) are available at the next exit. How should one tag these, > assuming that one cannot determine the exact position of those services off > the freeway? > > A good example is electric vehicle recharging or fuel stations that supply > CNG or other unusual fuels - it is not possible to see, only from satellite > imagery, which specific building was being referred to by the sign on the > freeway. > > -- > Alan Mintz > > > ___ > 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] Possible destructive bug in JOSM build 2417 - need someone to duplicate
Chris Hunter wrote: > Yeah, that's exactly what was happening to me. The best part is when > you try to delete the "empty" way, the real way gets deleted instead. > In my case the empty ways were at the beginning of the OSM file, so I just edited it, removed the empty ways and I was able to upload the file. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
Thanks. Can someone bounce this thread over to the Talk and JOSM-Dev lists, so we can get 2417 replaced ASAP. Probably want to get the MOTD updated and get edits from 2417 blacklisted on the server, too. On Thu, Nov 12, 2009 at 12:07 AM, Nakor wrote: > Dave Hansen wrote: > >> On Wed, 2009-11-11 at 21:01 -0500, Chris Hunter wrote: >> >> >>> My apologies if this has already been reported to the dev mailing >>> list, but I've been running up against a critical/showstopper bug in >>> JOSM 2417 for the past few days. >>> >>> >> >> I just tried with 2439 and can't seem to reproduce this. >> -- Dave >> >> >> >> > > The issue I was having is gone with 2439svn. > > Thanks, > > N. > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
Yeah, that's exactly what was happening to me. The best part is when you try to delete the "empty" way, the real way gets deleted instead. On Wed, Nov 11, 2009 at 11:34 PM, Nakor wrote: > > > > My apologies if this has already been reported to the dev mailing list, >> but I've been running up against a critical/showstopper bug in JOSM 2417 for >> the past few days. >> >> Can someone please try and duplicate this "precondition failed" bug: >> >> http://josm.openstreetmap.de/ticket/3884 >> >> Here is the chain of events that seems to cause the most frequent >> problems: >> >> 1. Download and edit a small area (1 square mile or so). >> 2. Move along a way that was just edited, and download another small area. >> 3. Upload changes, but leave the changeset open. - Error may occur at this >> point. >> 4. Download and edit some more small areas along the same way. >> 5. Attempt to upload the new changes using the open changeset - Error >> *WILL* occur at this point. >> >> Depending on if the validator plugin is installed or not, you may also get >> a slew of warning messages about duplicate nodes. >> >> >> > I confirm the issue with 2417. I have it when downloading small areas along > my GPS tracks. A lot of ways come in "empty" (with 0 nodes) which causes > problems later for the validator and when trying to upload my work. > > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Tagging "next exit" services
Along freeways, particular interstates with long distances between exits, there are usually signs that indicate what types of services (food, fuel, lodging, etc.) are available at the next exit. How should one tag these, assuming that one cannot determine the exact position of those services off the freeway? A good example is electric vehicle recharging or fuel stations that supply CNG or other unusual fuels - it is not possible to see, only from satellite imagery, which specific building was being referred to by the sign on the freeway. -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
Dave Hansen wrote: > On Wed, 2009-11-11 at 21:01 -0500, Chris Hunter wrote: > >> My apologies if this has already been reported to the dev mailing >> list, but I've been running up against a critical/showstopper bug in >> JOSM 2417 for the past few days. >> > > I just tried with 2439 and can't seem to reproduce this. > > -- Dave > > > The issue I was having is gone with 2439svn. Thanks, N. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
> My apologies if this has already been reported to the dev mailing > list, but I've been running up against a critical/showstopper bug in > JOSM 2417 for the past few days. > > Can someone please try and duplicate this "precondition failed" bug: > > http://josm.openstreetmap.de/ticket/3884 > > Here is the chain of events that seems to cause the most frequent > problems: > > 1. Download and edit a small area (1 square mile or so). > 2. Move along a way that was just edited, and download another small area. > 3. Upload changes, but leave the changeset open. - Error may occur at > this point. > 4. Download and edit some more small areas along the same way. > 5. Attempt to upload the new changes using the open changeset - Error > *WILL* occur at this point. > > Depending on if the validator plugin is installed or not, you may also > get a slew of warning messages about duplicate nodes. > > I confirm the issue with 2417. I have it when downloading small areas along my GPS tracks. A lot of ways come in "empty" (with 0 nodes) which causes problems later for the validator and when trying to upload my work. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Addressing Question
Ian Dees wrote: > * Ok, not "impossible", but the import size would triple and the CPU > time to compute the new addressing-only ways might make it hard for > the "regular mapper" to do. But for no added code and editor complexity. IMHO the only decent alternative is using a relation for each address interpolation-range, with the nodes at the ends of the range and the way itself as members. This is roughly half as expensive as the Karlsruhe interpolation ways, and reduces the visual clutter in the editors. It is also insensitive to way direction reversal. One of the worst problems is when you split a way which has more than one such relation (or even one, if the split is NOT between the two nodes). Consider a way A from node 1 to 2 to 3; interpolation relation R has members 1[from], 2[to], A[via] and the range info. Relation S has members 2[from], 3[to], A[via]. A is split into A and B at node 2. If B gets all tags and relations from A, things get ugly - R and S now have 2 "via" members. So the editor needs to know how to remove the extra relations so that only ways that contain both the nodes stay members. Note: This problem already exists in reverse for turn restrictions. Both the "from" and "to" ways are required to end at the "via" node. So, say, Market St crosses 1st St. Market and 1st are both split at the intersection so a no_left_turn can be inserted. If some well-meaning editor goes and rejoins the two halves of Market, the relation is at least formally wrong. /Stellan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Addressing Question
On Wed, Nov 11, 2009 at 10:17 PM, Apollinaris Schoell wrote: > On Wed, Nov 11, 2009 at 7:19 PM, Anthony wrote: > >> >> On the other hand, putting the information directly on the way would >> be problematic for many reasons. Ranges might span multiple ways, and >> right/left has to be reversed whenever the way is reversed being the >> most troublesome. >> >> this is enough reason to stay away from such a scheme. if it's too > difficult no one will use it or they will break the data. > > This scheme works for all of the places that I'm sourcing data from... they have line segments that are tagged with the left/right-begin/end addresses. Each road is broken up into line segments that have different address values. When this is converted to OSM ways, each way has its address data intact from the source information. That being said, I do see your point about reversing the order of the way... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Addressing Question
On Wed, Nov 11, 2009 at 7:19 PM, Anthony wrote: > > On the other hand, putting the information directly on the way would > be problematic for many reasons. Ranges might span multiple ways, and > right/left has to be reversed whenever the way is reversed being the > most troublesome. > > this is enough reason to stay away from such a scheme. if it's too difficult no one will use it or they will break the data. > It probably has to be a relation. Include a start node, an end node, > and a list of one or more ways (which are connected to form one > logical way). > > the ways have to be split at the start/end node. the relation members have to be ordered. too many beginners and medium experienced mappers have problems to understand such a scheme. how is that easier than the Karlsruhe scheme? > ___ > 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] [OSM-talk] Addressing Question
Ian Dees wrote: > * Ok, not "impossible", but the import size would triple and the CPU > time to compute the new addressing-only ways might make it hard for > the "regular mapper" to do. But for no added code and editor complexity. IMHO the only decent alternative is using a relation for each address interpolation-range, with the nodes at the ends of the range and the way itself as members. This is roughly half as expensive as the Karlsruhe interpolation ways, and reduces the visual clutter in the editors. It is also insensitive to way direction reversal. One of the worst problems is when you split a way which has more than one such relation (or even one, if the split is NOT between the two nodes). Consider a way A from node 1 to 2 to 3; interpolation relation R has members 1[from], 2[to], A[via] and the range info. Relation S has members 2[from], 3[to], A[via]. A is split into A and B at node 2. If B gets all tags and relations from A, things get ugly - R and S now have 2 "via" members. So the editor needs to know how to remove the extra relations so that only ways that contain both the nodes stay members. Note: This problem already exists in reverse for turn restrictions. Both the "from" and "to" ways are required to end at the "via" node. So, say, Market St crosses 1st St. Market and 1st are both split at the intersection so a no_left_turn can be inserted. If some well-meaning editor goes and rejoins the two halves of Market, the relation is at least formally wrong. /Stellan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
On Wed, 2009-11-11 at 23:01 -0500, Chris Hunter wrote: > Thanks. Is 2439 available on the server yet, or is it still in alpha? > I re-downloaded the latest beta a couple hours ago and the > josm-latest.jar link was still pointing at 2417. I checked it out of SVN and built it myself. I can send along a copy if you wan to give it a shot. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
Thanks. Is 2439 available on the server yet, or is it still in alpha? I re-downloaded the latest beta a couple hours ago and the josm-latest.jar link was still pointing at 2417. On Wed, Nov 11, 2009 at 10:30 PM, Dave Hansen wrote: > On Wed, 2009-11-11 at 21:01 -0500, Chris Hunter wrote: > > My apologies if this has already been reported to the dev mailing > > list, but I've been running up against a critical/showstopper bug in > > JOSM 2417 for the past few days. > > I just tried with 2439 and can't seem to reproduce this. > > -- Dave > > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Addressing Question
On Wed, Nov 11, 2009 at 9:47 PM, andrzej zaborowski wrote: > > That's a pretty pessimistic view. > > Sorry, I am pretty grumpy today. The area I'm looking at actually has quite a few mappers already, so I imagine this data would probably get updated quickly. > > For the record an import I've done had only this left/right - to/from > housenumber information, too, so I have an ugly python script here > ready to throw at this kind of data (after adapting to whatever the > input format is) and I would be happy to do the processing on my PC if > you decide to go this way. The whole toolchain should still behave > reasonably for data size of TIGER (though obviously I didn't have that > much data) > > What does the math look like to handle intersections? Curvy roads? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
On Wed, 2009-11-11 at 21:01 -0500, Chris Hunter wrote: > My apologies if this has already been reported to the dev mailing > list, but I've been running up against a critical/showstopper bug in > JOSM 2417 for the past few days. I just tried with 2439 and can't seem to reproduce this. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Addressing Question
On Wed, Nov 11, 2009 at 9:21 PM, Ian Dees wrote: > No, I doubt local mappers will improve the data. If that's true (and I'm really not sure if it is), then it really shouldn't be in OSM in the first place. > I sent this mail because > almost all of the data I've seen available for import in the US (all the way > from individual municipalities to TIGER's shapefiles) has this > left/right-from/to scheme for addressing information. > > If the expectation is that we will always be following the Karlsruhe schema > (with separate ways on each side of the road centerline), then importing > this addressing data will be next to impossible*. On the other hand, putting the information directly on the way would be problematic for many reasons. Ranges might span multiple ways, and right/left has to be reversed whenever the way is reversed being the most troublesome. It probably has to be a relation. Include a start node, an end node, and a list of one or more ways (which are connected to form one logical way). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Addressing Question
On Wed, Nov 11, 2009 at 7:55 PM, andrzej zaborowski wrote: > Hiya, > > 2009/11/12 Ian Dees : > > I'm looking at some donated street centerline data that has addressing > data > > in the form of "Right/Left From Addr" and "Right/Left To Addr" on each > > street centerline. Is there an accepted way of applying these tags to the > > road ways? It doesn't really make very much sense to create and store a > > separate way just for the addressing information. > > The hope is that local mappers there will be slowly improving imported > data until there are separate points for every address I think? Then > I'd recommend just adding those separate ways and making it easier for > the mappers to build on this data, instead of making it harder for > nearly everyone dealing with OSM data by adding a whole different > addressing scheme. > No, I doubt local mappers will improve the data. I sent this mail because almost all of the data I've seen available for import in the US (all the way from individual municipalities to TIGER's shapefiles) has this left/right-from/to scheme for addressing information. If the expectation is that we will always be following the Karlsruhe schema (with separate ways on each side of the road centerline), then importing this addressing data will be next to impossible*. -Ian * Ok, not "impossible", but the import size would triple and the CPU time to compute the new addressing-only ways might make it hard for the "regular mapper" to do. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
My apologies if this has already been reported to the dev mailing list, but I've been running up against a critical/showstopper bug in JOSM 2417 for the past few days. Can someone please try and duplicate this "precondition failed" bug: http://josm.openstreetmap.de/ticket/3884 Here is the chain of events that seems to cause the most frequent problems: 1. Download and edit a small area (1 square mile or so). 2. Move along a way that was just edited, and download another small area. 3. Upload changes, but leave the changeset open. - Error may occur at this point. 4. Download and edit some more small areas along the same way. 5. Attempt to upload the new changes using the open changeset - Error *WILL* occur at this point. Depending on if the validator plugin is installed or not, you may also get a slew of warning messages about duplicate nodes. For the record, I've already tried wiping my \program files\JOSM and \application data\JOSM folders, but the problem persists. I've also noticed that the color scheme reverts from "Windows" to "Metal" every other time JOSM runs. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Addressing Question
No, you're not too late... I've been looking at addressing issues lately as well. Most of the addressing resources I've found are on the relations page of the wiki: http://wiki.openstreetmap.org/wiki/Relations#Addressing The most important consideration here is that you are dealing with address *ranges* that are related to linear street segments, not address *point* which are related to individual parcels and/or buildings. This will affect how you tag them in OSM. I haven't worked through the logic yet, but I think the way forward is in some kind of a composite tag, because you have to associate the way with the right/left polarity, the from/to range. SEJ "Wretches, utter wretches, keep your hands from beans." -Empedocles On Wed, Nov 11, 2009 at 20:13, Ian Dees wrote: > Hi everyone, > > I'm looking at some donated street centerline data that has addressing data > in the form of "Right/Left From Addr" and "Right/Left To Addr" on each > street centerline. Is there an accepted way of applying these tags to the > road ways? It doesn't really make very much sense to create and store a > separate way just for the addressing information. > > ...but I might have arrived too late in the argument to say that :-)... > > ___ > 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] Addressing Question
Hi everyone, I'm looking at some donated street centerline data that has addressing data in the form of "Right/Left From Addr" and "Right/Left To Addr" on each street centerline. Is there an accepted way of applying these tags to the road ways? It doesn't really make very much sense to create and store a separate way just for the addressing information. ...but I might have arrived too late in the argument to say that :-)... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] hillshade
On Wed, Nov 11, 2009 at 4:00 PM, Don Lambert wrote: > The problem seems to be with the "color relief" tiles between 106.6 long > and 107.3 long at the approx 1:34,285 and 1:17,142 scale levels. > Ian, how soon do you think these servers might become available? As I said, > I'm willing to chip in on a solution if need be. This is a really great > project especially for land surveyors like myself. > I'm waiting to hear back from two different vendors. If I don't hear back from them this week, I'll pursue asking for donations from the OSM-US community (and maybe try to coordinate with the US-based OSMF group trying to get formed). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] hillshade
The problem seems to be with the "color relief" tiles between 106.6 long and 107.3 long at the approx 1:34,285 and 1:17,142 scale levels. Ian, how soon do you think these servers might become available? As I said, I'm willing to chip in on a solution if need be. This is a really great project especially for land surveyors like myself. Don Lambert, PLS Frontier Surveying, Inc. 352 Norfolk Street Aurora CO 80011 Ph: 303-340-0113 Fax: 303-340-0114 fsico.net - Original Message - From: "Lars Ahlzen" To: "Ian Dees" Cc: "Don Lambert" ; Sent: Wednesday, November 11, 2009 12:23 PM Subject: Re: [Talk-us] hillshade > Ian Dees wrote: >> On Wed, Nov 11, 2009 at 12:05 PM, Don Lambert >> mailto:dlamb...@frontiersurveying.net>> >> wrote: >> >> Hello group & Lars, >> >> I notice when zooming into some of the mountainous regions in >> Colorado that the hillshade is not there. Why is that and how could >> we fix it? >> Also, is there any interest or possibility of getting the TopOSM >> Colorado running on a faster server? Possibly an EC2. I would be >> willing to contribute to this effort. >> >> >> I'll let Lars comment on the TopOSM specific question, but I am working >> with some colo facilities to get a server or two specifically for the US >> set up. TopOSM for the entirety of the US is one of the first things on >> my list. > > Don, > > I remember seeing some area with missing base layer tiles at some point, > but then I couldn't find it again and assumed that some re-rendering had > taken care of the problem. I guess I was wrong. > > Do you remember a specific location where the base tiles are missing? If > not, I'll start a new render (and upload) of the entire base layer > tiles. That takes a while, though. > > I agree that a faster web server would be nice. Ian, I very much > appreciate your work on this, and I hope something good comes out of it. > > And, yes, a TopOSM for the entire US would be very cool. It's near the > top of my list as well. > > - Lars > > -- > Lars Ahlzen > l...@ahlzen.com___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] hillshade
Ian Dees wrote: > On Wed, Nov 11, 2009 at 12:05 PM, Don Lambert > mailto:dlamb...@frontiersurveying.net>> > wrote: > > Hello group & Lars, > > I notice when zooming into some of the mountainous regions in > Colorado that the hillshade is not there. Why is that and how could > we fix it? > Also, is there any interest or possibility of getting the TopOSM > Colorado running on a faster server? Possibly an EC2. I would be > willing to contribute to this effort. > > > I'll let Lars comment on the TopOSM specific question, but I am working > with some colo facilities to get a server or two specifically for the US > set up. TopOSM for the entirety of the US is one of the first things on > my list. Don, I remember seeing some area with missing base layer tiles at some point, but then I couldn't find it again and assumed that some re-rendering had taken care of the problem. I guess I was wrong. Do you remember a specific location where the base tiles are missing? If not, I'll start a new render (and upload) of the entire base layer tiles. That takes a while, though. I agree that a faster web server would be nice. Ian, I very much appreciate your work on this, and I hope something good comes out of it. And, yes, a TopOSM for the entire US would be very cool. It's near the top of my list as well. - Lars -- Lars Ahlzen l...@ahlzen.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] hillshade
On Wed, Nov 11, 2009 at 12:05 PM, Don Lambert < dlamb...@frontiersurveying.net> wrote: > Hello group & Lars, > > I notice when zooming into some of the mountainous regions in Colorado that > the hillshade is not there. Why is that and how could we fix it? > Also, is there any interest or possibility of getting the TopOSM Colorado > running on a faster server? Possibly an EC2. I would be willing to > contribute to this effort. > I'll let Lars comment on the TopOSM specific question, but I am working with some colo facilities to get a server or two specifically for the US set up. TopOSM for the entirety of the US is one of the first things on my list. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] hillshade
Hello group & Lars, I notice when zooming into some of the mountainous regions in Colorado that the hillshade is not there. Why is that and how could we fix it? Also, is there any interest or possibility of getting the TopOSM Colorado running on a faster server? Possibly an EC2. I would be willing to contribute to this effort. Thanks, Don___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
