Re: [Talk-us] TIGER 2011 Road Tiles
On Sun, 2012-01-15 at 12:11 -0600, Ian Dees wrote:
The JOSM TMS URL is
http://{switch:a,b,c}.tile.openstreetmap.us/tiger2011_roads/{zoom}/{x}/{y}.png
Okay, I found this previous email in the mailing list. I started JOSM,
edited preferences, clicked on WMS/TMS, click on +, selected the TMS
tab and entered the above URL for TMS URL and TIGER 2011 for menu
name. I restarted JOSM, zoomed into an area then selected TIGER 2011
under Imagery menu. The layer shows up in the Layers list, but
nothing else changed on the screen.
The OSM vector layer (that I'm editing) and the TIGER 2011 layers are
the only ones visible. JOSM will show other layers when selected. Why
doesn't TIGER 2011 layer show up?
Thanks,
- Val -
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On Sun, 2012-01-15 at 18:47 +0100, andrzej zaborowski wrote: Perhaps checking if either the name= tag or the direction_suffix tag has ever been edited by a human would be a good measure. The ways which have been edited might need to be manually reviewed if they contain an unexpanded N, E, W or S. In my area I know of two separate streets named E Avenue and an E Street. The first bot going through got two of these, but I contacted the owner before it got to the third. If another bot comes through and corrects these, it will probably do the same (wrong) thing. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What is a dual carriageway?
On Sun, 2012-01-15 at 10:45 -0700, Martijn van Exel wrote: I only map two separate ways when there's a median you can't cross, so the two directions are physically separate. By that rationale, it should be one way feature. I am curious if other mappers use the same convention. That's the way that I map it too. Except that reminds me of a section of road that I have to fix to follow the convention I've used elsewhere. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER 2011 Release
On Thu, 2011-12-29 at 13:42 +1100, Nick Hocking wrote: Is this available, somewhere, in OSM format. There's a neighborhood in Parachute, Colorado, that wasn't in the original Tiger but has been added by a decliner, that I'd like to remap. Nick What I'd like is some way to manually merge the data. Perhaps a layer in whatever editor that can be enabled. It would really help if data (an object) in the 2011 layer could be selected then merged into the active layer. Then the 2011 data could be loaded and manually reviewed for inclusion. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Tue, 2011-11-01 at 21:16 -0400, Mike N wrote: On 11/1/2011 7:14 PM, Martijn van Exel wrote: But let's discuss: are address imports useful (I say yes, for geocoding and routing they're indispensable), necessary (I say yes, potential OSM data users will want to be able to do these things) and feasible (I say yes, if there's local mappers to oversee it)? I would agree - yes, yes, and yes if the data quality is good enough. TIGER is not of sufficient quality or precision to import - it is obfuscated to comply with privacy laws, but could be used by an external geocoder to get to the general vicinity. As long as we have all of the addresses, we could use satellite data to align them with houses. Is this the type of data we have in TIGER? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Complete Addresseses (Was: What does the community want from a US local chapter?)
On Fri, 2011-09-30 at 19:47 -0400, Serge Wroclawski wrote: My experience is that lack of complete addresses is a larger issue. I've been thinking of posting about this for a few weeks: I know that it would be better to have all of the delivery points listed on streets, but this takes a lot of time. It is much quicker to fill in address interpolations. Are either of these types of address data actually used anywhere? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Brainstorm: What should a US map of OSM data look like
On Tue, 2011-09-13 at 11:10 -0500, Brad Neuhauser wrote: Towns appear at zoom level 9 in Mapnik, which seems pretty decent to me. There are tagged towns in SW Kansas that show up, but some villages probably need retagging to towns in the N and W. The Place page recommends tagging county seats as towns regardless of population: http://wiki.openstreetmap.org/wiki/Place I started upgrading some county seats in NW MN to town, which helps fill things in, I think: http://osm.org/go/WprNC4-- Brad I think that this is also the time to add a development level to the place key. There are so many place names that aren't hamlets but are developments (like subdivisions) that have names. This could include the name of an apartment complex. I suggest this because there are apartments next to each other that have names. The lowest level that these place names can be tagged with is hamlet. But how many hamlets per square mile would be reasonable? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planet extract for the US
On Mon, 2011-08-22 at 23:53 -0600, Martijn van Exel wrote: Hi all, Is there a ready-made, reasonably frequently updated planet extract for the contiguous US available somewhere? Right now I am merging the partial US extracts made available by Geofabrik, but I'd love to be able to get it directly. Martijn I have a map for that! Please chose response: [ROFL] [Groan] http://daveh.dev.openstreetmap.org/garmin/Lambertus/30-04-2011/ If you don't have a Garmin, then you can check out this link: http://wiki.openstreetmap.org/wiki/Routable_maps - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On Sat, 2011-08-20 at 07:52 -0400, Peter Dobratz wrote: On Sat, Aug 20, 2011 at 6:04 AM, Henk Hoff toffeh...@gmail.com wrote: To my understanding our tagging-standard for State Highways is [STATE] [NUMBER] http://wiki.openstreetmap.org/wiki/United_States_roads_tagging#State_Highways I agree that we should use the standard 2-letter state abbreviation and then the number: AK 7 Because of the international nature of this project, we need to include the country as well. We've had this discussion several times before. It usually lasts a week or two then dies out with no resolution. Please, let's resolve it this time. What about another field for the network. For instance US:UT:SR for Utah State Routes then the ref tag will be just the number. I'd like to put it all into the ref field, but the renderers just don't parse this field and render the whole string. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On Sat, 2011-08-20 at 12:16 -0400, Josh Doe wrote: On Sat, Aug 20, 2011 at 12:01 PM, Val Kartchner val...@gmail.com wrote: Because of the international nature of this project, we need to include the country as well. Whatever we do, can we please have a vote on it? I know votes aren't binding, but it's better than having this discussion over and over again. I'd say the first order of business is to create a listing of what each state uses, whether it be SR 123 or VA 123. Okay, who wants to collect the list? I also think that we should email said person and let them post the resultant list to this mailing list. I'm not volunteering for this because I'm behind in too many things already. I think that the list (as-is) should be posted to this list on Monday, unless it is complete before then. Who wants to volunteer? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On Sat, 2011-08-20 at 09:29 -0700, Dave Hansen wrote: On Sat, 2011-08-20 at 12:16 -0400, Josh Doe wrote: I'd say the first order of business is to create a listing of what each state uses, whether it be SR 123 or VA 123. I also do some work on open-source software projects. When you add new code, you at least make it _consistent_ with what's there before. Barring that, you just end up with everyone's different personal styles and no one can make sense of it. Same goes for the ref tags. The way it is now, the map just looks goofy. Roads are changing names from the casual users's perspective: http://www.openstreetmap.org/?lat=34.0475lon=-93.8215zoom=14layers=M The problem with this is that being consistent with what went before (first paragraph) means that it makes the map look goofy (second paragraph). We need to decide on a standard then go through and change everything. We could even have a 'bot go through and make a list of routes up for review. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On Sat, 2011-08-20 at 13:39 -0400, Nathan Edgars II wrote: On 8/20/2011 1:29 PM, Metcalf, Calvin (DOT) wrote: From: Nathan Edgars IInerou...@gmail.com On 8/20/2011 12:42 PM, Metcalf, Calvin (DOT) wrote: It doesn't matter if a state like MA uses SR internally we just use that because we deal with only one states routes. Postal code prefixes for all routes makes the most sense. So how do you distinguish California from Canada? Or Delaware from Germany? And do you support putting an abbreviation of the county name in the ref tag for a county route? Or are those fine with the ambiguous CR? We don't deal with other states so we don't distinguish so in a international contect you'd need to add more detail Meaning? How would you add more detail? US:MA:2? US:FL:ORA:535? UK:GB:M1? And once we set our standard here in the US, how do we get it adopted world-wide? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On Sat, 2011-08-20 at 14:56 -0400, Phil! Gold wrote: * Nathan Edgars II nerou...@gmail.com [2011-08-20 14:24 -0400]: I agree with this, and will abide by any reasonable consistent convention. The wiki has long recommended using the two-letter state abbreviation, a space, and the number. Is there any problem with continuing to use this approach? (Aside from somehow not being able to differentiate between Delaware and Germany even though this is a spatial database.) Because some states officially designate the road as SR-26, for instance. There are also county roads, CR-1963, for instance. If we eliminate the prefix then we lose information. I haven't seen anywhere in Utah where removing the prefix would cause ambiguity, but I haven't been looking around the state for such instances. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] SR-96 partially gone
Hello, I've been mapping Scofield Reservoir in Utah. I've also been aligning roads with satellite images. SR-96 has partially disappeared after my edit. It was there before. http://www.openstreetmap.org/?lat=39.78855lon=-111.12483zoom=17layers=M This is the area with the problem. If you zoom out one level you will see SR-96 appear again. What is wrong? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] SR-96 partially gone
I'm replying to both replies to my message so far, so I've included both of them. On Sat, 2011-07-16 at 16:21 -0400, Josh Doe wrote: It just needs to be re-rendered. Click permalink, then force a refresh by Shift+Reload or Ctrl+F5, though I've already done that. Right click the map, then view image, and add /status at the end to get the status of the tile, like this one: http://a.tile.openstreetmap.org/17/25078/49722.png/status It says: Tile is due to be rendered. Last rendered at Sat Jan 01 00:00:00 2000 Saturday is a heavy load on the rendering servers, so give it a while and it will re-render. -Josh I tried this and got the same result. It is lying about when it was last rendered because the route used to be there at that zoom level. I actually started editing when I was zoomed in one level closer and it was there. Is this a HAL 9000 moment: I'm sorry Dave. I'm afraid I can't do that.? I know what comes next in that movie. ;-) On Sat, 2011-07-16 at 15:28 -0500, Toby Murray wrote: Tiles are not being re-rendered after edits right now because of this: http://wiki.openstreetmap.org/wiki/Power_Maintenance_Q3_2011 I'm not sure why it disappeared but if you look at the data, it is clearly there so I would wait until the current outage is over and the tile rendering has caught up before panicing too much. Toby It has already rendered once, which caused the problem in the first place. I'll wait over the weekend (as you have both suggested), but I don't see how it will be different. Given the same input, the computer should give the same result. However, with more observers the answer could now be different. (See Schrodinger's Cat.) I've actually had times when I can reliably repeat (several times) a problem with a computer. I bring someone else over to show them what is going wrong, but it never repeats again. I hope that this is one of those times. On Sat, Jul 16, 2011 at 3:04 PM, Val Kartchner val...@gmail.com wrote: Hello, I've been mapping Scofield Reservoir in Utah. I've also been aligning roads with satellite images. SR-96 has partially disappeared after my edit. It was there before. http://www.openstreetmap.org/?lat=39.78855lon=-111.12483zoom=17layers=M This is the area with the problem. If you zoom out one level you will see SR-96 appear again. What is wrong? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Grand Junction + TIGER 2010
On Sun, 2011-06-26 at 10:45 -0400, Mike N wrote: On 6/26/2011 10:01 AM, Nick Hocking wrote: What would be really usefull is to have OSM in one of the geofabrik compare windows and TIGER 2010 in the other. Is there an easy way to achieve this? Until Ian gets the comparison server up, you can try setting the Inactive layer color in JOSM to a bright color.Download an area of interest. Open the .OSM file - it will come in as a new layer. Then ... Okay, when is the expected time for Ian to get this up and running? Also, this has probably been stated before, but where do we get these sections of data? Thanks, - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Create GIS database for Non Profit Organization
On Sat, 2011-06-25 at 10:12 -0400, Serge Wroclawski wrote: Clifford, I'm afraid I didn't entirely understand the question, but will try to give it a shot anyway. On Fri, Jun 24, 2011 at 8:13 PM, Clifford Snow cliff...@snowandsnow.us wrote: The data for Washington State is available. It would seem that it could be entered with tags that could be searched by a from a web site First, when you say the data for Washington State is available, we have to be very careful about what exactly that means. In essence, you'd be doing an import into OSM, and generally imports have not been overall good for the project and are /generally/ frowned upon. Even in the best case, you'd need to do a great deal of work not only making sure the tags are right, as you point out, but also ensuring that the data you enter is not already present in someone else's contributed data. And you would need to ensure that the data is properly integrated, and then properly maintained, with a plan for handling updates. What I think that you mean by this is that unsupervised data imports are frowned upon, for the reasons that you've given. Such scenarios need to be tried in a small area with thorough review. Let others on this mailing list know about the test area so that it can be peer reviewed. You'll need to see how this trial goes before proceeding with other areas. Good luck, - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Create GIS database for Non Profit Organization
On Sat, 2011-06-25 at 08:40 -0600, Val Kartchner wrote: On Sat, 2011-06-25 at 10:12 -0400, Serge Wroclawski wrote: What I think that you mean by this is that unsupervised data imports are frowned upon, for the reasons that you've given. I should not have seemed to have put words in Serge's mouth. The previous opinion that I expressed was more my perception than a restatement of Serge's words. I will leave a restatement to him, if he wishes to do so. I would like to say that, with a compatible license, imported data can be useful. It must be thoroughly tested and reviewed, just like I stated in my previous message. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] default to potlatch 1?
On Tue, 2011-04-05 at 02:23 -0700, Richard Fairhurst wrote: Val Kartchner wrote: I can confirm that this is still happening. Fixed now. Thanks for the reports. Richard Richard, It has been fixed. I'm back to using Potlatch 2 again. Thanks. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Dirt Bike Area
On Sun, 2011-04-03 at 15:15 -0400, James Umbanhowar wrote: On Sunday, April 03, 2011 08:53:50 am Richard Weait wrote: Why not highway=track, surface=dirt for the built-up track itself ? Some of these areas don't have have a fixed track and may be best viewed as a homogeneous area. This is an area with small hills that have been built up for use as jumps. There are no specific tracks. An area would be the best designation. But I don't see anything in the wiki. Should a proposal for such a designation be started? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Dirt Bike Area
Within the past few days I discovered an area built up for public use of pedal dirt bikes. I have searched but have not found a way to designate such an area. Has something been created yet? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Interstate exit junction exit_to tag
On Mon, 2011-03-28 at 18:27 -0400, Richard Welty wrote: On 3/28/11 6:21 PM, Nathan Edgars II wrote: This seems to be a display choice rather than an actual space in the exit number. we should standardize on how we enter them, either space or no space (and no tricky unicode characters, just a normal space if there is to be one.) the display is a rendering choice, let's not embed that into the ref tags. richard There is a simpler solution: Let the computer fix it. To express the pattern in Perl: display $1 $2 if($ref =~ /^(\d+)\s*(.*)$/); This means that if there is a series of digits followed by an optional space followed by any characters; display the digits, a space followed by the remaining characters. Of course, there would be variations of this basic pattern. However, the point is that whether there are spaces or not is easy to fix. The output is even up to the renderer. Just let the computer fix it. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] USPS Address Database
I think that someone has brought this up before, but I forget what happened. Can we get the United States Postal Service (USPS) address database? It would still take some adjustments, but this would be a lot easier than driving every street and finding the numbers. A lot of house numbers are hard to find. The cops may be called if we go around casing houses. With the database we can just align them with houses/buildings. We'll only have to go to places where something doesn't line up. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USGS National Hydrography Dataset
On Thu, 2011-02-17 at 08:57 -0500, Phil! Gold wrote: (TopOSM also shows a lot of intermittent streams from the USGS National Hydrography Dataset.) Can we get this USGS dataset loaded? It would be more accurate than tracing from satellite images, and much quicker too. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Parking lot not rendering
I'm having a problem with the Mapnik rendering of this area: http://www.openstreetmap.org/?lat=41.176495lon=-111.948208zoom=18;. In the retail area northwest of 48th Street and Harrison Blvd (UT-203) I have entered parking lots. However, they are not rendering. The commercial area just north of that is part of the same parking lot but it is being rendered. What is wrong with the retail area? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parking lot not rendering
On Sat, 2011-02-12 at 13:28 -0500, Nathan Edgars II wrote: On 2/12/2011 12:47 PM, Val Kartchner wrote: I'm having a problem with the Mapnik rendering of this area: http://www.openstreetmap.org/?lat=41.176495lon=-111.948208zoom=18;. In the retail area northwest of 48th Street and Harrison Blvd (UT-203) I have entered parking lots. However, they are not rendering. The commercial area just north of that is part of the same parking lot but it is being rendered. What is wrong with the retail area? It's because the parking lot crosses a landuse boundary. Mapnik, in my experience, tries to find which of two objects is inside the other and renders them with the smaller one on top. But if they cross results are suboptimal. Aerials indicate that the commercial parking lot is not connected to the retail parking, so it should be a separate polygon, even putting aside this complication. That was it. I split the parking lot at the boundary of the land use, and it now renders correctly. I'll have to keep this in mind when I'm drawing parking. I figured that since there was very little separation between parking lots that it should be done as one big one. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parking lot not rendering
On Sat, 2011-02-12 at 14:10 -0500, Nathan Edgars II wrote: On 2/12/2011 2:01 PM, Val Kartchner wrote: That was it. I split the parking lot at the boundary of the land use, and it now renders correctly. I'll have to keep this in mind when I'm drawing parking. I figured that since there was very little separation between parking lots that it should be done as one big one. Oh, I didn't even notice the big area to the north. I was talking about the small commercial lot off 48th. Since the two large areas do in fact share parking with absolutely no separation, it's probably best to treat them as one parcel and use the more prominent landuse value (or should it be commercial by default, since retail is a subset of commercial?). Then you can indicate the actual uses of each building (which may be mixed; an office building might have a cafe on the first floor). (By the way, the commercial parking to the north still goes slightly into the retail area. Maybe Mapnik calculates the area and draws from biggest to smallest?) An area (parking lot, pedestrian, whatever) should only be one piece if it's all connected. Since you can't enter the retail parking lot and get to the small south commercial parking, they should be two separate areas, close *but not touching*. Okay, I've fixed both of the problems that you noted. I do like to make things as detailed as I'm able when I'm mapping. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NoName and Roundabouts
On Fri, 2010-11-26 at 00:13 -0800, Gregory Arenius wrote: Although most roundabouts aren't considered to be part of a way I there might be some that are named or are considered to be part of one of the attached streets. I would just tag the unnamed roundabouts with noname=yes so that its explicit that they are unnamed. NoName render recognizes the tag as well so it won't render as an error. Cheers, Greg I've tagged the roundabouts as you've suggested. I'll see how it comes out. For a while there, NoName hadn't been rendering. How quickly does NoName render now? Why was the MapLint layer removed from Potlatch? On Fri, 2010-11-26 at 16:16 -0500, Dale Puch wrote: Should it be marked? probably not, but here are two other suggestions. Depending on the situation, perhaps use a mini-roundabout, or make the roundabout a split 1-way section in the main road. What do you mean that it shouldn't be marked? I didn't mark it as a mini-roundabout because it does not fit this description from the wiki: The mini-roundabout usually does not have an island in the middle but is painted on the road. I also didn't do a split one-way because the roundabout isn't really either of the ways but a special junction of the two ways. I also like that with the Garmin maps (though not the OSM-derived Garmin maps) you will be told which exit (relative to where you enter) to use for exit. My comments are how I've been tagging roundabouts. This is certainly open for someone changing my mind though. That's most of the reason I ask here. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] NoName and Roundabouts
When I do a roundabout it shows up on the NoName renderer as a way with no name. Most roundabouts around here don't have names so they shouldn't be tagged as needing a name. These are tagged with junction=roundabout so this can be used for this special case. Can we get a consensus on this then get it changed? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Highway shields
I know that we've discussed this before, and there was no consensus to change the current rendering. However, I think that we should to better than the other mapping services. We should have a shield for highways that have such. Despite the images that I gave that demonstrated otherwise, there were more people that thought that adding shields made the numbers unreadable than those who thought they were readable. What if, instead, we put the shields before the numbers. So, for instance UT-67 would be rendered (as an ASCII example) like this []67) Where [] is the shield, 67 is the number, and ) is the oval (also around 67) that is currently done. What do you think about this? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway shields
On Thu, 2010-11-25 at 16:23 -0500, Richard Weait wrote: Have you got a demo of what you are suggesting? It sounds like you are suggesting rendering the shield beside the reference number. Would the shield have number in it as well, then the larger, more legible number beside it? Yes, this is exactly what I meant. I could produce a demo. However, this idea it has already been shot down by the same person who shot down my previous idea. Here are a couple of examples from my shield server. And these are the very type of things that were shot down before. These are exactly what I suggested. My examples were smaller to show that this could be done with a small shield. What I have been told (on this mailing list) is that if a consensus is developed for rendering shields then the rendering will be added to Mapnik and Osmarender. I like your idea. Can we get a consensus to do this? I think that the big map providers should be a floor and not a ceiling. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposal: delete census-designated place polygons
On Fri, 2010-11-12 at 02:24 -0500, Nathan Edgars II wrote: On Fri, Nov 12, 2010 at 1:34 AM, Daniel Sabo daniels...@gmail.com wrote: The problem comes from the fact that the trailer park was a hamlet inside of a city, but then there are legitimate cases for nesting like that, and there's no way for Nominatim to tell the difference if there are only nodes. place=hamlet is misleading for a trailer park. If it's inside a city, it's probably best to use place=neighborhood. I'd like to use place=neighborhood as well. Can we get a consensus to make this addition? This should be doable as a point because these developments, if they do have a sign, don't usually have a map designating the boundaries. One would have to get the government documents to find out such boundaries. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Wed, 2010-10-27 at 15:17 -0400, Nathan Edgars II wrote: On Wed, Oct 27, 2010 at 2:04 AM, Val Kartchner val...@gmail.com wrote: Sorry to disappoint, but the 17x17 example that you gave is quite readable. Not nearly as readable as a lone 7. I've attached another 17x17 that is also readable. Since readability at 17x17 is demonstrably not an issue, what is your real objection to route-specific shields? Clutter and legibility. Nathan, So, your problem is not the size of the shields but the route-type specific shields themselves? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Route Tagging Consensus
On Fri, 2010-10-29 at 23:57 -0400, Richard Weait wrote: It feels like we have been going around in circles on this for almost two years. I wrote this in March 2009. I concur. Discussions here go round and round, with no decision being reached. They die then come up a few years later. Sounds like a haunted house. ;-) - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Tue, 2010-10-26 at 10:11 -0400, Nathan Edgars II wrote: On Tue, Oct 26, 2010 at 3:17 AM, Val Kartchner val...@gmail.com wrote: On Tue, 2010-10-26 at 01:27 -0400, Nathan Edgars II wrote: No for state roads in general. Some shields are poorly-designed for display in a limited number of pixels. For example http://commons.wikimedia.org/wiki/File:Colorado_7.svg is four times the size a simple rectangle would be. Attached are the bitmaps of the shield that is poorly-designed for display in a limited number of pixels. The first one is 39x39 pixels, and the second is 20x20 pixels. Both are quite readable. It's actually 17x17 that you want: http://upload.wikimedia.org/wikipedia/commons/thumb/b/b8/Colorado_7.svg/17px-Colorado_7.svg.png and this is somewhat harder to make out than Mapnik's 7 in a circle: http://www.openstreetmap.org/?lat=26.6963lon=-80.1974zoom=14layers=M And Mapnik's default shield actually has a bit of padding; the number itself is in a 13x13 space. Sorry to disappoint, but the 17x17 example that you gave is quite readable. I've attached another 17x17 that is also readable. Since readability at 17x17 is demonstrably not an issue, what is your real objection to route-specific shields? - Val - attachment: 17px-Colorado_7.png___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Tue, 2010-10-26 at 13:15 -0400, Richard Weait wrote: On Tue, Oct 26, 2010 at 1:02 PM, Alex Mauer ha...@hawkesnest.net wrote: On 10/26/2010 10:50 AM, Nathan Edgars II wrote: It's a tradeoff where bigger shields reduce the space for other features. Sure, but that doesn’t mean that we can’t adjust to give a little more space to highway shields. These rendering decisions are completely unrelated to the discussion of how shields might best be tagged. Easy: Use ref= tag. Anything before final non-alphanumeric is the network, and anything after is what is put in the shield. I proposed this a few weeks ago and no one has provided a counter example that doesn't work with this simple method. Examples: ref=network identifier US:I-15 US:I15 US:US 89US:US 89 US:UT:SR-67 US:UT:SR 67 US:NH:3AUS:NH 3A US:MI:M-6 US:MI:M 6 UK:A A4 UK:AA4 If you object to having all of this in one tag, put the identifier in the ref= tag and the network in highway:network= tag. Simple for people to enter. Simple for computers to parse. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Tue, 2010-10-26 at 01:27 -0400, Nathan Edgars II wrote: On Tue, Oct 26, 2010 at 12:45 AM, Val Kartchner val...@gmail.com wrote: Second, let's decide if we should render the route numbers in route-type specific shields. I think that we should do so. Let's not let Google, MapQuest and Bing be a ceiling, but instead a floor. No for state roads in general. Some shields are poorly-designed for display in a limited number of pixels. For example http://commons.wikimedia.org/wiki/File:Colorado_7.svg is four times the size a simple rectangle would be. Attached are the bitmaps of the shield that is poorly-designed for display in a limited number of pixels. The first one is 39x39 pixels, and the second is 20x20 pixels. Both are quite readable. These were both reduced to bitmaps using the SVG file you gave me using Inkscape. If there are any shields that don't work well this way, the blank shields can be redrawn manually. The same for any unclear digits. Then the renderer can put these pieces together. But this is only if the simple solution (demonstrated by the attachments) doesn't work. Any other objections to my suggestion? - Val - attachment: Colorado_7.svgattachment: Colorado_7-20.png___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] [Fwd: Re: Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)]
Oops! I attached the SVG and the 20x20 image (1/20th original size). I meant to attach the 39x39 image (1/10th original size). Here it is. ---BeginMessage--- On Tue, 2010-10-26 at 01:27 -0400, Nathan Edgars II wrote: On Tue, Oct 26, 2010 at 12:45 AM, Val Kartchner val...@gmail.com wrote: Second, let's decide if we should render the route numbers in route-type specific shields. I think that we should do so. Let's not let Google, MapQuest and Bing be a ceiling, but instead a floor. No for state roads in general. Some shields are poorly-designed for display in a limited number of pixels. For example http://commons.wikimedia.org/wiki/File:Colorado_7.svg is four times the size a simple rectangle would be. Attached are the bitmaps of the shield that is poorly-designed for display in a limited number of pixels. The first one is 39x39 pixels, and the second is 20x20 pixels. Both are quite readable. These were both reduced to bitmaps using the SVG file you gave me using Inkscape. If there are any shields that don't work well this way, the blank shields can be redrawn manually. The same for any unclear digits. Then the renderer can put these pieces together. But this is only if the simple solution (demonstrated by the attachments) doesn't work. Any other objections to my suggestion? - Val - attachment: Colorado_7.svgattachment: Colorado_7-20.png---End Message--- attachment: Colorado_7.png___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Sat, 2010-10-23 at 06:30 -0700, Craig Hinners wrote: [...] (Or, if you're of the brevity and ambiguity trumps verbosity and clarity camp, I give you network:US:WI, network:US:US, network:US:I.) [...] No endless parsing of the tag value, looking for I- to determine whether that way is an interstate, oh, oops, this guy doesn't like hyphens, I need to look for I*, oh, oops, that gets me everything for Iowa and Idaho, oops, now my function to determine whether a way is an interstate is 1 lines long with 500 if statements and regular expressions that would make a CS major run for the hills. No, it's very easy. Colons separate fields, and non-alphanumerics separate subfields. Fields are arranged from highest level administrative level, starting with ISO two-letter country codes. Everything before the last subfield is used to determine the shield to use. Look at these for example: Ref:Shield Number US:I-15 US:I15 US:US-89US:US 89 US:UT:67US:UT 67 US:UT:SR-67 US:UT:SR 67 US:UT:CR-1983 US:UT:CR 1983 US:NH:3AUS:NH 3A If people don't use the country reference, then it will be more difficult to figure out which shield to use, but these could be tagged and fixed manually. The bigger problem is rendering the shield so that it is clearly readable. Another problem will be making state-specific shields that can be clearly rendered. Something that could be done is that the basic shields will be made manually. The numbers would also be done manually or they become fuzzy at small sizes. The shields and the digits would be put together by a program, so the complete shield would be made by computer. The big map providers (Google, Yahoo, Bing, MapQuest, etc.) should be considered a floor (minimum) for OSM rendering, not a ceiling. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Fri, 2010-10-15 at 12:08 -0400, Phil! Gold wrote: == Hyphens == There's a lot of inconsistency in tagging in road's ref= tags. The main wiki pages (Interstate Highways, United States road tagging) specifically call for using spaces between the network designation and the network number. A lot of people still use dashes for Interstates, because thet's how they're commonly written (and because I-5 is more obvious than I 5, which might be read as 15). At least here in the US, the dash is convention so it should be used in the map. == Inconsistent State Prefixes == This is another very inconsistent area. The main US wiki page (United States road tagging) says to use the state's two-letter postal code (optionally with a US: prefix). In practice, usage varies wildly, generally based on how individual states prefer to represent their routes: in states like Maryland that use their postal code, usage is pretty uniform; in states like Ohio that use a SR prefix, usage is mixed between local customs and the postal code standard. A further complication is the presence of county roads. The wiki doesn't mention any standard for those. From what I've seen, they mostly end up as CR or whatever the local nomenclature is. Should we use the postal code everywhere for nationwide consistency or should we use the prefixes that locals use? If we use postal codes, what should we do about county or town roads? We should find some consistent way to do it such that it is easy for a renderer to parse. Then the renderers will need to be changed to use them. Once this is done, people will be more likely to enter them properly since they will show up in a special way. So, for instance, in Utah the state routes are designated (without abbreviation) State Route 67 (for instance). This is abbreviated as SR-67. However, a sign with this designation is not used very much. The much more commonly used signage is 67 is the state highway shield (a white beehive on a black background). This is how the renderers should put it on the state highways. (Wikipedia does it this way on each page.) I haven't seen any county road signs (on physical roads), but I've heard the renderers will draw the number in a circle. The standard should be something easy to parse. Perhaps, for the above example, it would be US:UT:SR-67. This would allow an easy way to parse which shield to use. For instance, a made-up Canadian route would be CA:BC:12. The colons would designate a field, and a space or dash would indicate a subfield. The renderer could just use all but the last field to figure out which shield to use (US:UT or CA:BC), then use the last subfield of the last field to draw the shield. This would work for an instance I've seen in New Hampshire which would be US:NH:3A. I'm sure that there are some exceptions, to using the last subfield to draw the shield. Let's hear about them. == Semi-Colons == He shows a road that has a ref= of I 88;56. I think it should be completely uncontroversial to say that each part of a semicolon-delimited ref should have the appropriate network information in it. I agree with your solution. Again, the renderer needs to draw the highway shields. If there is no special treatment by the renderer for doing things in the proper way, then it is less likely that things will be tagged correctly. I'm reminded of the truism, What gets rewarded gets repeated. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Towns as Areas or Points
On Tue, 2010-08-31 at 18:23 -0700, Alan Mintz wrote: At 2010-08-31 07:47, Serge Wroclawski wrote: ... It just makes no sense to me that an area with this high population and population density [Silver Spring, MD] is labeled a hamlet. Particularly when it seems that hamlet is also used for mobile home parks (commonly 50-500 residents) in the GNIS data. The wiki says that hamlet is 1000. The only place possibly smaller is suburb, but no population is given. There should be some place types below hamlet. For instance, an actual hamlet would have the same priority for rendering as a mobile home park (as above) or any number of subdivisions in said hamlet. The subdivisions of said hamlet should be rendered only at high zoom levels and in a smaller font than the hamlet, but currently the leftmost one is most likely to be rendered and they will all be rendered in the same font. 1) Should this be fixed? (YES!) 2) How do we fix it? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Towns as Areas or Points
On Tue, 2010-08-31 at 23:56 -0400, Nathan Edgars II wrote: On Tue, Aug 31, 2010 at 11:46 PM, Val Kartchner val...@gmail.com wrote: The wiki says that hamlet is 1000. The only place possibly smaller is suburb, but no population is given. There should be some place types below hamlet. Mapnik renders suburb in a larger font than hamlet/village, which implies that it's more major. I think it's an official government designation in Australia. For subdivisions and small planned communities I draw the border and create a multipolygon with landuse=residential and no place=* tag: http://www.openstreetmap.org/?lat=28.4669lon=-81.5045zoom=14layers=M Subdivisions (planned communities in the U.S.) are currently tagged (from TIGER data) as hamlets. They would show up at the same level as the hamlets of which they are parts. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Dealing with types of places (possibly US-specific)?
On Mon, 2010-08-16 at 23:34 -0400, Nathan Edgars II wrote: What place=* values should be used for unincorporated places? In some states villages are incorporated; do we skip this value? Do we use suburb at all, or is everything village or hamlet? There should be something between 1000 and 2, but there isn't. A lot of the place names that were loaded with TIGER data are subdivisions. There is no place key for such small places. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Thu, 2010-08-12 at 14:54 -0600, Kevin Atkinson wrote: I think that these components should be automatically separated by parsing the street name some how, and only require manual entry when there is ambiguity. When there is ambiguity, I think just entering in the Street Name (base type in tiger) will be enough. However, the directional prefixes can't be automatically parsed out. Just as some examples, from your home of Salt Lake City, there is North Temple Street, South Temple Street and West Temple Street. These are the actual names. A complete address would be something like 150 West North Temple Street. Further north, around Ogden, there are actually two streets named North Street, one South Street, and (one I found today) a South Pointe Street. There is also an East Crest and West Crest. In each of these cases, the seeming directional prefix is part of the street name and not a prefix. One North Street could have East or West directional prefixes (for addresses), but for various reasons the others wouldn't. Names like South 3300 West could automatically be parsed. There would be other patterns that we could find that would always work. There would be many others that couldn't automatically be parsed. We will need a solution that is easy to enter. What about using separators, like the standard semicolon. Any names without separators (and not an always works pattern) would need to be manually reviewed. So the above example would become South;3300;West;Street. This separates out the parts of the street name into, in this case, directional prefix, street name, directional suffix, type of street. They wouldn't need to be in any specific order since there would only be a limited set of strings that could be in the fields other than street name. Some of the other examples above would become South Pointe;Street and West;North Temple;Street. These work because South Point isn't one of the known fields like South. However, North;Street and South;Street wouldn't work with this scheme, so we'll need something beyond this simple idea. Also, the renderers seem to be VERY slow at catching up to changes like this. (They're still arguing about how to handle route numbers separated by semicolons.) Would there be a way for a 'bot to monitor street name changes and parse something like the above idea, separate it into appropriate key/value pairs, then fix up the regular name field to a standard format? Then the 'bot could check other changes to a name field and flag it for manual review. Okay, shoot these ideas full of holes, just as long as we make progress. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, 2010-07-30 at 15:00 -0400, Anthony wrote: Basically, the only tag I can imagine worth keeping would be the name_type, name_base, name_* ones, and those should be removed from the tiger:* namespace. But really before that can be done a standard should be decided on about how to store the names. Once that is done, I'll gladly produce a script to re-add all the name_base/name_types that I've deleted. Good luck on this idea. This is the fourth time that it has been brought up since I've been on this mailing list (less than a year). There is much discussion but no decision is made. The topic gets dropped, then the topic comes up a few months later. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
On Sat, 2010-07-31 at 16:34 -0600, Kevin Atkinson wrote: On Sat, 31 Jul 2010, Mike Thompson wrote: On Sat, Jul 31, 2010 at 3:27 PM, Kevin Atkinson ke...@atkinson.dhs.org wrote: All cities in Utah (that I am aware of) are laid out in a grid and use grid style addressing (I think you alluded to this in your post). In the above example, there is probably also a N 900 E. If move the S or South (I don't want to get into the expand vs. not expanding abbreviations here), you introduce a potential ambiguous situation. There is a North and South 900 East, but they are the same road. North becomes South when it crosses South Template. The only ambiguous situation is if you give an address of 333 900 E, as this has two potential locations (one North and one south of South Temple). The correct address is 333 S 900 E. Hence, the directional prefix is more part of the address. In additional most printed maps do not include the directional prefix. It is only really found on online maps. If the road changes names when it crosses South Temple (other cities in Utah use Main or Central as the dividing line), then I would contend that it is a different road, at least name wise. The road name does not really change. The directional prefix is not really part of the road name, it is not signed that way. When someone asks you what street you live on you would say 900 East (or sometimes 9th East), you will not include the directional prefix. In Salt Lake City, South Temple is 0 N/S and Main Street is 0 E/W. Though the Avenues District changes the normal grid layout. While Ogden (Utah) is laid out in a grid, it is somewhat different. In Ogden, Wall Avenue is 100 E/W and North Street is 100 N/S. Also, east and south direction prefixes are assumed if none is given. So 3725 Washington is really 3725 South Washington Boulevard, and 350 25th is 350 East 25th Street. If/when you run your script on Ogden (which I'd like), you'll have to take this directional assumption into account. However, we come to the problem of tagging as the street signs say (as the wiki says with abbreviations expanded), or tagging for address look-up (which I've only seen Cloud Made make available). When tagging for alternate names, do we use name, name_1, name_2, name_3, etc, or name, alt_name. Note: Some streets that I've corrected tags on legitimately have six name tags. For instance: Washington Boulevard, South Washington Boulevard, 400 East, South 400 East, 400 East Street, South 400 East Street, US-89, though the last one I've put in the ref tag. (However, it would be legitimate to give an address like 3750 South US-89 and it would get there. When US-89 splits off from Washington Boulevard, it is fully spelled out as United States Highway 89.) If you don't want all of the variations put in some sort of name tag, then develop a standard way of conveying the same information. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: [OSM-talk] Mapquest launches site based on OSM!
On Mon, 2010-07-19 at 18:51 -0400, Richard Welty wrote: On 7/19/10 4:48 PM, Nathan Edgars II wrote: There's been no standard way of tagging state highways since before I joined at the beginning of this year. the US routes page has always called for US:ST or ST since i joined last summer. it's all a matter of which wiki pages you find. Yes, I've had a dispute with another local mapper in Utah about this very issue: How to tag state routes. It has been brought up on this list twice already, with no resolution. The discussion dies rather quickly This one will go the same way, a lot of talk but no resolution. Good luck, - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] County lines vs. TIGER roads
I've noticed that the roads at county boundaries were imported separately and not connected. I know that there was an effort to connect all of the Interstates at county boundaries, and I haven't found any problems. Major roads have also been fixed. However, I've been working on the back-country roads. These are mostly tracks in the mountains. I've been connecting them manually, at least in my local area. My concern isn't about making these connections (though it would be good to have a 'bot make these fixes). What I've noticed is that where the counties change on the roads and the actual county lines don't line up. I know that the TIGER data isn't very accurate (within a few hundred feet), but the county line data seems to be low resolution. I know in my area, county lines often follow watershed boundaries. The low resolution county boundaries don't follow the ridge lines. Is there a way that we could get higher resolution county line boundaries from anywhere? I expect not, but I figured I'd ask. I'll plan to continue to correct these manually. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] County lines vs. TIGER roads
On Thu, 2010-06-24 at 01:22 -0400, Nathan Edgars II wrote: On Thu, Jun 24, 2010 at 12:41 AM, Val Kartchner val...@gmail.com wrote: Is there a way that we could get higher resolution county line boundaries from anywhere? I expect not, but I figured I'd ask. I'll plan to continue to correct these manually. The TIGER county boundaries should be better than the existing USGS data: http://www2.census.gov/cgi-bin/shapefiles2009/national-files For some reason the TIGER import didn't include these, nor minor types of municipalities (mainly townships - County Subdivision (Current) in the by-state downloads), but did have those silly census-designated places. Ah, so it USGS county lines that were imported. Can we get TIGER county lines imported instead, if they're more accurate? They should at least match the county assignments on the roads. We should leave the import to someone more experienced than me though. And what would we do about the county lines that have already been edited? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Aeroway=Aerodrome Modifier Tags?
On Sun, 2010-06-20 at 11:04 -0400, Zeke Farwell wrote: On Sun, Jun 20, 2010 at 6:28 AM, Lennard l...@xs4all.nl wrote: On 20-6-2010 0:53, Val Kartchner wrote: So, apparently we have to work it out ourselves before they'll even consider making the change. The problem is that once we add a tag to the stylesheet, and it starts rendering, it is very hard to subsequently remove it for a better tagging scheme. Especially now that there's this whole discussion on airodrome tagging, the quick request for aerodrome=rc_airstrip struck me as let's try to get this one tiny aspect of that rendering. Implementing this would mean nothing for the abundance of airports now rendering in mapnik, even at lower zooms. I would love to be able to render some at higher zooms only, based on hints such as a specific tag for airport size and/or national/regional importance. A good and non-arbitrary tagging scheme would be the way to go. So, now you know why I made those remarks on that ticket. Discuss, document, request rendering. Usually in that order. Yes, and we are currently in the Discussion phase. When I have some time I'll try to get a proposal up on the wiki with the goal of moving things towards the Documentation phase. I've never made a proposal before so I need to figure that out. I also want to read over all the ideas thrown out in this thread first. If anyone else feels motivated and beats me to it that's fine too. As mentioned before there already is a general importance tag proposal. Moving that one along would certainly enable airports to be rendered at different zoom levels. An airport specific tagging scheme may be desirable too though. It may be useful for a future renderer to show more detailed information about airports. Zeke I followed the directions from someone (I assumed to be) more experienced with OSM who told me (quote): i have a real problem with tagging highway=residential to get an airstrip to look right. instead, you should tag it correctly and open a ticket to get the renderer fixed. I changed the tagged RC runway then entered the ticket. I have now been enlightened as to the proper procedure. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Aeroway=Aerodrome Modifier Tags?
On Thu, 2010-06-17 at 23:20 -0600, Val Kartchner wrote: On Sat, 2010-06-12 at 20:28 -0400, Richard Welty wrote: aerodrome=rc_airstrip aerodrome is used for an area. I've submitted the change as #3062 (aeroway=rc_runway), similar to how regular runways are tagged. - Val - I received a reply for this change: Could you please work out a satisfactory tagging scheme on the tagging (and talk-us) mailing lists[1] and the wiki[2] before we consider adding this ad hoc key? FYI: The current tagging discussion would encompass more than just making a place for rc strips, but also cater for all aeroways, big international, to small local, to rc strips. So, apparently we have to work it out ourselves before they'll even consider making the change. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Aeroway=Aerodrome Modifier Tags?
On Sat, 2010-06-12 at 20:28 -0400, Richard Welty wrote: aerodrome=rc_airstrip aerodrome is used for an area. I've submitted the change as #3062 (aeroway=rc_runway), similar to how regular runways are tagged. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Aeroway=Aerodrome Modifier Tags?
On Sat, 2010-06-12 at 16:47 -0400, Zeke Farwell wrote: Hi everyone, You may or may not know that currently in OSM there is only one [rendered] tag to describe the many different types of places where planes can take off and land (aeroway=aerodrome). I'm trying to figure out how we can tag tiny airstrips and gigantic international airports differently so that renders can decide to show important aerodromes at high zoom levels and tiny, unimportant ones only at low zoom levels. Here are some tag ideas I'm toying with. These would all be modifiers for aeroway=aerodrome: aerodrome=airport(large aerodrome. many buildings. commercial flights. international flights) aerodrome=airfield(smaller aerodrome. few buildings) aerodrome=airstrip(tiny aerodrome. basically just a runway, often just a grass one) aerodrome=water (a place where seaplanes take off and land in the water. same rendering importance as airstrip) Please have a look at the Airports:Talk page on the wiki if you are interested in this subject. I've also posted this there. Zeke Burlington, VT, USA While you're working on these tags you should add ones for personal airstrips and ones for RC aircraft. There are a few of each around here. The personal airstrips would be (mostly) where someone takes off and lands in their ultralight. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Aeroway=Aerodrome Modifier Tags?
On Sat, 2010-06-12 at 17:19 -0400, Zeke Farwell wrote: Would something like this work, Val? Personal Airstrip: aeroway=aerodrome aerodrome=airstrip access=private RC Airstrip: aeroway=aerodrome aerodrome=rc_airstrip Another possibility for RC Airstrip: aeroway=aerodrome aerodrome=airstrip aircraft_type=radio_controlled I know we're not supposed to tag for the renderer, but I tried tagging a RC strip this way. It comes out VERY wide and very short. I ended up tagging it as a residential street so that it would look reasonable. On the ground it is about that wide anyway. The ultralight airstrips that I've come across aren't much longer, but I haven't tried tagging any of them. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Changeset to revert (or defend
On Tue, 2010-05-25 at 08:33 -0500, Lord-Castillo, Brett wrote: So, the real argument here is what is a bridge and what is a tunnel? Many people considered depressed highways to be tunnels rather than the roads over them to be bridges. I saw USGS topos mentioned earlier. Not all manmade cuts are reflected in topo lines. Manmade cuts that are structures are not considered bare earth and are left out. But then you get to the weird idea of are the sides of the depressed highway vertical concrete or sloped ground? and other such criteria. --Brett What I used to distinguish a bridge from a tunnel is to ask, Is it a span or a pipe? A pipe puts (or leaves) the support structure around the tunnel. A span puts the support structure under the bridge. There will be some places where this becomes ambiguous, but I haven't found any in my area. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Address Lookup
On Wed, 2010-05-19 at 08:54 -0500, Lord-Castillo, Brett wrote: If someone were to use OSM for dispatching, dispatching software generally requires a destination address to be associated with a corresponding street in order to dispatch to an address point (as opposed to dispatching to an interpolated street geocode). That would be one reason for associating objects with the streets they are on. It is also useful for non-USPS situs addresses (for example, parcel lot addresses for office buildings or condos). Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400 Fax: 314-628-5508 Direct: 314-628-5407 -Original Message- Date: Tue, 18 May 2010 23:00:45 -0400 From: David ``Smith'' vidthe...@gmail.com Subject: Re: [Talk-us] Street Naming Conventions To: talk-us@openstreetmap.org Message-ID: aanlktinvugzsb2fsxicwduebb6ip7wdk7smi1o-2p...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Tue, May 18, 2010 at 10:39 AM, Phil! Gold phi...@pobox.com wrote: * David ``Smith'' vidthe...@gmail.com [2010-05-14 23:58 -0400]: 5) The value of addr:street=* should contain the abbreviated form of the street name according to USPS standards, regardless of the way the street name is signed. The point of addr:street is to associate the address to a particular road, so its value needs to match the name of the road. ?(There's also the associatedStreet relation, but more people use the addr:street tag.) As Frederik already asserted, that's incorrect. But if for some reason you need to associate an object with a street without using an AssociatedStreet relation, you could always give the street its own addr:street tag with the same value as all of the objects along it, which uses the same USPS-based abbreviation. But I'm not sure what is accomplished by associating objects with the street they're on. (As far as I know, the original point of the associatedStreet relation was to automatically imply addr:street values for all of the objects by using the street's name or addr:street value. What you said is kind of backwards from that.) The goal of Open Street Map is to eventually do everything that commercial map products do. This would include address lookup. I've looked around and the way of associating addresses with streets doesn't seem to work very well. The simplest way (requiring the fewest nodes) still requires a lot of work. For instance, for an example I've picked a street around my area: West 2550 North. This is just the ways needed for the streets themselves. (I didn't include the names on the cross streets because they don't matter for this example.) AB C D E || | | | || | | | +--+-+--+---+---+---+---+-- || | | | | || | | | | FG H From what I understand, next to each place where another street intersects this street I will have to create another node (on each side of the street) tagged with addr:street and addr:housenumber. I will need to connect the nodes on each side of the street with a relation. The relation I will need to tag with addr:interpolation and even/odd, as appropriate. This makes the simple street above now look like this: AB C D E || | | | || | | | **--*---*---*---*---*-* +--+-+--+---+---+---+---+-- **--*---*---*---*---*-* || | | | | || | | | | FG H This is a LOT of data to manually add. Is there a simpler way? No, I don't have a better idea. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
This topic has been dropped without it having been resolved. We still need some way of addressing the issues summarized in http://vidthekid.info/misc/osm-abbr.html;. This can be summarized as needing to create fields for: direction prefix street name street type direction suffix This is needed for exactly the same reason that no abbreviations are supposed to be used in OSM: There is no automated way to fix the parts of a street name. For instance, here are some actual addresses which occur in this area: Number Prefix Street Name TypeSuffix 200 WestNorth Temple Street 200 EastSouth Temple Street 200 North West Temple Street 50 EastNorth Lakeview Drive 50 EastSouth Lakeview Drive 2450North EStreet 300 SouthgateDrive 4700West3300 Street South These are just samples, but others on this list have come up with other examples that demonstrate the problems with the current way of doing things. Also, in the last example given above, the Type and Suffix would be swapped, but in most written addresses the Type would be dropped. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Trail Route Relationships
I know that the current preferred method for tagging trail routes is with relationships. However, I don't know whether or not to assign names to the segments of the trails. The wiki doesn't seem to specify, at least not that I've found, so I'll ask here. Around Ogden, several cities have their own trail systems. The main trail in the foothills is called the Bonneville Shoreline Trail, along the Weber River is the Weber River Parkway, along the Ogden River is the Ogden River Parkway. Where these three trail systems make a loop around Ogden, it is called the Centennial Trail. Some parts of these trails use streets as part of the trail. Which levels should be assigned as the name for each trail segment? The rest will be used in the name for the route relationships? Once I get an answer, I'll change the trails for consistency. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] One-way Wrong-way
I was using the OSM maps on my Garmin just to test the routing. With the OSM data, it sometimes picks strange routes. However, last Saturday it picked a really strange route suggesting a dirt road next to the freeway instead of the freeway itself. Today I looked at the route, and Cloudmade made a similar strange routing decision. I found that one segment of the freeway was the wrong way. I have fixed this segment. I have also previously fixed on and off ramps that were the wrong way. Would someone write a 'bot that would go through the database and see if there are segments that have similar problems? These should be flagged and put on some list for manual checking. Actually any one-way streets that make no sense should be flagged. (Things like a one-way dead-end street.) Thanks, - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On Tue, 2010-04-27 at 10:57 -0700, am12 wrote: I'm saying that abbreviations are part of every day life, and locals know what to abbreviate and what not to. Sure, according to their local usage, which will be inconsistent with local usage in other places. What one local thinks is an obvious abbreviation usage because everyone knows it will not be obvious to a map user from elsewhere. How does commercial text-2-speech handle this? Unabbreviated, better-structured data. So, does that mean that street names like 40th Street, for instance should be expanded to Fortieth Street? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On Mon, 2010-04-26 at 16:31 -0700, Alan Mintz wrote: Good. We also need to settle on a set of component tags to make best use of the information present in those edits - particularly to separate out cardinal directions from those that are really part of the name. Can we agree for now that, with appropriate local knowledge, it will be acceptable to strip just these prefixes out of the name tag into another tag? Should I propose a set of component tags for a (hopefully quick) vote? The suffixes and root tags could then be populated at the same time (without stripping them from the name). I second you proposing this. We need to separate out the prefix, suffix and root. Though you need to remember these things when you make your proposal: http://vidthekid.info/misc/osm-abbr.html - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
First of all, I've renamed the subject to what it is really discussing.
On Wed, 2010-04-21 at 19:24 -0700, Alan Mintz wrote:
name: The pre-balrog name
name_direction_prefix: The 1-2 char cardinal direction before the root
use_name_direction_prefix: {yes|no} Yes indicates that the
name_direction_prefix should be rendered/spoken
name_root: The actual root of the name
name_direction_suffix: The 1-2 char cardinal direction after the root
name_type: {St|Ave|Blvd|etc.} Common, documented abbreviations allowed
render_name: The name to be rendered on a map (if not name for some reason)
spoken_name: The complete expanded name, ready for text-2-speech
The post-balrog name should go into spoken_name for now. The pre-balrog
name would be restored to the name tag and also split up into the name_* tags.
I think that your proposal would cover both of the address forms covered
in http://vidthekid.info/misc/osm-abbr.html;. Would this still hold
for the rest of the world, or have we decided to dump the global
thing?
- Val -
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
The traffic has calmed down. I still want some things resolved before I agree with expanding street names. 1) Be useful to the user. (This is mostly done via programs.) 2) Be simple for automated processing (programs) a) Render in an uncluttered way on the maps c) Look up addresses on maps b) Processed for GPS use 3) Be easy to enter data a) As simple as possible b) Consider above goals as higher priority If you want these things stated in a different way then look at this link: http://vidthekid.info/misc/osm-abbr.html;. Right now, by putting everything into name, we lose utility. I mean that we compromise between making it easy for users and easy for programs. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Sat, 2010-04-10 at 07:42 -0700, Richard Finegold wrote: On Sat, Apr 10, 2010 at 04:51, Alex S. m...@swavely.com wrote: Richard Finegold wrote: see http://www.openstreetmap.org/browse/node/53224246 that has West Lake Sammamish Parkway as its base name. I'm guessing that the lack of direction prefix was a data mistake. East... And no, (IMHO, anyway) it's not a data mistake, though including it on West Lk Sam Pkwy (http://www.openstreetmap.org/browse/node/53223662) *is* (again, IMHO). The 'East' and 'West' in this case are really part of the name. There are numerous similar examples at the other end of the same county. Thanks for catching my mistake; at first I was going to use 53223662 as the example, but switched. The data mistake I attempted to refer to was Val's example of W 3300 S. Alas, Val didn't specify a city, but an example I found is http://www.openstreetmap.org/browse/node/83553388; the signage might have 3300 S at the intersection with S Main Street, but it'd only be at that intersection as a cost-saving measure, and signs naming W 3300 S for the westbound branch of that intersection and E 3300 S for eastbound would be equally valid. I think that I specified Ogden, Utah somewhere, but it got lost somewhere in the conversation. The specific place that I was playing with my Garmin routable map and the OSM routable map was along 3300 S both sides of Midland Drive. (http://www.openstreetmap.org/?lat=41.20421lon=-112.02395zoom=16) The E Avenue that I've also mentioned is about a mile northeast of here, on the other side of the freeway. The E Street isn't too far away, http://www.openstreetmap.org/?lat=41.17035lon=-112.00271zoom=17 here. I think that http://vidthekid.info/misc/osm-abbr.html (that Richard brought up) provides a pretty good summary of the issues that we've got to deal with. One of the most important that I see is making sure that the core name can be separated from the rest of the entered name. How do we go about doing this? We also have to be able to do this for streets that have multiple aliases, such as Washington Blvd and 400 E that I mentioned before. What I want to have eventually is for OSM data to be able to totally replace the functionality provided by GPS maker's data. When I enter an address on my Garmin, it first wants city and state (which it assumes from my current location). Next it want the address number. Next it wants the base street name (no directional prefix, suffix or street-type). Finally, it provides a list of complete addresses (prefix, suffix and street-type) from which to select an address. I know that part of this is done by those preparing the data for the GPS, but we need to provide the capabilities to that this can be done by a program. Here's my list again, modified and now ordered with the most important stuff at the top: 1) Be useful to the user (This is mostly done by programs) 2) Be simple for automated processing a) Render in an uncluttered way on the maps c) Look up addresses on maps b) Processed for GPS use 3) Be easy to enter data a) As simple as possible b) Consider above goals as higher priority - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote: Hi, On 7 April 2010 20:12, Mike Thompson miketh...@gmail.com wrote: Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. I ran the bot ([1]) over the west half of the US [...] [...] After Oregon I ran the bot on the other states because of the comments I got from mappers on IRC. This was what prompted Val to start the discussion here. I'm going to hold off with it according to your comment. Funnily in an IRC discussion we concluded that it was nice that at least one thing had been agreed on in OSM :) After the brief but lively discussion on this topic that I started, I am almost convinced to go with the expanded (unabbreviated) names. I see these goals, in no particular order but numbered for reference: 1) Be easy to enter data 2) Be easy for automated parsing 3) Be rendered in an uncluttered way on the maps These goals and the discussions so far have brought up some further issues for discussion. These are not all OSM issues may be issues for OSM consumers. 1) Are these even good goals to work towards? 2) An issue that I brought up with Andrzej in email, the bot has expanded E Ave (in Ogden, Utah) to East Avenue when this is a range of avenues from A - H. There is another local instance (in Riverdale, Utah) that the bot hasn't yet expanded where streets are named A - K. The bot could leave such instances and flag them for manual review. 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? 4) Should the issue of making it easy to enter expanded street names be pushed off onto the data entry programs? 5) Should suggestions be given to renderers to use the USPS abbreviations? This brings up my previous example of South A Avenue burying the important part of the street name. a) Should we develop our own guidelines for abbreviations (as brought up by someone else)? 6) Should the direction prefix even be part of the street name since it (mostly) isn't on the sign? a) Commercial maps provide it as (for example) W 3300 S. However, I was using the OSM and Garmin routable maps on my GPS today and noticed that the Garmin maps show 3300 S (not 3300 South) for a street name. Should this be an issue that is pushed off onto the program that generates routable maps (with suggestions from OSM how to process the data)? b) I have used the alternate names (name, name_1, name_2, etc.) for alternates which would include expansions of the abbreviations. Should we establish a standard for how these are used and their order? For instance, north of 200 North, Washington Blvd is also 400 East and State Route 235 (though I know that routes are now tagged by relations). - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Thu, 2010-04-08 at 12:23 -0400, Richard Welty wrote: i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. While I didn't like what the bot was doing (at the time), I don't thing rampage is the correct word to use. That implies malice, which wasn't what was attempted. However, it did have a beneficial side effect: this topic. ;-) - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Thu, 2010-04-08 at 23:43 -0400, Dale Puch wrote: With regards to E Ave Check for a base name if all is matched. If nothing is left, leave the name alone. I'm not sure what you asking about with Southbay vs South bay Are you trying to figure out if the bot should add or remove the space? If so, leave that for manual edits. Dale Dale, For E Ave, I don't know if you're addressing me or the bot's master (Andrew), but I'll answer for me. The tiger:name_base is actually E (the quotes are used as delimiters). Tonight, I was actually in the area and I looked at several of the street signs, but not E Ave. The actual signs of the two that I noted are A Ave and B Ave, though I noted E Ave when I originally surveyed the area. It should be expanded to E Avenue, but no more. The Southbay vs South Bay is something that someone else mentioned in this discussion. He said that his actual street name is Southbay Drive, but some mail arrives with the address of South Bay Drive (which is incorrect). This is something else that we need to avoid. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Street Naming Conventions
The Editing Standards and Conventions (http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions;) page says: In the name tag, enter the full name as it appears on the street name signs. [...] Do not abbreviate words. Some sample ACTUAL street signs around here say 14th Street, 1400 South, A Ave, Bee Ct, Cheyenne Dr. If we expand the abbreviations, this still doesn't carry the other directional identifier. (e.g.: W 1400 S) However, if the directional identifer is added and expanded then A Ave becomes South A Avenue which really buries the most important part of the street name A. (Two areas I've mapped have single-letter street names, one A-H Ave and the other A-K Street.) Even expanding the local convention (for instance) of S 1000 E should be expanded to South 1000 East Street (according to the wiki), again burying the most important part. Using USPS abbreviations is the convention used by all commercial online mapping providers that I've seen. (i.e.: maps.google.com, maps.yahoo.com, www.bing.com/maps ) I think that OSM should adopt the same convention. What do people think? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
