Re: [Talk-us] State ref tags on ways: Use of unique ISO/ANSI/USPS 2-letter state codes in RELATIONS as well as WAYS?
On Wed, Mar 12, 2014 at 6:34 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: On 16:04 2014-03-11, Peter Davies wrote: I thought I would make my proposal stand out a bit more by adding words to the title. :-O There are some weird things, like Nebraska's state law that requires NDOR to have a state road link to every community of a 100 people or more. I've changed some Link 80F ref tags to NE 80F Link and Spur nnX tags to NE nnX Spur without having time to do the whole state. AZ has its Loop 101 and Loop 202 freeways for which I would advocate refs AZ Loop 101 and AZ Loop 202. Texas also has many weird qualifiers on minor state routes but as I've never contracted there for 511 I'm not totally familiar with them. Peter As others have mentioned, we already use unique two-letter state abbreviations as part of relations' network tags. I created a bunch of network=US:OH:LOG:Zane route relations last night (Zane Twp., Logan Co.) and I'm intent on keeping the ways' ref tags a bit shorter than that. For all I know, Ohio's DOT could be an outlier, but they use SR 123 notation exclusively, including on variable message signs [1] and at their traffic website OHGO [2]. I've firmly of the opinion that ways' ref tags should not always be considered uniquely identifiable. For something like a traffic reporting application, ways' ref tags should be at most a fallback in the absence of route relations. On the other hand, less qualified refs may be more useful in narrated directions: Turn left at Link 80F would be preferable to Turn left at NE 80F Link. Why bother telling me what state I'm in as I approach the intersection? It's unnecessary to cram more qualifiers and a rigid syntax into a single field when our data model has much more appropriate facilities for this information. Insisting on uniformity on ways' ref tags only invites data consumers to make poor assumptions. There's a CA 50 in Cantabria, Spain, after all. [3] I've been saying this for years, but perhaps not quite as clearly. That said, I don't find a particularly strong case for leaving bare numbers in ways' ref tags. How about when the actual route marker is generic? A few states here and there use the plain circle for their state routes. A few New England states use a plain square or rectangle. To me this is a clear parallel with Europe, which tends to use rectangles, and whatever's written in the rectangle gets put in the ref tag as-is. I wouldn't object to this practice, as long as it's only used for states where the official route marker is a plain circle/oval or square/rectangle with no clear state identifier on it. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD Imports
Past NHD imports have made vast multipolygons which can be difficult to interpret without a view of the whole thing. This made particular problems for tiles@home/osmarender, which tried to render the multipolygons without loading their out-of-area members, leading to water-land inversion in a lot of places. Editing these multipolygons may be error-prone too, though need for such editing should be rare. If you can somehow limit the size of the multipolygons, this issue can probably be mitigated. On Oct 27, 2012 7:29 PM, Clifford Snow cliff...@snowandsnow.us wrote: I saw bsupnik's wiki page, http://wiki.openstreetmap.org/wiki/User:Bsupnik, on importing of NHD into OSM. I'm working on National Parks in Washington State. After spending countless hours tracing in streams and rivers into OSM, I've finally decided that importing makes more sense. I'm wondering what the consensus was on using NHD in OSM? The data can be downloaded as shapefiles from the USGS website. With Paul Norman's ogr2osm script and translation tables, the data looks like to could be imported into OSM. In the areas I'm focusing on, it would need to be done almost stream by stream since some of the data already exists. And doing it in small batches allows for easy alignment with a Bing image. (These are areas that a survey is nearly impossible due to the large amount of difficult terrain involved.) One of the advantages to using the NHD data over topo maps is getting the correct names on the streams. The existing topo maps make it difficult to determine named streams from un-named ones. Before I bring this up on the imports list, I thought I'd ask the US community about their opinion about importing the data. -- Clifford ___ 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] What is the status of the Toolbox?
The toolbox isn't entirely necessary if you know the keyboard shortcuts for its buttons, and I found those easily enough by clicking help. Use enhanced stylesheet to see which direction a way flows. The banner at the bottom has some issues. Helpful for new and maybe intermediate users, but i'd like the option to turn it off. Also, it's an *editable* text field, which frequently captures keystokes that were meant for the tag pane. That's annoying, but not a blocker once you figure out what's going on. Sorry if I'm duplicating information from the trac ticket... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Consensus on SR for state route versus state abbreviation?
Concerning ref tags on ways, I don't think there's a need to impose nationwide consistency. I also don't think it's worth even adhering to a strict machine-parseable syntax (particularly dealing with overlaps) since that kind of information is much better organized in relations. That said, here are my ideal guidelines for formatting ref tags on single state highways: 1) If there is one clearly-popular abbreviation, such as M-xx in Michigan or possibly K-xx in Kansas, use it. 2) If a state has primary and secondary state routes, or numerous classes of state routes like Texas, the prefix should indicate the route class. 3) If a state allows its state routes to have the same number as a US or Interstate route in that state, a state-specific prefix (postal abbreviation or other as described above) should be used. 4) If a state is large (such that most places aren't near the borders) a generic prefix like SR or SH or STH (depending on preferred local terminology) may be used, notwithstanding guideline 3. 5) If a state's state route markers are generic (circle/oval or box) and don't specifically identify the state, a generic prefix or no prefix may be used, notwithstanding guideline 3. 6) Consistency within a state, or within broad regions of larger states, is probably still of value. A format should be chosen by consensus of mappers familiar with the state or region in question. 6a) As a mapper familiar with Ohio, I prefer SR xx, but would be amenable to OH xx or OH-xx. Slightly off-topic: A) I strongly prefer I-xx and not I xx (and definitely not Ixx) for Interstates. The hyphen enhances readability and reduces the chance of the I being mistaken for a 1. The reasons I've heard in support of I xx are: to match US and state routes (why does it have to?); to match European route designations (making apples look like oranges); because all the Interstates are already tagged as I xx (due to a few editors who value consistency a little too highly, plus I see that as a circular argument); changing it breaks renderers (nearly all renderers just pass a way's ref tag directly to the output, and those that do try to parse it can and should normalize tagging variations as a preprocessing step anyway). On the other hand, I would't argue against the format IH xx in Texas because most Texans I've encountered write it that way. B) When routes overlap, there is no right way to format the way's ref tag. I don't think any active renderers attempt to separate it into multiple values; considering this information can be stored with much better structure in relations, I don't think any programmer wants to bother with trying to parse a ref string anyway. That just leaves humans who will ever read it, and we can optimize for that. Brevity may be more important than technical correctness when a human is reading. Local understanding of routes' relative importance may play a role. The following equations demonstrate options to represent overlapping routes in a way's ref tag that seem perfectly sensible to me: US 1 + US 9 = US 1-9 I-70 + I-71 = I-70/71 US 40 + US 62 + OH 16 = US 40-62 I-74 + I-465 + (?) = I-465 I-95 + MA 128 = I-95/128 US 68 + OH 15 = OH 15 These little white lies are close enough to match the line on the map to the road on the planet. (Every good map has to lie in some way to convey information effectively.) If someone really wants to know which routes follow a particular way, they should examine the relation(s) that contain it. If a mapper really wants to make sure the correct, official truth is represented in the database, they should make sure all relevant route relations exist and are correct. Trying to squeeze all that information into a single string with a rigid syntax is optimizing for a use case that essentially doesn't exist. On Sep 12, 2012 8:59 PM, Charlotte Wolter techl...@techlady.com wrote: Hello all, ****Was there ever consensus on whether to use SR (or some variation on that) for state highways versus an abbreviation of the state name (CA or NY). I remember that there was discussion, but I don't remember if there was consensus. ****Thanks. Charlotte ** ** Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady *The Four Internet Freedoms* Freedom to visit any site on the Internet Freedom to access any content or service that is not illegal Freedom to attach any device that does not interfere with the network Freedom to know all the terms of a service, particularly any that would affect the first three freedoms. ___ 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] Consensus on SR for state route versus state abbreviation?
On Sep 13, 2012 11:51 AM, Charlotte Wolter techl...@techlady.com wrote: David, I agree with much of what you said. However, I'm not sure why the size of a state should make a difference in what abbreviation is used. Large or small, shouldn't the state abbreviation be consistent? In most parts of a big state, one is surrounded by that state and no others, so state route is unambiguous. In a small state with many neighbors, there are always other states nearby, so disambiguation may be called for. Anyway, this particular guideline wasn't meant to carry a lot of weight. Also, in the B section, where you suggest US 1 plus US 9 could be abbreviated as US 1-9, I think that could be misleading. It is common to use a hyphen between numbers, such as 1-9, to signify 1 through 9. That's not what you meant. I've seen photos of single US route markers that literally say 1-9 in the interior. I have also seen people refer to combined US routes in this way. And to split hairs, a range of numbers should be written with an en dash, not a hyphen. And the use of a slash would seem OK if the prefix always is there, the I or whatever state prefix applies. For example I 70/I 71 or I 95/MA 128. Otherwise, I think, there is potential for confusion. Confusion because someone might read Interstate 128 when it's a state route? I'm sure that mistake is not new, and it still doesn't really interfere with a human matching the map to reality. I value brevity when writing refs for human consumption. In the context of agging ways, I assume the ref value is displayed unmodified to a human (if at all), so I choose to optimize for humans. At any rate, I hope we can come to some kind of agreement on what to do about overlapping routes. Now we use semicolons to separate overlaping routes, but Potlatch 2 always flags those as incorrect. I corrected a bunch of those before someone told me that it's just a problem in Potlatch 2. So, it would be great if there were some clarity on that. Anyone? The semicolon method is, in my opinion, just as valid for overlaps as the examples I provided; it's just not optimized for humans. Potlatch doesn't actually flag it as an error, but it thinks it might need to be checked (as if two different values were combined when ways were joined, and maybe only one value should apply). I think it just needs to be tweaked so mappers interpret it as a warning that can be OK as-is, and not an outright error. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remap-a-tron observation
One thing that would have made RemapATron's existence difficult before the redaction I think is predicting which ways would be deleted entirely. As I recall, there were various remapping tools which flagged dirty objects with slightly different criteria. I think it was even said a few times we'll have to wait for the bot to run to know for sure. RemapATron, post-redaction, doesn't need to replicate the redaction bot's deletion criteria -- it only needs to work from a fixed list of deleted objects. If we sent this tool into the past, it would need to be joined with some prediction code to be useable, and then not as reliable (unless we also sent back the deleted objects list, but that could create paradoxes). Sorry if my hypothetical time travel argument seems silly... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US-Canadian border
On Aug 22, 2012 10:23 AM, Metcalf, Calvin (DOT) calvin.metc...@state.ma.us wrote: Ah that makes more sense, but not sure how it explains http://www.openstreetmap.org/?lat=44.81868lon=-66.91419zoom=15layers=M What happened to the data overlay on the slippy map? That might make analysis of situations like this easier without having to fire up an editor… ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] non-round roundabouts
Seems to me the simplest solution would be to map the two roundabouts as one peanut-shaped roundabout: narrow, but not self-intersecting, in the middle. On Aug 7, 2012 12:39 AM, Dion Dock dion_d...@comcast.net wrote: Maybe you've seen this before, but I haven't. Here are some roundabouts that are teardrop shaped; the intersection somewhat resembles a dumbbell. Is there supposed to be a no left turn restriction? Are these even roundabouts? http://www.openstreetmap.org/?lat=45.92721lon=-122.75631zoom=16layers=M -Dion ___ 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] Discardable TIGER tags
Wasn't someone working on importing address data from TIGER? I was under the impression that may have depended on tiger:tlid tags on objects already in OSM, but wasn't sure… On Jul 30, 2012 1:50 AM, Alan grunthos...@yahoo.com wrote: On Sun, 2012-07-29 at 16:21 -0500, Toby Murray wrote: tiger:tlid - there seems to be support for removing it although I do recall someone opposing it strongly in the past as Anthony mentioned. In theory it lets you link back to a specific TIGER object. In practice it seems minimally useful with way splitting/merging and a fairly high degree of certainty that an automated TIGER 2011+ reimport where this could actually be used is probably not going to happen I think removing it is fine for any changed way, for the reasons everyone else has mentioned. I oppose removing it for ways that are unchanged (which I understand is not the current proposal for JOSM; I'm just stating for the record). I still think it is valuable to leave ourselves any options for synchronization in the future. While an automated TIGER re-import isn't likely to happen, the tlid could be useful in the mystical grand conflation tools that people have proposed/discussed/drooled over. - Alan ___ 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] Discardable TIGER tags
Personally, I think there should be a tag to differentiate between a one-way road and half of a divided road; yes, a human can look at the map and make that determination instantly, but a computer requires some advanced analysis. (I can imagine some extra-nice rendering could benefit from this information…) Though I don't think such a tag belongs in tiger: namespace, the presence of tiger:separated is a half-decent hint for now. On the other hand, tiger:separated=no can go. The only use case I can imagine for keeping tiger:cfcc is if one is frustrated at the inconsistent application of different highway values, and would rather render by CFCC instead. However, it would make a lot more sense just to render directly from the most recent TIGER data in that case. To conclude, tiger:cfcc can go. PS I find it very annoying that replies don't go back to the list by default ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: Post bot cleanup
I've been having a bit of fun remapping unclean areas based on cleanmap and remapping after the bot. It's a bit like the initial TIGER cleanup, but this time I feel extra pride at achieving even higher quality than in that effort years ago. (More experience, better tools, more familiarity with tools, better imagery, etc) I'll admit Columbus isn't as hard-hit as Los Angeles, but having the right attutude might help cleaning up SoCal seem less painful. And if you could use another armchair mapper in the effort, I'll try to bring my optimism with me. On Jul 19, 2012 9:21 PM, Paul Norman penor...@mac.com wrote: From: Toby Murray [mailto:toby.mur...@gmail.com] Subject: Re: [Talk-us] Fwd: Re: Post bot cleanup And this time to the list... (cures you, lack of reply-to!) On Thu, Jul 19, 2012 at 11:16 AM, the Old Topo Depot oldto...@novacell.com wrote: Toby's post yesterday using the modified live edit bot osmZmiany seems a good way to help focus on areas. Toby, do you think it possible to serialize the state of the edits as you displayed yesterday so that they could be used as a zoomable reference to areas potentially needing review ? Ehh... not sure OSMZmiany is the best tool for this. Once you get a lot of nodes loaded in, it takes up a few hundred MB of RAM and performs like crap. Like 5 seconds to zoom/pan. However I do have an idea or two to make something that would work better. I will have to tinker with it tonight and see if it is practical. I can build a .osc file that represents all the bot changes to a given square (e.g. LA) It'll take a bit of coding so I might not get it done today, but it shouldn't be too hard. I'm also wondering if a routing regression suite exists anywhere that could be used to help identify broken interstates and other major ways, as the tagging changes and 2 node bridges that were likely deleted will take time to identify. There was something like this back when the TIGER import was new to help people connect major highways across county lines. Does anyone know the technical details or if it would be practical to bring back? It is documented here: http://wiki.openstreetmap.org/wiki/TIGER_fixup/250_cities/routing_grid I think it's practical, I've given some thought to doing this. Maybe query one of the routing services to build it. ___ 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] Highway Shield Rendering
I think I would prefer horizontally arranged shields regardless of way direction. I think a variety of tagging schemes should be condensed into a unified scheme by data preprocessing, rather than handled by an overly-complex rendering stylesheet. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] FYI - user going around changing highway refs just to put in the - and /
On Sun, May 29, 2011 at 4:08 AM, James Mast rickmastfa...@hotmail.comwrote: I just happened to notice this guy tonight was going around and editing the ref tags on highways in the US just to replace the space and put in the hyphen. There's actually a sensible reason for this, at least for Interstate highways: http://mutcd.fhwa.dot.gov/htm/2009/part2/part2a.htm Manual on Uniform Traffic Control Devices, Section 2A.13, guidance paragraph 9: When an Interstate route is displayed in text form instead of using the route shield, a hyphen should be used for clarity, such as I-50. Of course, this applies to road signs and not maps, but I still count this as precedence. Renderers should ideally tolerate ref tags of the form I-50. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Feature Proposal - RFC - Directional Prefix Suffix Indication
. PS: I'm seriously considering doing some major work with addresses around Columbus. As long as it's taking to make a satisfactory TIGER address import bot, I might as well just sit down with Potlatch and ArcExplorer's Identify tool to manually add address interpolation ways with help from Yahoo! imagery and my familiarity with the Franklin County address grid. I can also conduct in-person surveys and verification along key roads. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Kansas extract
On Sat, Jul 3, 2010 at 5:06 AM, Toby Murray toby.mur...@gmail.com wrote: I just downloaded the Kansas extract from cloudmade: http://downloads.cloudmade.com/north_america/united_states/kansas After rendering I noticed that the northern border was missing. Looking at it some more, the extract seems to be cut off about a half mile too far south. The cutoff for the other 3 borders looks to be about a half mile or so outside of the border which is fine, it is just the northern border that is off. I suppose the other option is that the extract is correct and the state boundary is off in OSM... Can anyone confirm either of these theories? Neither is correct. At least, not with absolute accuracy. But the state boundaries in OSM come from TIGER, and usually are pretty darn close — certainly better than a half-mile error. CloudMade has been doing these extracts since before OSM imported state boundaries from TIGER. (Before that, state boundaries could be inferred by county boundaries, which had been imported from USGS. That particular boundary source can at times be a half mile off...) I actually don't know where CloudMade gets its state boundary polygons for the purposes of data extracts. It's probably not a very detailed polygon, anyway. Here's a suggestion for CloudMade: When creating these boundary extracts, use a generous state boundary polygon that gets an extra margin all around the state by a few miles. Then, look for the actual state boundary multipolygon in that data. If it's a closed figure with no errors, then use that to further trim the dataset. (If not, optionally, use the last error-free version of the state boundary multipolygon from previous extracts.) Since these are only done once a week, this shouldn't be too huge a processing load. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Trailheads
On Sat, Jul 3, 2010 at 8:45 AM, Greg Troxel g...@ir.bbn.com wrote: I've been thinking about this question for a few days. Maybe the only way to distinguish a trailhead is that it has been designated as this by some trail authority. For instance, the Ogden River Parkway (http://weberpathways.org/trails_display.asp?ID=30 ) crosses several streets but only certain places are designated trailheads. On the West Haven Trail (http://weberpathways.org/trails_display.asp?ID=32 ) the trailhead is located where there is public parking and a paved trail (not a sidewalk) all of the way to the Weber River Parkway. I am sympathetic to Sam's position that one should simply represent what's there (sign boards, parking), and I agree with it. But we should also be able to represent official designations of trailheadedness, or the equivalent judgement of locals. I suppose, when adding the informational sign (or some other mappable feature) at the trailhead to the trail's route relation, you could give it a role of trailhead. That semantically describes the situation, though it has the disadvantage that simple POI search algorithms won't be able to catch it. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Route Relation Nitpicking
On Tue, Jun 15, 2010 at 1:45 PM, Phil! Gold phi...@pobox.com wrote: I started experimenting with rendering route shields the other day, and I figured it would be nice to use route relations as my source. The wiki says that the ref= tag on a relation should not include the network identifier[0], which makes sense, since there's a separate network tag. When I looked, though, I found a lot of relations putting it in (as well as other things, sometimes--US 1 in Maryland had a ref of US 1 (DC/MD/PA), which I moved to the name= tag (which might still be incorrect, but at least it's less incorrect)). How consistent are the US route relations? Should the relations with network information in the ref= tags be updated, or should the wiki be changed to document current behavior? In Ohio: * Route relation tagging consistently is as described by the wiki (with the exception of no clear agreement between network=US and network=US:US) * Interstate route relations offer nearly complete coverage * US route coverage is around half complete * State route coverage has a good start So, yeah, I agree with the wiki, and I see no reason to abandon the practice described therein. And to say that route relations aren't used anywhere so it doesn't matter is highly inaccurate for the part of the planet with which I'm familiar. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Census designated place boundaries: should we care about them?
Oops, forgot to fix the to field... On Thu, Jun 10, 2010 at 11:37 AM, Nathan Edgars II nerou...@gmail.com wrote: Usually a CDP is simply an arbitrary area drawn by the Census Bureau for statistical purposes. Does it sound reasonable that these should at least not be treated as ordinary boundaries, if not (carefully) deleted altogether where not based on actual administrative boundaries? In Ohio, they're rather insignificant. They have some value as placenames, but their exact boundaries are fairly meaningless. The standard procedure for dealing with Ohio's CDPs is to remove tagging pertaining to administrative boundaries, both on the relation, and on the member ways (unless they are also part of real administrative boundaries, of course). The CDP then remains as just a place=locality. I wonder how many of Ohio's CDPs will get new boundaries with the 2010 census. I've always been irked at how the Lake Darby CDP so poorly matches the actual extent of residential development... -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Uploading all Post Office Drop Box locations in the US
On Thu, Jun 10, 2010 at 2:37 PM, Kirk Ireson palmerstat...@gmail.com wrote: released under the Freedom of Information Act. There are 20 Excel files ranging from 14,000 to 65,000 lines in length each and it looks like they do have all the locations. I thought it would be a good project for me to extract/clean up the data and geocode it for upload (only addresses are given in the files) and so would like to first seek feedback from the community before proceeding especially with regards to licensing, tagging and geocoding. GEOCODING: -Can anyone recommend a geocoding service (that is, translating an address to latitude/longitude) preferably free or very cheap. Only one I've found is http://geocoder.us (since I can't use Yahoo's or Google's without using them on one of their maps), but I can only send one request per 15 seconds and so it will take weeks (since I don't want to pay hundreds of dollars). Am I the only one who sees a problem with this? I'm pretty sure all of these geocoding services, free or otherwise, are only free beer and not compatible with OSM's open license, unless the geocoding data itself is open-license or public domain (such as TIGER). Wouldn't use of a commercial geocoding service to import POIs taint the OSM data? Maybe not if the original address were not present in the tagging but still... -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Reply-to field in list messages
Why doesn't the talk-us list use the reply-to field so that simple replies go to the list, not just the original poster? The newbies list does that. Every other e-mail list I've ever been on does that. So why not this one? I know I can hit reply-all instead of reply but that still requires me to remember that the list doesn't work normally. Besides, that still puts the OP in the to field, and just adds talk-us as a CC. That's not semantically correct most of the time. How about a poll of list members? How many of you would prefer to reply directly to a list poster, more often than you'd like to send the reply to the whole list? I suspect that the default intention for most list members is to send replies to the whole list. (I could be wrong, hence the poll.) If this is true, then the list settings really should be changed, so that messages are delivered with a reply-to: talk...@... line in the header. It would save nearly everybody from occasional frustration and frequent minor annoyance. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging of county roads
On Thu, May 27, 2010 at 3:58 AM, Apollinaris Schoell ascho...@gmail.com wrote: in general the better tag structure and very common approach is to define a namespace like this network=Orange network:state=CA (or california to make it human readable) network:country=US, but this is probably overkill this is much easier to understand for humans and it is easier to parse by applications. packing all info into a single tag value by some cryptic codes is tagging for a specific application. I don't think it matters if it's cryptic or not. If applications do anything with these, it will probably be matched against a lookup table rather than parsed into components. For example, if an application does anything special with county highways in Orange County, CA, it will notice US:CA:Orange (or whatever) and match that exactly. Or, if it only cares that it's a county route, it will notice that the network matches the pattern US:*:* (as nearly all county route networks are currently tagged in practice) and identify the route however the application is meant to identify county routes to the user. Or, most probably of all, the application doesn't care at all about county routes, won't find any match to US:CA:Orange in its lookup tables, and ignore the relation altogether. osm principle is to use human readable tags and values. it's a system designed for mappers not for GIS experts or programmers. the hardcore geeks can understand cryptic codes but normal people can't. if we want to attract more mappers this is crucial. if we start to make osm a pure geek project it will not survive. The only humans who are going to see these particular tags are mappers, since no sane application for non-editors should expose these tags directly. And mappers who are doing anything with route relations should have done some reading on the wiki about it, otherwise they wouldn't know what the heck they're doing anyway. Once they see that US routes are network=US or =US:US, state routes are US:CA, etcetera, the meaning of US:CA:Orange should be obvious. And ideally, anyone doing mapping at this level would be coordinating with other Calfornia mappers via the wiki, which should have California-relevant county-road tagging conventions documented, assuming agreement has been reached. Or they'd ask for specifics on this email list. Which brings us back to the top of the thread... -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging of county roads
On Thu, May 27, 2010 at 9:08 PM, CrystalWalrein closed...@hotmail.com wrote: The 'parentheses' idea for tagging county roads would be mine. I used it in New Jersey, and then I applied it to county highways when doing fixup in Florida. For some strange reason, NE2 liked my system so much that he used it to tag county roads wherever he edited (including the whole of Florida) after that. So that's what those are? I always thought they were state routes or something. That would make sense, considering NJ's state route markers are just circles, and a number in parentheses looks similar to a number in a circle. (Read: that practice is possibly misleading and probably a bad idea.) So anyway, it's been a good decade since I've been through NJ. How are county route numbers signed there? -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ 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, May 25, 2010 at 3:02 AM, Nathan Edgars II nerou...@gmail.com wrote: We don't dispute the facts. (Taking the South Innerbelt example) the freeway is in a shallow valley/cutting, with ramps between the freeway and its frontage roads, and cross streets intersecting the frontage roads and passing over the freeway. Those aren't frontage roads. They're city streets which predate the freeway, which have been converted to one-way in places, as a convenience to the ramps. And a couple of the entrances do not come from these parallel city streets (those mistaken for frontage roads) but directly from north-south streets. Also, the whole situation is going to change over the next 10 years as major improvements are made. The only dispute is about tagging: whether it's appropriate to use layer=-1 for that. Of course, if the freeway is layer=-1, a drainpipe that passes under the freeway would need layer=-2. That wouldn't be hard to do, if the drainpipe could be considered verifiable... And a landuse polygon would need layer=-1 only where the freeway is such, and layer=0 on both sides, or otherwise, if continuous, it would be referring to land on a structure above the freeway or land under the other streets. Landuse polygons and the like should NOT have layer tags. They are to be drawn by the renderers BELOW linear features, even if those linear features have negative layer values. Osmarender screws this up, but nobody with the necessary understanding of XSLT and how Osmarender uses it has been willing to fix the problem. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Changeset to revert (or defend?)
I have found the changes in a particular changeset to be rather unhelpful and in fact quite annoying: http://www.openstreetmap.org/browse/changeset/4363590 Belongs to: NE2 Tags: comment = Removing negative layers from ground-level features. created_by = JOSM/1.5 (3081 en) Some examples of the ground-level features that were stripped of their negative layer tags: http://www.openstreetmap.org/browse/way/26497642 A section of 8-Mile Rd in a volleyball interchange in Detroit. This is a 3-level interchange between two major city avenues, where the middle level is at ground level and in fact provides access to properties and side-streets adjacent to the interchange. Setting layer=-1 on the lowest level makes perfect sense. http://www.openstreetmap.org/browse/way/29687558 A section of the Scioto River in downtown Columbus. While technically the ground is the riverbed itself, this river is certainly lower than anything else around. Most bridges that cross it are tagged layer=0 because they are generally not higher than the rest of the streets they carry. http://www.openstreetmap.org/browse/way/29314498 A section of the South Innerbelt, also in downtown Columbus. This freeway is in a trench, easily 20 to 30 feet below the streets. Were it covered, it could legitimately be tagged as a tunnel. (Eventually, portions of it could be.) All three of these examples, and presumably the vast majority of ways in the changeset, have other features crossing over them that are tagged with layer=0. NE2 did not change those to layer=1. As far as I can tell, he didn't even check for their possible existence. I believe this changeset was done simply to satisfy some arbitrary (and not widely-accepted) restriction on use of the layer tag, putting some academic idea of correct tagging over practical realities. Would anyone like to defend these changes? Of those who would defend it, how many are willing to fix the semantic problems they caused, by increasing the layer on all of the affected bridges (and any bridges over them, and so on)? I think reverting the changeset would just be easier. Unfortunately, I'm a Windows user with no easy way to do that. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Changeset to revert (or defend?)
On Mon, May 24, 2010 at 8:55 PM, Nathan Edgars II nerou...@gmail.com wrote: I'll repeat what I told him through the OSM messaging system: I responded to those arguments already, in that same system. Rather than rapid-fire replying in two places, I'll wait to see what other people say. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Proper Consistent Spelling (was: Fast food vs. restaurant vs. cafe)
[cross-posted to talk-us and newbies; original thread on talk-us] On Mon, May 3, 2010 at 5:39 AM, Katie Filbert filbe...@gmail.com wrote: * COSI (restaurant or cafe?) What's that one? Around here, COSI (formerly an acronym, still all-caps) is a science museum. http://en.wikipedia.org/wiki/COSI_Columbus We do, however, have several locations of the restaurant Così. http://en.wikipedia.org/wiki/Cos%C3%AC_%28restaurant%29 That's a word, not an acronym. I don't know why, but it seems it's rather often written COSI. Just like how a lot of stores get a phantom 's' added on the end, or sometimes removed: Meijers, Krogers, Aldi's, Walgreen. I've seen these incorrect names in the OSM data, too. We should get the word out to new users: Make sure you know the correct name of a place when you add it to OSM. (Or, is misspelled data better than no data?) Maybe this just annoys me because I can't understand how people get these things wrong in the first place... -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Lookup
On Fri, May 21, 2010 at 12:45 AM, Val Kartchner val...@gmail.com wrote: 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. Whoa, that sounds like it might be an overstatement, or at least an exaggeration. You don't necessarily have to have an address node *every* block, but every few blocks (even one per mile) is probably going to be close enough for most uses. (At least as precise as Google's typical lookups, anyway...) You can probably just do addr:housenumber on each of those nodes. Then you connect all those nodes up with a way on each side of the street, which has the addr:interpolation tagging. (That way can have nodes along it that don't have addr:housenumber if necessary to follow the bends of the street or line of houses.) Also, those ways will probably have addr:street tags. Optionally, but perhaps ideally, those ways will be linked to the street itself using an associatedStreet relation. If the relation exists, then addr:street tags on the interpolation-ways can probably be omitted, as they can be inferred from the addr:street or name tag of the street itself. Now that doesn't sound like a terribly large amount of work to me. Of course, this is style is best for rows of houses and other small buildings that aren't already individually mapped. Large, important features should probably have their own, complete address information tagged directly. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
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.) -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another how would you...?
On Thu, May 6, 2010 at 4:40 PM, David Carmean d...@halibut.com wrote: There are a number of wildlife preservation areas established in the marshlands around the San Francisco Bay, and those which are not designated as Wilderness areas usually have pedestrian access (SF Bay Trail, etc.). In a number of locations there are dedicated observation decks built as part of a system of boardwalks over the marshes. Sometimes they have benches and even picnic tables, often they have descriptive signs, etc. Others have none of these features. How should I tag such an observation deck? They are certainly not blinds/hides (though there are hundreds of waterfowl hunting hides in the area as well). I'd go with, for the boardwalks: highway=footway bridge=yes and for the observation decks, draw a closed way around the edge tagged thusly: highway=footway bridge=yes area=yes I really can't predict how a bridge-area-footway would render in any of the slippy maps, but I think that tagging adequately describes the features. In the case of a named trail, you could add the name of the trail to the ways that form it, or better, create a route relation: type=route route=hiking network=lwn name=... I'm not sure if hiking routes are covered in the wiki, but I've seen a few relations tagged like this. I assume lwn means local walking network as a parallel to lcn meaning local cycle network. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] proposed first principles for United States road tagging
On Thu, Mar 4, 2010 at 12:38 PM, McGuire, Matthew matt.mcgu...@metc.state.mn.us wrote: I see three dimensions of road classification at play here. 1) System 2) Function 3) Observed Character System is the easy one. That is the road system(s) that that the road belongs to especially for signage, but also for road funding channels, and maintenance responsibility. And I agree that in practice, Census Feature Class Codes have been used (incorrectly) to identify the system to which a road belongs. Actually, the CFCCs are based almost entirely on the system to which a road belongs. The Census Bureau just botches it a lot because they're not a highway department. Function describes the role a road plays in a road system and the types of trips (volume and length) it supports based on travel demand and trip generation. This is what the Highway Functional Classification System is designed for. It is used by Metropolitan Planning Organizations to distribute transportation funding. This is what the highway tag should mostly be based on, because that makes the most useful map. A road's Observed Character is what kind of road it appears to be to a person on the road. For general purpose maps, using observed character to classify the roads intends to match a person expectations to what they see on the ground. Character is highly correlated with function, but is not the same. I think Observed Character is what OSM is trying to achieve with the highway tag. No, it's not! Because character is highly correlated with function, it's possible to have a close guess of function based on observed character most of the time. But if we give each highway a classification based entirely on observed character, we'll have sloppy maps that are difficult to understand. I think this because the OSM tag descriptions for highways have photos and describe how the road looks, and you cannot determine system or function from a photograph. You've got it a bit backwards. Because you cannot determine system or function from a photograph, and the people who wrote the tag descriptions were in a mindset of mapping from photos and physical appearances only, the OSM tag descriptions are based on that. I also think it is what the Census Feature Class Code definitions describe. The CFCCs, at least the ones that deal with roads, literally describe a combination of system and observed character, though it can be frequently wrong on either. They translate to things like Interstate, undivided US route, state route in tunnel, and local street. I would like to see all three dimensions. Where the OSM community is trying to go is to use the highway tag for function, the ref tag and route relations for system, and various other tags to describe physical characteristics. Right now, highway=motorway and in some places highway=trunk are tied to (or strongly imply) certain physical characteristics, but I'm working on a proposal to change that slightly. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] proposed first principles for United States road tagging
On Wed, Mar 3, 2010 at 10:45 AM, McGuire, Matthew matt.mcgu...@metc.state.mn.us wrote: The US Census Feature Class Code has descriptions of most types types of roads. This would at least tie it to an existing US standard. http://www.census.gov/geo/www/tiger/appendxe.asc This designation exists in many OSM roads tagged with TIGER:CFCC. However most roads could definitely use some refinement. We could strip the TIGER from the tag to just cfcc then refine it from there. The original TIGER import did in fact use CFCCs to determine highway class. It produced values of motorway, motorway_link, primary, secondary, and residential. We've been refining that for 3 years now. The problem is, this comes from the Census Bureau. They really don't care about a road's functional importance. There are CFCCs for many other things besides roads. And the few CFCCs assigned for road features are essentially based on whether the road is an Interstate, a US route, or a State Route, which doesn't correlate well with a road's functional classification. What's more useful is the Highway Functional Classification System. The name sounds like what we want to do. And it's from the Federal Highway Administration, so they actually care about roads. I've also put forward guidelines for translating HFCS to OSM. http://wiki.openstreetmap.org/wiki/Talk:United_States_roads_tagging#Discussion (Sort of buried in a wall of text. I should probably repost those guidelines in my userspace.) -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Please revert my epic fail changeset
I'm still having trouble figuring out how to do the things I want in JOSM. It works in some strange ways. Anyway, I started uploading a rather significant changeset before I realized that JOSM considered everything I was working on as new objects and were being uploaded as such. I nearly duplicated half the roads in Toledo. Fortunately, I realized my mistake and unplugged a network device before much of the upload was completed. Still, over 400 nodes were uploaded, all of which certainly duplicate existing nodes. A revert will be quite helpful on http://www.openstreetmap.org/browse/changeset/3854124. I was using JOSM so I could edit while being able to see the big picture (not practical in Potlatch) but it's looking like I'm not going to be able to get JOSM to actually upload anything properly now. Still, I can use my locally saved .osm file as a blueprint for Potlatch editing now. (And that will be easier when the duplicate nodes in tonight's epic fail changeset are gone.) -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] script for adding layer=1 to bridges
On Wed, Jan 27, 2010 at 9:01 AM, Bill Ricker bill.n1...@gmail.com wrote: On Wed, Jan 27, 2010 at 2:13 AM, Frederik Ramm frede...@remote.org wrote: I've noticed that a lot of bridges don't include a layer= tag. I suspect this is because they render OK in mapnik...but not so well with osmarenderer. (Consider the railroad in http://www.openstreetmap.org/?lat=33.76931lon=-84.53762zoom=17layers=0B00FTF.) I'd suggest to modify Osmarender rather than the data, then. No this is Tiger import data, the data arrived wrong and was half corrected. (much of tiger has intersecting nodes where there should be bridges. some bridge insertion went without layering), It missing all but implied layering of bridge-nature. What we can't tell without checking satellite view is whether the bridge is at grade level with the Railroad in a ditch, or if the bridge pitches up over the RR. I wouldn't put any faith in when TIGER says something is a bridge. It seems like, in the process of merging tiger lines into single ways, no consideration was given to which segments were bridges. As a result, the entire length of the street gets bridge=yes. Furthermore, this usually appears on roads with no obvious bridges (though there could be a tiny culvert somewhere along it) and not on roads that have bridges of any significant length. As far as I can tell, it could be completely random. Anyway, I have seen places where people have cleaned up freeway corridors, and neglected to tag layer on anything unless there are bridges crossing over other bridges. Mapnik renders this fine (actually that could be considered a deficiency of Mapnik in my opinion) but it looks a little goofy in Osmarender. (On the other hand, when one end of a layer=0 bridge is directly at an intersection with other layer=0 streets, Osmarender renders this beautifully and Mapnik makes it look odd.) Since some people consider the entire layer tag to be tagging for the renderer these people probably don't think it's important to add thorough layer information; instead, they add just enough to make it look decent in the renderer. I am not of that opinion. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Ohio Statewide Imagery Program
I have recently noticed that Google Earth has incorporated OSIP (Ohio Statewide Imagery Program, http://ogrip.oit.ohio.gov/ProjectsInitiatives/StatewideImagery.aspx) imagery into their historical imagery feature. (Actually, I have to wonder why it's not used more on the default/current image layer, as in many places it's newer and/or finer-resolution than that layer.) Anyway, when the OSIP imagery is visible, the attribution portion of the window does not use the copyright symbol. Just to be sure about copyright status, I called Jeff Smith today (his contact info appears on the OSIP download page) and asked about it. He said that the OSIP data is all public-domain. (I also asked him if he was aware of OSM, and he said he was, but I didn't press for more details.) Since this data is public-domain, and newer and/or sharper than the Yahoo! imagery*, I think it would be very worthwhile to investigate ways to easily use it for tracing or general reference in OSM. There seems to be a WMS service, but I couldn't get JOSM's WMS plugin to work with it. While I was able to download georeferenced TIFF files from OSIP, the PicLayer plugin didn't even support TIFF, and I had to manually align the imagery anyway. Is there a JOSM plugin that supports geolocated TIFF or MRSID files? If not, does anyone know a way to align imagery in JOSM other than fiddling with the move, scale, rotate tools until it fits existing data? I suppose I should poke the trac about adding the OSIP WMS to Potlatch. I acknowledge that using OSIP may be difficult from a programmer's standpoint, given that it uses Ohio State Plane projections (which are conics) rather than Mercator. * OSIP imagery was captured in 2006 and 2007. In central Ohio, it appears to be the newest imagery Google has. Only Mapquest has newer imagery, apparently from i-cubed. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] HI: Hawaii GIS Data
On Fri, Dec 4, 2009 at 7:47 PM, Scott Atwood scott.roy.atw...@gmail.com wrote: Offshore islets can probably be mapped via satellite imagery. It's common practice for providers of aerial/satellite imagery such as Yahoo to mask out actual coverage of oceans and large lakes with a generic ocean texture that is meant to look better than actual photographic data. So if it's small and not very close to the mainland, don't count on it showing up in the Yahoo imagery. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Marking closed bridges
I fully support keeping access=* simple, or at least, not making it more complicated than it is. Closed roads and bridges, for whatever reason*, should be tagged access=no. Of course, having additional info would be great. I suppose description=* would be best for that, as it seems that key's intention is for the value to be passed directly to the end-user. Perhaps the slippy map should render the value of description=* in parentheses next to the name on roads, POIs, and other features. Anyone who can propose a solid idea of how this should work can suggest it on the trac. Provide visuals of how it would look, you get bonus points. Figure out how to accomplish it in the Mapnik stylesheet, and then you'll *really* be a superhero. (*When something closes, make it access=no. When/if it re-opens, use whatever access tags are appropriate. However, when this happens repeatedly on the majority of roads in an area, there really should be a better way to do it. I'd settle for leaving the access tagging as representative of its usual open state, and add something like description=closed in winter along with whatever tags might be appropriate for seasonal or periodic closures.) -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin Level for Neighborhoods?
On Tue, Dec 1, 2009 at 9:37 AM, Ian Dees ian.d...@gmail.com wrote: Has anyone decided on a admin_level to tag for neighborhoods in a city? I'd like to import some neighborhood boundary data that my local municipalities have given out. Assuming these neighborhoods do indeed have some kind of administrating body, I'd use admin_level=10. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin Level for Neighborhoods?
On Thu, Dec 3, 2009 at 3:29 PM, Randy rwtnospam-new...@yahoo.com wrote: David ``Smith'' wrote: On Tue, Dec 1, 2009 at 9:37 AM, Ian Dees ian.d...@gmail.com wrote: Has anyone decided on a admin_level to tag for neighborhoods in a city? I'd like to import some neighborhood boundary data that my local municipalities have given out. Assuming these neighborhoods do indeed have some kind of administrating body, I'd use admin_level=10. Ah, but what if they do not have a administrative body. Most neighborhoods have, at most, a neighborhood association, which has no legal administrative authority, but acts as a common voice to the city for its citizens, and may perform other functions (such as, in our case, negotiating a group natural gas extraction lease for the residents, or purchasing street sign toppers that have the name of the neighborhood). Still, the boundaries of the neighborhoods are recognized by, and, in fact, usually established by the city. Then tag the area (be it a single closed way, or a multipolygon relation) with landuse=residential for primarily residential neighborhoods/subdivisions, or place=locality for mixed-use neighborhoods, and name=*. The exact boundaries of the neighborhood won't be visible on the default renderers, but they'll be there in the data for any user who wants a map with those details. And there should be a nice label in the center of the neighborhood in Mapnik (if it doesn't conflict with another label) and Osmarender/t...@h. I've done this for quite a few developments south of Hilliard, OH: http://osm.org/go/z...@kdz-. Note, there are many areas I haven't drawn/tagged yet. And there are some areas I've drawn which I know have names, but I don't know them personally. It's a work in progress. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What's causing rendering artifacts in the Southeast?
On Wed, Nov 25, 2009 at 4:13 PM, Dale Puch dale.p...@gmail.com wrote: Oops I spoke too soon. There is a relation. http://www.openstreetmap.org/browse/relation/304245 I still think this is the probable source of the problem though. Perhaps someone with more experience with relations could take a look? I believe the problem is in how ti...@home works. Just enough data (in theory) is downloaded to the client to render one tile at zoom 12 (and all the equivalent tiles at lower zoom levels) and then Osmarender renders the map tiles. I believe the problem is that when some members of a multipolygon intersect this tile and some don't, only those members are downloaded. Without also downloading every other member in the relation, most computer rendering algorithms will fail to draw the feature correctly, because only part of the polygon is loaded. On a related note: when a member of a multipolygon relation also represents a different feature (such as a road) sometimes the tags of that feature are treated as if they apply to the whole relation in Osmarender. I've been meaning to file a trac ticket about that one... -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Karlruhe Scheme addressing ways from 2009 TIGER data
On Sat, Nov 14, 2009 at 1:21 PM, Apollinaris Schoell ascho...@gmail.com wrote: forget the technical aspect for a minute and think about motivation, how a community works and all that. no one is interested to cleanup crap after a bad import. That's exactly what I've been gladly doing around Ohio for the last year. Most of the fixes I've been doing were made possible by the Yahoo! imagery, basic logic, a good understanding of American roads, casual observation of the roads as I've driven on them anyway, and the flawed TIGER data itself. This would have not been possible without the TIGER roads import. (Granted, most of the areas in which I've worked have had TIGER data with quite high positional accuracy. But that hasn't stopped me from fixing up some major roads in counties with bad positional errors.) That Geocoding with TIGER website seems to give results about as accurate as Google* or Mapquest would in my area, so I would welcome the import for central Ohio. The way I see it, the choice is between perfect data for a handful of POIs and streets scattered around Columbus, or that *plus* average data covering the entire region. (*Just because Google shows parcel boundaries doesn't mean their geocoding is that good. They still use interpolation on most streets, which can be off by few doors. Considering Google just recently switched to government data for their base map in the US, which has many of the same errors OSM imported two years ago, I wouldn't be surprised if they're already geocoding with the same TIGER data that we're talking about here.) osm is open to everyone to add, change, delete everything. there is no technical solution to have a tag like 'tiger:reviewed = no' doing anything useful if mappers don't agree on the usage of it. removing it can mean - I have seen it, it's approximately in place - I have done a survey with GPS - I have verified location on Yahoo is correct - One of the above AND name or any other attribute is correct - Everything is correct and it's as if I had entered the data myself Everyone has different thresholds when to remove such a tag, some may You have a bit of a point there. The absence of the tag can be a bit ambiguous. I once saw tiger_reviewed=aerial which probably means your third interpretation. Maybe, rather than simply removing the tag, people should change its value to something that describes to what extent the feature has been reviewed. even some official county data is badly broken. If we start to accept broken imports as better than survey osm is just a me to thing and completely useless. If anyone is interested in a me to solution it's called Google maps and has much better infrastructure than osm will ever have. they have imported all county data, park data, tiger data and refined with sattelite image tracing and street view data analysis. We can't beat them. But we can make something different with different value. the survey on ground is the strength of a community project. I'll concede that there's a me too aspect involved with trying to make OSM work for geocoding like the big names do. But that doesn't mean there aren't legitimate motivations. OSM's street map is arguably better than the big names in many places, including ones that started with a TIGER import. I'd love to tell people to use OSM rather than Google, but most casual users will dismiss it if they enter their home address and nothing comes up. And it's my firm belief that as more people use OSM as their primary map source, more people will contribute to the project. Or in another scenario, let's say a business or organization is in an area that has changed a lot recently. OSM may very well have the best map of the area, but that business can't use OSM to serve driving directions to customers unless OSM can find the customer's starting address. And in that case, close is certainly better than nothing; the customer will find his way as long as the start point is at least in the customer's neighborhood. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] 2009 TIGER Shapefiles now available
On Sat, Oct 3, 2009 at 12:33 AM, Kevin ksamp...@uga.edu wrote: Released October 1, 2009 http://www.census.gov/geo/www/tiger/tgrshp2009/tgrshp2009.html I downloaded my county and checked a few things. Some interchanges that were reconfigured in 2007-08 still appear in their old configuration. (For that matter, an interchange that was reconfigured from 1994-2003 still appears mostly in its old configuration.) But I suppose the census bureau isn't that interested in freeways. Still, most errors (even non-freeway ones) from the '07 files still persist in '09. There are a few new streets in there which weren't imported to OSM before. Some of them, I've drawn from Yahoo! imagery. Now I have names for those. Of course, I could have done my own field observation, but I have other priorities. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Lake Winnepesaki rendering issue
On Mon, Oct 12, 2009 at 7:29 PM, Andrew Sawyer assaw...@gmail.com wrote: Thanks for taking a look. On the Information Freeway site it still shows a rendering issue. I notice that the Mapnik layer was getting changes faster. I tried manually forcing a rerender via the site, but nothing substantial has changed. Should the islands not have natural:land? Does t...@h not like that tag? I am glad it doesn't appear that I made an editing error. I posted my original e-mail to the t...@h list. Hopefully someone over there can lend their expertise. Is there a lot of data behinds the scene that affects the rendering, but the typical user cant see? I notice that the parts of the map that don't render the lake right happen to be specific map tiles at zoom 12. A t...@h client will download a chunk of OSM data that's supposed to be enough information to correctly draw a zoom-12 tile and all of the closer zoom levels for the same area. This looks to me like, for a couple of tiles, the chunk of data that gets downloaded is not sufficient to correctly describe the lake. This is due to the large size of the lake and the way t...@h selects the data to be downloaded. Here's a wild guess: what if those tiles are ordered re-rendered as ocean tiles? That might work, or it might require the outer ways of the lake to be tagged natural=coastline. I have a knack for guessing how things work, but I'm still just guessing. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Salt Fork Lake rendering issue
On Mon, Oct 12, 2009 at 8:24 PM, Seth Fitzsimmons s...@mojodna.net wrote: That looks likely. Quabbin Reservoir (Western MA) is also rendering similarly: http://www.openstreetmap.org/?lat=42.3749lon=-72.2847zoom=12layers=0B00FTF Last I checked, landuse=reservoir is being rendered like natural=water even though it shouldn't be. With the MassGIS OpenSpace import, lots of landuse=reservoir polys were imported and represent protected areas, not water. seth On Mon, Oct 12, 2009 at 4:56 PM, Apollinaris Schoell ascho...@gmail.com wrote: Just a guess. landuse=reservoir overrules natural water. I don't think that's the issue. For one thing, Quabbin renders fine in Mapnik, but poorly in Osmarender. For Salt Fork Lake, the opposite is true. So they are two unrelated problems. For another thing, all of the relevant wiki pages seem to indicate that landuse=reservoir is just as valid as natural=water for this type of feature. (What kind of protected area was tagged as landuse=reservoir in the MassGIS import? Unless those areas protect water, that tagging is wrong.) Besides, I've done numerous smaller bodies of water which are both landuse=reservoir and natural=water, as multipolygons and as single ways, and this is the only one causing problems. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Reply-to?
Why is it, when I receive messages from this list, they don't come with a reply-to header so replies automatically go back to the list and not individual sender(s)? That would be helpful. The newbies list has such headers. I looked on the list subscription site and I didn't see any settings that appear to relate to this. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] CDPs and admin_level
In most states, municipal boundaries have been imported from TIGER data. In many of these states, no admin_level tag was used. That should be corrected (admin_level=8 for incorporated municipalities) but that's not the focus of this discussion. In the states where these boundaries were imported with admin_level=8, it appears that Census-Designated Places [1] were also included in the import, and treated the same as incorporated cities. (That's what happened in Ohio, anyway.) The wiki page [2] that lists what admin_level to use for various administrative units in different countries does not address Census-Designated Places. It does not say that CDPs should be admin_level=8, or any other value. I believe this should be addressed. Census-Designated Places are geographical units determined by the Census Bureau to give (arbitrary) limits to otherwise-unquantifiable, informal population centers. They do not represent any real political, governmental, or administrative unit. There are no signs posted to mark the borders of a CDP. Residents of a CDP usually are not even aware of its existence, though they are certainly aware of the informal population center it's meant to represent. They really have minimal real-world significance. You may be asking yourself, 'but how can I tell if something is a CDP or an actual city?' There are a few ways. For one thing, you could look up the locality on Wikipedia. CDP boundaries typically follow only roadway centerlines and sometimes county boundaries, whereas actual corporation limits can and usually do also follow property lines and the edge of the right-of-way on one side of roads. (More correctly, CDP boundaries don't split census blocks.) Finally, the answer may lie in the tags generated by the boundary import. For example, in Ohio, there's a tag like tiger:LSAD which always ends with CDP if the entity is a Census-Designated Place. I suggest using admin_level=9 or admin_level=10 for CDPs. If there is agreement here, then the wiki should be so clarified. (I don't think a full-blown proposal is necessary to make a minor clarification to an existing map feature, do you?) [1] http://en.wikipedia.org/wiki/Census-designated_place [2] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#admin_level -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Lake Winnepesaki rendering issue
On Mon, Oct 12, 2009 at 4:44 PM, Andrew Sawyer assaw...@gmail.com wrote: I have been experiencing what I think to be a error with the rendering of islands in Lake Winnepesaki in New Hampshire. I tried copying the tagging convention from Lake Champlain (Vermont/NY border), but it seems to render the islands incorrectly as small lakes in two of the tiles in the middle-bottom of the lake. I don't know what I am doing wrong. I have attached the link to the Information Freeware, OSM, and OSM Relation Analyzer pages for your convenience. http://informationfreeway.org/?lat=43.61625379229798lon=-71.36002480862106zoom=12layers=BF000F http://www.openstreetmap.org/?lat=43.6329746246338layers=0B00FTFlon=-71.3110542297363zoom=12 http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=63730useCache=false Some details about the tagging of the lake: There are 9 ways comprising the outer border of the lake with natural:water as the tag and belong to Relation #63730 with the role of outer and have a direction of clockwise There are 152 self-contained ways (islands) belonging to the relation with natural:land with the role of inner which as far as I know have a direction of counter-clockwise The relation is tagged with the following: name:Lake Winnepesaki natural:water type:multipolygon I don't know if I edited the lake wrong or its a rendering problem or a combination of both. Thanks, Andrew S. Sawyer http://www.facebook.com/assawyer If it is indeed tagged as you described, that sounds correct to me. I'm having a similar issue myself with Salt Fork Lake in Ohio. I think I once saw a ticket about a similar issue on the OSM trac. There it was explained that if the upload process took more than 5 minutes, (as can happen with large lakes,) it may not have been correctly represented by the minutely diffs used to update Mapnik's copy of the planet. The solution is to wait for the next planet dump, which should represent the feature correctly. So let's wait till Wednesday or so, and if our lakes still don't render right, we'll head to the trac to complain. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Lake Winnepesaki rendering issue
On Mon, Oct 12, 2009 at 4:44 PM, Andrew Sawyer assaw...@gmail.com wrote: http://informationfreeway.org/?lat=43.61625379229798lon=-71.36002480862106zoom=12layers=BF000F http://www.openstreetmap.org/?lat=43.6329746246338layers=0B00FTFlon=-71.3110542297363zoom=12 http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=63730useCache=false Oops, I should have looked at your links *before* I sent my response. As it turns out, your lake looks just fine in Mapnik, but Osmarender is having some problems. I'm pretty sure it's a rendering issue that the Osmarender or t...@h guys need to fix, because I've seen issues like this in Illinois too. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Restriction tagging
On Tue, Sep 29, 2009 at 3:17 AM, Stellan Lagerstrom lagerst...@blindsight.com wrote: It seems like a reasonable way to tag it. The only possible alternative I can see would be for the restriction to be a no_right_turn since it is the turning right onto the offramp that is restricted. That's what I'd do, but it shouldn't make a difference either way. According to the definition of the restriction relation, no_right_turn is equivalent to no_straight_on as well as no_anything_else. The to, from, and via members define what specifically is prohibited. It should be noted that most routing programs don't support restrictions, and those that do generally only support the case where via is a node. It is a concept that's difficult to incorporate into an algorithm like A*. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
