[Talk-us] East end of I-44 (Re: shields and overlaps)
> > This shot shows the road as all 4 interstates and US-40 at once. > > http://maps.google.com/?ie=UTF8&ll=38.617642,-90.181049&spn=0.00824,0.013078&z=17&layer=c&cbll=38.617746,-90.181461&panoid=etjY4kn9oqoecsdYSjoXqw&cbp=12,285.92,,0,5.98 > > (This shot is actually from during the realignment, as shown by the I-64 > > detour sign.) > > As soon as you hit the end of the bridge, the 4 Interstates start splitting > > up. > > Is there any reassurance signage for I-44 in either direction here? This > is close enough to the I-44/55 junction that the exit 40C overhead could > easily be implying that it's 'TO' I-44, like exit 1C on I-255 westbound > is signed US 50/61/67 despite not leading directly to the latter two. > > The mileposts display I-55 rather than I-44; is it MoDOT policy to > always use the lowest number (if both are the same network)? MoDOT only puts one symbol on a mile marker. Notice that the bridge actually leads most directly to I-64/US-40; all the other interstates exit, but the mile marker and reassurance signage only say I-55. I am not sure how the choice is made which Interstate to use for the reassurance signs and mile markers. The MoDOT roads on file at MSDIS say that the bridge is all four interstates. Either as a 3 Interstate + 1 highway shield or 4 Interstate + 1 highway shield, it still makes an interesting rendering problem. 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] shields and overlaps
On 6/7/2011 4:45 PM, Nathan Edgars II wrote: > On 6/7/2011 9:30 AM, Lord-Castillo, Brett wrote: > > I-64, I-70, I-55, I-44, US-40 > > AKA, the Poplar St Bridge in St Louis, MO. > > It is the only quad Interstate route in existence. I-70 will reroute in > > 2015 and it will go down to a tri > > route. > > > > It also carries the designation Historic Route 66 and has the Historic 66 > > shield on it as well. > > > > (Even weirder, I-44 ends at the Illinois state bridge halfway across the > > bridge, so the west half of the > > bridge is I-64/70/55/44 US-40 while the > > east half is only I-64/70/55 US-40 > > Unfortunately, I-44 is missing from this part of St Louis, so it is not on > > the way right now. > > http://www.openstreetmap.org/browse/way/32333977 > I-44, at least according to signage in 2008, ends at I-55. > http://www.interstate-guide.com/images044/i-044_et_04a.jpg > Yeah, that was before the I-64 project which involved realigning I-44 temporarily. At that point, the east bound ended at I-55, but the westbound started on the Poplar St Bridge. Today, the Eastbound goes all the way to the Poplar St Bridge as well, but the signs are not changed yet. This shot shows the road as all 4 interstates and US-40 at once. http://maps.google.com/?ie=UTF8&ll=38.617642,-90.181049&spn=0.00824,0.013078&z=17&layer=c&cbll=38.617746,-90.181461&panoid=etjY4kn9oqoecsdYSjoXqw&cbp=12,285.92,,0,5.98 (This shot is actually from during the realignment, as shown by the I-64 detour sign.) As soon as you hit the end of the bridge, the 4 Interstates start splitting up. 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 Message: 4 Date: Tue, 07 Jun 2011 16:45:55 -0400 From: Nathan Edgars II To: talk-us@openstreetmap.org Subject: Re: [Talk-us] shields and overlaps Message-ID: <4dee8e03.5080...@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 6/7/2011 9:30 AM, Lord-Castillo, Brett wrote: > I-64, I-70, I-55, I-44, US-40 > AKA, the Poplar St Bridge in St Louis, MO. > It is the only quad Interstate route in existence. I-70 will reroute in 2015 > and it will go down to a tri route. > > It also carries the designation Historic Route 66 and has the Historic 66 > shield on it as well. > > (Even weirder, I-44 ends at the Illinois state bridge halfway across the > bridge, so the west half of the bridge is I-64/70/55/44 US-40 while the east > half is only I-64/70/55 US-40 > Unfortunately, I-44 is missing from this part of St Louis, so it is not on > the way right now. > http://www.openstreetmap.org/browse/way/32333977 I-44, at least according to signage in 2008, ends at I-55. http://www.interstate-guide.com/images044/i-044_et_04a.jpg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Using OSM for emergency routing?
We have other adaptations too. For example, we are one of the few departments that does a dispatch by beat instead of a dispatch by nearest vehicle. This way, officers have specific beats that they will be responding too; and we make a detailed street map of each beat available in car on their mobile data terminals. We dispatch somewhere around 30 agencies in addition to our own, so we have a very large amount of dispatchers on hand at any given time. We do not dispatch fire, which makes dispatcher duties less complex. We also have standardized routing books that we publish every year and a dispatching system that lets us put in live alerting for specific hazards. Interestingly enough, most dispatchers rarely, if ever, look at a map during their shift. They instead explore the alerts and other information via a command line interface only. 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- From: dipie...@gmail.com [mailto:dipie...@gmail.com] On Behalf Of Anthony Sent: Tuesday, June 07, 2011 8:50 AM To: Lord-Castillo, Brett Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] Using OSM for emergency routing? On Tue, Jun 7, 2011 at 9:18 AM, Lord-Castillo, Brett wrote: > In our jurisdiction, we have 370,000 roads and 800+ bridges. We basically use > a whole bunch of radio dispatchers looking at live edited maps for routing. > Just building a routing network has been a massive undertaking (and, > unfortunately, OSM is nowhere close to sufficient in our area right now). > So, GPS devices in the vehicles, which relay location to the radio dispatcher, and then the radio dispatcher relays the routing info back over the radio? Sounds pretty awesome. Must be manpower-intensive, though? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] shields and overlaps
Richard Weait said: > I'm doing a little work on shield rendering for Interstate and US > Route shields, etc. > > Who has a favourite highway overlap? I'd like a few examples of each > of the following. > - two Interstates overlapping on a way > - three Interstates overlapping on a way > - combination of Interstates and US Routes totalling two or three shields > > If you could reply with a link to the way, like > http://openstreetmap.org/browse/way/ that would be awesome. > I-64, I-70, I-55, I-44, US-40 AKA, the Poplar St Bridge in St Louis, MO. It is the only quad Interstate route in existence. I-70 will reroute in 2015 and it will go down to a tri route. It also carries the designation Historic Route 66 and has the Historic 66 shield on it as well. (Even weirder, I-44 ends at the Illinois state bridge halfway across the bridge, so the west half of the bridge is I-64/70/55/44 US-40 while the east half is only I-64/70/55 US-40 Unfortunately, I-44 is missing from this part of St Louis, so it is not on the way right now. http://www.openstreetmap.org/browse/way/32333977 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Using OSM for emergency routing?
On Fri, Jun 3, 2011 at 9:37 PM, Richard Welty wrote: >> emergency vehicles >> shouldn't be overriding this, usually these bridges really and truly >> are not usable. >Drivers of emergency vehicles shouldn't be using OSM for routing >purposes. And people who don't know the area where they are driving >shouldn't be driving emergency vehicles. Certainly not people who >don't even know what bridges are safe to drive on! > >I don't know how it in other jurisdictions, but no one was allowed to >drive the ambulance or fire truck where I volunteered until they >filled out a blank map with all the street names. In our jurisdiction, we have 370,000 roads and 800+ bridges. We basically use a whole bunch of radio dispatchers looking at live edited maps for routing. Just building a routing network has been a massive undertaking (and, unfortunately, OSM is nowhere close to sufficient in our area right now). 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] FEMA seeking ideas for community disaster preparedness
Remember that the goal here is community preparedness, not disaster response. What happened in Haiti was a great use of OSM, but that was response, not preparedness. If you are going to do community based mapping, the most valuable thing to map is critical facilities and vulnerable populations. Hospitals, clinics, nursing homes, day cares, public and private schools, churches, shelters, police stations and substations, fire stations, city halls, enclosed malls, libraries, businesses with disaster supplies, officially designated heating and cooling sites, etc. I spend a lot of my time mapping these locations (especially private schools, since even defining a school is tricky). This is a critical element in disaster planning, and can greatly help community members in making their own individual disaster plans. Another idea would be to map locations in community BEOPs (basic emergency operations plans) and POD (point of distribution) plans. This would require people going to emergency management offices to get these plans, but often key locations in these plans are not mapped out. Having these locations mapped out and linked in some way back to the BEOPs and POD plans would greatly help community groups, businesses, and individuals with their own disaster plans. Charting hazards is not a good idea. There is a huge amount of liability that goes with designating hazards, and it should only be done by licensed engineers and similar professionals in their insured professional capacity. I have seen firsthand how small errors in those respects can create tens of thousands of dollars of costs overruns (or even millions in the case of earthquake liquefaction mitigation). --Brett 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: Wed, 17 Nov 2010 11:49:32 -0500 From: Leroy E Leonard To: Charlotte Wolter , talk-us@openstreetmap.org Subject: Re: [Talk-us] FEMA seeking ideas for community disaster preparedness Message-ID: Content-Type: text/plain; charset=ISO-8859-1 > Project of the week or month is another good idea. > > I have no personal contacts in FEMA and wouldn't know how to find out > what holes they have in their data sets and how OSMers could help fill > them. That's a conversation that might be best hosted online in a > forum such as this. > > As I outlined in my previous post, OSM can bring a network of mappers > and local "experts" as well as a very local map of variable richness > to the table. Our people and map could be made more valuable with some > guidance and education about which features would be the most useful > for crisis preparedness. > > Any folks from FEMA (or other experience) want to offer some suggestions? > > -- Lee On Tue, Nov 16, 2010 at 7:54 PM, Charlotte Wolter wrote: >> Lee, >> >> Perhaps some of our "projects," which get announced every month, >> could be tailored to issues that FEMA has identified. For example, FEMA >> charts hazard areas for floods, soil liquefection during earthquakes, >> tsunamis, etc. Just try to sell a home in California. You have to provide a >> complete report on those hazards, and it's generated mostly from FEMA data. >> We could incorporate that data into OSM as a project. That could be very >> doable. Then, any community could use it to generate maps for government and >> citizens. >> What do you think? >> >> Charlotte Wolter >> >> >>> At 07:34 AM 11/16/2010, you wrote: >>> >>> Over on challenge.gov, FEMA has issued a challenge for ideas for >>> "Preparing our Communities Before a Disaster Strikes": >>> >>> ? http://challenge.gov/challenges/87 >>> >>> I've started a discussion there (well, me and the crickets) about OSM >>> as a tool for building both "a diverse and distributed network of >>> people with a strong understanding of the local terrain and >>> infrastructure" plus "a hyper-local, very rich online map of a >>> community that compliments those created by the professionals at FEMA >>> and other agencies.". >>> >>> Is this an idea that other folks would be interested in pursuing, or >>> am I just a guy who thinks we have a really terrific hammer and is >>> looking at everything like it's a nail? >>> >>> >>> ?-- Lee >>> ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposal: delete census-designated place polygons
Um, actually, I am talking about a disagreement on the order of 500+ sq mi difference between the agencies on what constitutes "St Louis" As for the boundary disputes, lots do not go to boundary dispute, as they are simply resolved by taxing jurisdiction. Most boundary disputes are on the scale of 40-160 acres, but we have had some as large as 60+ sq mi (which ended with an incorporation vote to resolve it). The only real difference with a boundary dispute is that there are officially recorded documents that can serve as evidence of the boundaries. Of course, these conflict wildly (and sometimes for decades). It can take a court case to decide which document is correct; and these documents are rarely used for defining OSM boundaries anyway. 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- From: Nathan Edgars II [mailto:nerou...@gmail.com] Sent: Friday, November 12, 2010 8:47 AM To: Lord-Castillo, Brett Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposal: delete census-designated place polygons On Fri, Nov 12, 2010 at 9:40 AM, Lord-Castillo, Brett wrote: > The St Louis County Planning Department, St Louis Planning and Urban Design > Agency, St Louis Regional Chamber of Commerce and Growth Association, and US > Post Office all have different definitions of the boundaries of "St Louis" > even though it has one of the oldest most clearly defined geographic > boundaries in the United States. Among the 91 cities in our county, there > have been 54 boundary disputes resolved within the past 3 years, and 489 such > disputes in the last 50 years (the use of GIS is leading to the discovery of > more boundary discrepancies). > Just because there is disagreement over a boundary does not mean that those > boundaries do not exist and are not well defined. Totally different thing - you're talking about small-scale disagreements on the order of a lot. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundaries of cities used in postal addresses?
We try to maintain zip code boundaries using existing parcel boundaries and a list of known addresses that we get from the postal service every quarter. Zip codes do change significantly on a quarterly basis though, depending on new addresses, retired addresses, vacant addresses, PO box demand, and delivery demand. To add to this, zip codes are clearly not contiguous with themselves. They very definitely skip around, sometimes even skipping around among addresses within a parcel (and even more so when you get into the ZIP+4, which is what you need to assign specific community names). Even with full time people working on it, it is a nightmare that we only really do every couple of years for ~500 sq mi. It is possible, but certainly not easy. 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: Fri, 12 Nov 2010 07:18:57 -0500 From: Nathan Edgars II To: Talk Openstreetmap Subject: [Talk-us] Boundaries of cities used in postal addresses? Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Would it be possible to get the boundaries of the areas where a certain place name is accepted by the USPS in addresses? For example, any places not within the Orlando city limits have Orlando, FL addresses, and someone searching for said place is likely to type that into the search box. Are these simply combinations of areas covered by zip codes? If so, is there a suitable source for zip code boundaries, or are they copyrighted by the USPS? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposal: delete census-designated place polygons
The St Louis County Planning Department, St Louis Planning and Urban Design Agency, St Louis Regional Chamber of Commerce and Growth Association, and US Post Office all have different definitions of the boundaries of "St Louis" even though it has one of the oldest most clearly defined geographic boundaries in the United States. Among the 91 cities in our county, there have been 54 boundary disputes resolved within the past 3 years, and 489 such disputes in the last 50 years (the use of GIS is leading to the discovery of more boundary discrepancies). Just because there is disagreement over a boundary does not mean that those boundaries do not exist and are not well defined. 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: Fri, 12 Nov 2010 07:00:40 -0500 From: Nathan Edgars II To: Serge Wroclawski Cc: Talk Openstreetmap Subject: Re: [Talk-us] Proposal: delete census-designated place polygons Message-ID: Content-Type: text/plain; charset=ISO-8859-1 http://en.wikipedia.org/wiki/Silver_Spring,_Maryland#Geography "The definitions used by the Silver Spring Urban Planning District, the United States Postal Service, the Greater Silver Spring Chamber of Commerce, etc., are all different, each defining it for its own purposes." Which one do you "know"? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What would you want done with TIGER 2010?
It us acquired under the LUCA program. You have to go through a form of clearance for confidential data to access LUCA data and it is not public domain. I do not have that clearance, so my understanding of it is limited. Basically, the Census sends each county there current records and the county reviews/updates it. There are no direct penalties, but not participating leaves you on the outside for grant money and significantly increases the risk of undercount. As well, since so many commercial services integrate decennial tiger data, nit correct the Census records can create other problems for a county down the road. But to repeat, LUCA data is confidential(?) and never released to the public. -Brett Lord-Castillo Sent from my iPod On Aug 24, 2010, at 5:45 PM, "Anthony" wrote: > On Tue, Aug 24, 2010 at 1:45 PM, Lord-Castillo, Brett > wrote: >> TIGER 2010 is a different beast from past TIGER products. Each >> county was required to respond to the Census bureau with their >> addressing and centerline data to build it. So, it is a year or >> more out of date, but also it is derived mostly from existing local >> sources. > > Required under what law? Do they have to release it into the public > domain? > > In any case, year out-of-date county data is no better than up-to-date > county data, if you live in a state with decent public records laws. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What would you want done with TIGER 2010?
TIGER 2010 is a different beast from past TIGER products. Each county was required to respond to the Census bureau with their addressing and centerline data to build it. So, it is a year or more out of date, but also it is derived mostly from existing local sources. I'm curious what they did with the addressing. The addressing is derived from the door to door GPSing the census bureau did for several months. 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, 24 Aug 2010 11:48:05 -0400 From: Anthony To: Antony Pegg Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] What would you want done with TIGER 2010? Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 23, 2010 at 11:05 PM, Antony Pegg wrote: > What would you like to see done (or NOT see done) with TIGER 2010 as regards > OSM when it is released? Nothing on a grand scale. A TIGER import into a pretty much blank map is a great thing. A TIGER import into the current OSM, isn't going to work. On a smaller scale, I don't know. Pretty much all the TIGER data I've ever seen is surpassed in quality by local county/state data. So if you're going to import county by county, why bother with TIGER? On the other hand, TIGER 2010 might be great for the CommonMap project. (http://commonmap.info/) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Brainstorming an Import Tool
Google does not make their data available to anyone as far as I know, but the basemap tiles are available to "regular Joe Schmoe" in the same form they are available to us (i.e. you have to get a free API key). We have no contract at all with them. For ESRI, you have to sign up for an ESRI global account (I think they are free, not certain though). That gives "regular Joe Schmoe" the same data access we get. I would actually say that this works a little easier than OSM for that aspect, since the data is available as shapefiles and other formats. The database synchronization obviously requires ESRI software on the receiving end though (and permission of the uploader, since you connect to their database for the synchronization). We are interested in the tiles being pushed out, not the actual data. Our data, unfortunately, has all sorts of legal landmines that require us to keep track of who we release it to (centerlines being one of the exceptions though). 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 From: Ian Dees [mailto:ian.d...@gmail.com] Sent: Tuesday, August 17, 2010 10:21 AM To: Lord-Castillo, Brett Cc: talk-us@openstreetmap.org Openstreetmap Subject: Re: [Talk-us] Brainstorming an Import Tool On Tue, Aug 17, 2010 at 10:12 AM, Lord-Castillo, Brett mailto:blord-casti...@stlouisco.com>> wrote: Just thought I would add that both the Google and ESRI programs allow for community edits, which we can get back out into our systems. Community BaseMaps even makes the data directly available to end users (potentially with database synchronization, so you can get only edits pushed out to you nightly). None of that is available to "regular Joe Schmoe" (my definition of "community"), though. I'm sure you have a contract in place ESRI that gives you access to the Community Basemaps and a similar contract for Google's setup. These contracts prevent your citizens from using the data in the same way that OSM would allow them to. What we want out of our data upload is a publically available common basemap that provides an equal base to our enterprise applications and to public mashup developers with no mapping experience. What we offer to support that is the work of our 20+ cartographers who have direct access to resources that no one outside their office has access to. When you say a basemap, are you describing the actual data or the images that would be placed behind mashups or enterprise applications? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Brainstorming an Import Tool
Frederik Ramm wrote: > 0. Discuss with community (don't import if no community exists) > 1a. Discuss with community (don't import if no community exists) > 2a. Discuss with community (don't import if no community exists) > 3a. Work with community (make tools that let LOCAL community do this comparison) > 4. provide tools/mechanism to let community upload the data in their > area of interest. If no community exists, do no upload data. ... > In a place without a thriving community, > NOBODY NEEDS A (third party) IMPORT - the import will only make it > harder for a community to form. I speak on this from three perspectives. 1) Operator of a relatively high traffic demo mapping website that uses OSM (through CloudMade) as a base map. 2) Creator of an ESRI JSAPI map layer extension that allows drop in use of cloudmade or osm as a base map in a JSAPI based map. 3) Holder of a significant cache of official centerlines (recorded plats edited by 911 mappers) that I would like to get into OSM so we can continue to use the basemap. Just because there is no community of editors, does not meant there is not a community of highly motivated users. That is the impetus behind government agencies wanting to get their centerlines into OSM. Close off those agencies, and you close them off as users. Once I get our data uploaded into ESRI Community Basemaps (which is a simpler process, has technical support, and will accept and integrate our authoritative data even without an editor community), I'm going to have to make a choice whether our public maps will continue to use OSM. If significant barriers are made to our agency being able to upload or edit, that will be an easy choice. ESRI and Google are both actively recruiting data uploads with offered support. I don't think it is wise to go the opposite extreme with actively refusing uploads. Consider how these sources are put together too. For our county, 20+ cartographers working every day from recorded plats, deeds, right of ways, internal high resolution aerials and differential GPS traces. That -is- an editing community of its own. 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, 17 Aug 2010 10:55:35 +0200 From: Frederik Ramm To: Ian Dees Cc: "talk-us@openstreetmap.org Openstreetmap" Subject: Re: [Talk-us] Brainstorming an Import Tool Message-ID: <4c6a4e87.7040...@remote.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Ian, Ian Dees wrote: > I got the impression after SotM US that there was a huge interest in > doing imports correctly. For me, correctly means the following: 0. Discuss with community (don't import if no community exists) > 1. Get permission 1a. Discuss with community (don't import if no community exists) > 2. Convert to OSM format 2a. Discuss with community (don't import if no community exists) > 3. Compare to existing data 3a. Work with community (make tools that let LOCAL community do this comparison) > 4. Upload to the data no: 4. provide tools/mechanism to let community upload the data in their area of interest. If no community exists, do no upload data. I think that far too much weight is put on the technical side here. In a place with a thriving community, it may not take more than a WMS server to get the "import" going. In a place without a thriving community, NOBODY NEEDS A (third party) IMPORT - the import will only make it harder for a community to form. Bye Frederik -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us End of Talk-us Digest, Vol 33, Issue 42 *** ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USGS imagery (was: Changeset 5393406)
Isn't NAIP always flown leaf-on? It is required to be flown during the peak of the agricultural growing seasons. Cover-maps don't show any states where it was ever flown leaf-off: http://www.fsa.usda.gov/Internet/FSA_File/naip_coverage03-09.pdf http://www.fsa.usda.gov/Internet/FSA_File/naip03_09covermaps.pdf The is also a useful directory of distribution nodes here: http://www.fsa.usda.gov/Internet/FSA_File/appendix_c.pdf Many of which have WMS connectors. 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- -- Message: 3 Date: Thu, 12 Aug 2010 23:01:57 -0600 From: Eric Wolf To: Toby Murray Cc: Talk-US Openstreetmap Subject: Re: [Talk-us] Changeset 5393406 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Interesting. I'll have to do a little sleuthing tomorrow at the office and tell you what the different URLs are (and if there is anything better yet). Just a quick browse tells me what you are using draws from The National Map whereas Ian's URL was purely NAIP. The National Map includes the imagery captured as part of the 133 most populated places and is .3m color as well as a few other flyovers. I heard a rumor the other day that the USDA wants to start doing NAIP leaf-on (i.e., when the trees have full canopies). That sucks for most purposes other than monitoring the health of trees. But that's just a rumor right now. -Eric -=--=---===---=--=-=--=---==---=--=-=- Eric B. Wolf 720-334-7734 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
I understand that idea. But TigerLine 2010 starts releasing in December, with every state released by February. The main difference between your proposal and adopting the address standard would be that directional and type prefixes and suffixes would be broken out from each other and from informational prefixes and suffixes. That's a small subset of streets to worry about, but it will mean that streets will actually match up to the new tiger data, rather than having to manually rematch all of those. Or, we could just forgot about using TigerLine 2010, which I think would be a mistake. 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- From: Kevin Atkinson [mailto:ke...@atkinson.dhs.org] Sent: Thursday, August 12, 2010 3:54 PM To: Lord-Castillo, Brett Cc: 'talk-us@openstreetmap.org' Subject: RE: [Talk-us] Address Standard On Thu, 12 Aug 2010, Lord-Castillo, Brett wrote: > The vast majority of street addresses are only going to have only four > elements: > 2.2.1.2 Address Number > 2.2.2.2 Street Name Pre Directional or 2.2.2.6 Post Directional > 2.2.2.4 Street Name > 2.2.2.5 Street Name Post Type or 2.2.2.3 Street Name Pre Type > That's hardly a significant burden and easily understood by most people. If > the other elements don't exist, you don't use them at all. Like I said, it's > a tag based model, not a table based, so you don't even need to enter nulls > for the other elements. > The complex elements do not have to be entered either, since they are all > compositions of the simple elements. All the other 12 elements are only > entered for the rare addresses that use them. My point I was trying to make was that it still more trouble than just entering in a single name, and, in my view, not worth the extra complexity in data entry. 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. > As I said, the important thing here is that this is likely to be the > FGDC standard soon, and looks to be the format for TIGER 2010 and > subsequent updates. The point as I was trying to make is that I personally don't want to deal with them in my proposal for prefixes and suffixes. I want to push something simple though which can get used now. At a latter date we can decide if we should fully break out the address and how to use it. Also my proposal is more about what should be displayed as the street name on the map, and less about a full breakout. I will redo my proposal to make that more clear, and also to make sure it is not incompatible with a future move to a full breakout. <>___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
The vast majority of street addresses are only going to have only four elements: 2.2.1.2 Address Number 2.2.2.2 Street Name Pre Directional or 2.2.2.6 Post Directional 2.2.2.4 Street Name 2.2.2.5 Street Name Post Type or 2.2.2.3 Street Name Pre Type That's hardly a significant burden and easily understood by most people. If the other elements don't exist, you don't use them at all. Like I said, it's a tag based model, not a table based, so you don't even need to enter nulls for the other elements. The complex elements do not have to be entered either, since they are all compositions of the simple elements. All the other 12 elements are only entered for the rare addresses that use them. The Subaddress, Landmark, Place, and USPS elements are only used for those special address types, so they don't come into play on street addressing (and actually provide a standardized way of dealing with rural routes and placemark addresses, which we can currently only deal with as POIs). As I said, the important thing here is that this is likely to be the FGDC standard soon, and looks to be the format for TIGER 2010 and subsequent updates. --Brett 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- From: Kevin Atkinson [mailto:ke...@atkinson.dhs.org] Sent: Thursday, August 12, 2010 2:57 PM To: Lord-Castillo, Brett Cc: 'talk-us@openstreetmap.org' Subject: Re: [Talk-us] Address Standard On Wed, 11 Aug 2010, Lord-Castillo, Brett wrote: > I just want to point out that the federal address standard has passed > through the public comment period and is now in committee review. It is > expected to become a federal regulation in early 2011. > > http://www.urisa.org/about/initiatives/addressstandard > > ... > > The standard is presented as a tag based model expressed in xml. It > would probably be a serious mistake to ignore it. It actually directly > addresses (in address data content) all of the issues that are getting > hashed over here, and quite a few that have not been brought up yet > (like dual and quad number addresses). I looked it over. If you really wanted to break out every last possible part of a street name it would be a good guideline to follow. The problem is no one will manually enter in all those parts, especially since the distinction would be meaningless to most people. My main goal was to separate out the directional prefix because, which while important for mailing, did not really belong as part of the street name. I thought I would take care of the suffix as well. However, since I now see that there are other, non-directional, prefix and suffixes. I might simplify my proposal to simply include any prefix and suffixes not included with the displayed street name. I am also considering dropping the "included" provision until such time that all components are broken out. <>___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
I have found that in almost every case, the road really is officially named "service road" or "frontage road" if the naming authority is a county or municipality. In most cases though, the naming authority for such roads generally belongs to the State, who gives the road a name like an official name North Highway 40 Frontage Road (with the direction always designated side of the highway the road runs along, not direction the road runs), and then shortens it on the sign. The exceptions are when the state has an even more cryptic system that gives the frontage road an official name like R40N270170. This is common when the frontage or service road is technically a ramp. In those cases though, the roads rarely have signage. --Brett 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: Wed, 04 Aug 2010 10:34:25 -0500 From: Alex Mauer To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Abbreviation Police Message-ID: Content-Type: text/plain; charset="windows-1252" On 08/04/2010 07:09 AM, Richard Welty wrote: > otherwise, i'd go with local usage. some places use Service Road, > others use Frontage Road, and i'm sure there are other usages. Either way though, that?s not the actual name of the road. It?s a description of the road?s function. (though sometimes they are actually named that by the local municipality as well, YMMV) ?Alex Mauer ?hawke? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Ohio Statewide Imagery Program
I loaded the entire service into ArcMap. Nothing in the southern tier is available on the WMS connector. If you look at the viewer here: http://gis1.oit.ohio.gov/website/osip/viewer.htm you can see which counties are in the southern tier and which are in the northern tier. As an option though, you can download the imagery directly here: http://gis3.oit.ohio.gov/geodata/ 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: Wed, 07 Jul 2010 22:46:59 -0400 From: Nakor To: "Talk-us U.S." Subject: [Talk-us] Ohio Statewide Imagery Program Message-ID: <4c353c23.2000...@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, I was trying to get the OSIP imagery in southern Ohio (Miami and Montgomery counties) but cannot fiond those counties from the WMS description at http://gis1.oit.ohio.gov:80/wmsconnector/com.esri.wms.Esrimap/osip?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities Any idea how those counties can be accessed? Thanks, N. -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us End of Talk-us Digest, Vol 32, Issue 7 ** ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USGS National Map aerial imagery
USGS does not pay for anything below 1 ft resolution in an urban area (as defined by the Urban Area Security Initiative) or 2 ft anywhere else. Anything below that is not owned by USGS, but may be in the public domain due to a USGS contribution. There are orthoimagery sets on the seamless server that do not have a USGS contribution but are hosted there; those are not in the public domain. Unfortunately, due to cutbacks in the USGS orthoimagery program, that is becoming increasingly common (especially for large cities that want below 1 ft anyway). The best way to ensure that the imagery can be used for OSM is to contact the agency or company listed as "Source_Citation" under "Lineage". Under the last "Process_Step" under "Lineage", it should specify if there is a USGS Point of Contact for the orthoimagery set. If there is, then you can reach that point of contact to clarify usage too. 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: Sat, 05 Jun 2010 20:14:28 -0400 From: Lars Ahlzen Subject: Re: [Talk-us] USGS National Map aerial imagery To: Greg Troxel , Talk Openstreetmap Message-ID: <4c0ae864.7030...@ahlzen.com> Content-Type: text/plain; charset=ISO-8859-1 On 06/05/2010 07:07 PM, Greg Troxel wrote: > I think the 15cm and 30m imagery is not from MassGIS, but was paid for > by USGS, and massgis has been hosting it. But I'm not sure. You may be right. It's not clear (IMO) from the metadata. Fortunately, it shouldn't matter. -- Lars Ahlzen l...@ahlzen.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Talk-us Digest, Vol 31, Issue 1
I don't think I have encountered a situation where an administrative boundary at the city level of higher follows a road (i.e. if the road changes alignment, the boundary changes alignment). Sometimes boundaries below the city level are defined by roads, but those are not legally defined boundaries. There occasionally are legal boundaries defined on a river, but only if the river changes course gradually and naturally. If there is a radical (e.g. a post-flood cutoff of an ox-bow) or man-made (e.g. a dam causes flooding that shifts the midline), the boundary stays fixed at its original boundary. So, while boundaries might regularly fall on right of way or centerlines of roads and rivers, they are rarely fixed to those lines (which takes away some of the future benefit of using a highway in an admin boundary relation). 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: Mon, 31 May 2010 16:02:15 -0400 From: Richard Weait Subject: Re: [Talk-us] Admin limits To: "talk-us@openstreetmap.org Openstreetmap" Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 31, 2010 at 3:49 PM, Richard Welty wrote: > On 5/31/10 11:06 AM, Nakor wrote: >> ? ? Hello, >> >> I just have a quick question on admin limits. I have seen various >> practices when they are overlapping another feature (road, river, ...) >> and I was wondering if there was a consensus on the way to do it as well >> as the pros and cons of each methods. >> >> * Two separate ways with separate nodes >> * Two separate ways with common nodes >> * One way holding both tags (e.g. highway=residentail and admin_level=8) >> * other? >> > most think it should be your first choice, two ways with separate nodes. > some argue for > choice 2 (generally GIS people who don't ?like duplicate nodes), and > some bots and other > tools push that way. > > i've not heard of anyone advocating choice 3. me, i stick with 1, if it > were ever decided > that 2 was the thing to do, it'd be possible to get there with a bot. You will also hear folks suggest tag the highway as it exists, then add the highway to a boundary relation for the admin_level. When applied correctly, this makes corrections to the road geometry simple, makes the boundary follow the corrected road without a hassle, and is an excellent use of a relation. This is not an argument to put the boundary on the road if the boundary does not belong on the road. The same benefits would apply for a boundary that follows a river or other exiting feature. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Changeset to revert (or defend
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 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, 25 May 2010 03:02:19 -0400 From: Nathan Edgars II Subject: [Talk-us] Changeset to revert (or defend?) To: talk-us@openstreetmap.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Frederik Ramm wrote: >I think it's quite easy. If NE2 has been there to inspect the individual >intersection he has been changing, or at least thoroughly studied aerial >imagery or so for this particular intersection, then his idea of how it >should be tagged is as legit as someone else's and the issue must be >discussed/battled out for each case individually. 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. 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. 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. >(Personally, I have no issues with a bridge being layer=0 when stuff >below it is layer=-1 - we explicitly say that layers are meant to be >relative only. Since before I joined (and, in fact, since they were created in 2008), the wiki pages for layer and key:layer have stated that 0 is for the ground level, positive numbers are for bridges, and negative numbers are for tunnels. "The bridge within a perfectly flat street should be layer=1 even if the stream is as far below it as the Grand Canyon." As I said, maybe we need a way to mark that this has no consensus (or actively not mark that it has consensus) if there is truly a lot of disagreement with it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Lookup
But, you cannot point to point dispatch using an interpolated address; so that's why a database without address points is not that much more valuable than the TIGER db for that purpose. TIGER is not that accurate, but it is precise for an interpolated range set. Without point to point, you are only getting a driver a topologically correct route that gets them in the general area. TIGER's precision (especially TIGER 2009) is enough for this. There is plenty of value above TIGER in other applications where accuracy matters more than precision, just not in the point to point dispatch application; and that is going to be the most valuable application. The work is not in the ground surveying; that really is relatively quick work if street addressing and point addressing are done at the same time. The work is in building the address to street associations. Unfortunately, I don't see how that can get any easier than how Val has diagrammed. That particular aspect becomes even more burdensome when done separately from the street addressing too (as you have to then search for the right street segment for each address). 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: Fri, 21 May 2010 04:52:26 -0600 From: Peter Batty Subject: Re: [Talk-us] Address Lookup To: Apollinaris Schoell Cc: "val...@gmail.com" , OSM Talk US Message-ID: <04041b59-cecc-4b4f-90ea-1c9ba680d...@gmail.com> Content-Type: text/plain; charset=us-ascii I don't agree that there is no value in address range interpolation like TIGER uses. As anyone who has edited TIGER data knows, it is not very accurate. So cleaning that up (address aspects as well as geometry and attributes) is a valuable thing that we can do in OSM. Getting a viable geocoding function using address ranges is much more achievable in terms of the effort needed than doing individual properties. And the two approaches complement each other anyway - you can always search for a specific property address and fall back to an address range if you don't find it. Cheers, Peter. On May 21, 2010, at 4:24 AM, Apollinaris Schoell wrote: > there is not much value to add address interpolation in US. this can be done > easier and more consistent by using a plain tiger DB. only if detailed > addresses are added to osm there is additional value. > and yes this is a lot of work much more than streets. some counties offer > detailed data and it can be imported easily. in other places it has to be > done by survey. but wasn't that the idea of osm? competing with google in > processing public data has no chance anyway. why not concentrate on the > strengths of crowd sourcing. > > > On 21 May 2010, at 6:45 , Val Kartchner wrote: >> >> 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 > > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us -- ___ Talk-us mailing list Talk-us@openstreet
Re: [Talk-us] Getting data from ArcIMS servers
Anyone have any guidance for doing this on ArcGIS server? I have opened up WMS 1.3.0 on our aerial photo service Capabilities url: http://maps.stlouisco.com/arcgis/services/Maps/Aerials2008/MapServer/WMSServer?request=GetCapabilities&service=WMS Just not sure if anything else is needed beyond opening up the service capability. It's only 12" leaf-off for now, but sometime in the next 18 months it will be updated 6" ASPRS I leaf-off --Brett 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 07:13:57 -0400 From: Christopher Covington Subject: Re: [Talk-us] Getting data from ArcIMS servers To: talk-us@openstreetmap.org Message-ID: <1274181237.3100.21.ca...@hokiepokie> Content-Type: text/plain; charset="UTF-8" On Sat, 2010-05-15 at 15:34 -0500, Toby Murray wrote: > Oh that is awesome! The images are perfectly aligned with my GPS > traces and as a special bonus, they seem to have been taken during the > winter as there is no foliage on trees to obscure things like there is > in the Yahoo imagery of my area. I can totally count parking spaces > and even see the striping in the roads! I currently don't have > explicit permission to use layers other than the imagery for mapping > in OSM but I will have to play with this and see what's there. > > It might be a good idea to create a wiki page about ArcIMS servers > that contains some of this information. I might look at doing it once > I play with it some more... Yes, we should have a WMS page, and we should guide new mappers to this page. Tracing aerial imagery is a great way to map, and we should be giving new folks higher resolution imagery than the Yahoo stuff. NAIP has national coverage, but it's leaf-on and not as high resolution as local datasets. I propose we add it here http://wiki.openstreetmap.org/wiki/Aerial_imagery For now, just throw up your information. We can start to categorize it by country, state, etc. once we have some entries. > > As for the configuration problems, that's not going to change until > they hire a new director. I pointed out some simple link errors on > their site and got a "yeah... we're not going to touch it" response. > > Thank you! > Toby > > > On Sat, May 15, 2010 at 2:50 PM, Frederik Ramm wrote: > > Toby, > > > > Toby Murray wrote: > >> > >> Oh cool. Do you know how to determine if the server is indeed running > >> the WMS Connector and what the URL would be? I found a "how to > >> configure" page about the connector which seems to indicate that it > >> should live at /servlet/com.esri.wms.Esrimap but the county server > >> (gis.rileycountyks.gov) returns an error for that URL. > > > > Ok they have the WMS connector running. You can add the following WMS source > > to JOSM to retrieve their aerial imagery: > > > > http://gis.rileycountyks.gov/wmsconnector/com.esri.wms.Esrimap?request=GetMap&layers=0&format=image/jpeg&srs=EPSG:4326&version=1.0.0&; > > > > They also offer other layers (Parks, Streets, Churches, Streets, Public > > Buildings, and Cities) which can be accessed by changing layers=0 to > > layers=1...layers=7. > > > > Trying to access the base WMS URL > > > > http://gis.rileycountyks.gov/wmsconnector/com.esri.wms.Esrimap? > > > > with a standard WMS client like QGIS will cause problems because they have > > not configured their server properly; if you want to do that you will have > > to add the line > > > > 65.71.160.130 gisweb > > > > do your /etc/hosts or wherever the DNS override resides on your OS (or phone > > up your friends at the county GIS dept and tell them to replace "gisweb:80" > > by "gis.rileycountyks.gov" in the GetCapabilities response). > > > > Bye > > Frederik > > > > -- > > Frederik Ramm ## eMail frede...@remote.org ## N49?00'09" E008?23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
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''" Subject: Re: [Talk-us] Street Naming Conventions To: talk-us@openstreetmap.org Message-ID: Content-Type: text/plain; charset=UTF-8 On Tue, May 18, 2010 at 10:39 AM, Phil! Gold wrote: > * David ``Smith'' [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 End of Talk-us Digest, Vol 30, Issue 28 *** ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Signs on the ground was Re: Street Naming Conventions
Well, that brings up yet another issue. Olive Blvd is also State Highway 340.
So, while the local jurisdictions or county are responsible for the street
names, the state is responsible for the signage on Olive Blvd itself. As a
result, the street signs are inconsistent. If you go up to the intersection of
Old Olive Street Rd and Guelbreth Ln, you will find that the street signs now
read "Old Olive St. Rd" rather than (the use of a period in the street name is
to indicate that Street has been abbreviated to fit the sign and is not part of
the official name).
http://maps.google.com/maps?layer=c&cbll=38.675457,-90.408147&panoid=qiq2gCAHv8TR6HxNuQLn0g&cbp=12,335.15,,0,19.32&ie=UTF8&t=h&ll=38.675443,-90.408039&spn=0,0.026157&z=16
You are right on the other section. Turns out the only parcel on it (a high
school) has been readdressed to "North Olive Spur Rd", eliminating Old Olive St
Road (possibly because of the confusion, but it is interesting to note that the
online maps have not caught up yet). The street sign is still wrong (North is
part of the name), but at least some of the confusion is gone from the two road
names. To add to the fun, I was driving Olive today and saw a street sign for
yet another segment with signage for Olive Street Rd (not Old Olive Street Rd).
Turns out it used to be Olive Street rd; another chunk left over from the
realignment of olive
http://revenue.stlouisco.com/revWebDocs/asrPlats/108%20BK%209%20581.pdf
(Not sure that will work external)
But the state has placed that sign; there are no addresses there anymore with
that name and the county no longer recognizes it as Olive Street Rd, instead
having renamed it Toreador Dr. Right next to the Olive Street Rd sign is
another sign that says Toreador Dr. I know this last bit of trivia has little
bearing on the road naming conventions, but I just thought it was interesting
how screwy things get when one entity (the county) is responsible for street
names and another (the state) is responsible for street signs.
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 16:43:54 -0400
From: Nathan Edgars II
Subject: [Talk-us] Street Naming Conventions
To: talk-us@openstreetmap.org
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
Lord-Castillo, Brett wrote:
>The road that now bears all the "Olive" names was originally Plank Rd, the
>major road through St Louis County when it was rural. The main road went
>through several name changes (Plank Rd, Olive Rd, Olive St, Olive Street Rd,
>Olive Blvd). But, it also was realigned, creating orphaned segments of road
>with business on them. So, depending on when the section of road was orphaned,
>it picked up different names. All the orphaned segments became "Road" for
>their type. There is no more Plank Rd (or orphaned Plank Rd segments). But,
>going in order, orphaned segments became Old Olive Rd, Old Olive Street Rd,
>Old Olive St Rd (to differentiate that it was orphaned off Olive Street Rd
>instead of Olive St), and the currently alignment is Olive Blvd (but the next
>set of orphans should be Old Olive Boulevard Rd).
I'm still confused. Why do you say it's wrong to call the one off
Creve Coeur Mill Road "Old Olive Street Road"? (By the way, what do
the street signs say? Looks like "Olive Spur":
http://maps.google.com/maps?ll=38.683027,-90.488221&spn=0,0.008234&z=18&layer=c&cbll=38.682966,-90.488107&panoid=Retgfa_YfogoQb1_cwXbpg&cbp=12,26.81,,0,-6.61
- if so, that's what OSM should show. And on Olive Boulevard west of
Lindbergh, one of the traffic light-mounted signs says "Old Olive
Street Rd", the other "Old Olive St Rd":
http://maps.google.com/maps?layer=c&cbll=38.673196,-90.413365&panoid=qgVz1VhqBHZcd1RLK6n-ag&cbp=12,59.7,,0,4.47&ie=UTF8&ll=38.673194,-90.413243&spn=0,0.008234&t=h&z=18
- so the "on the ground" rule doesn't jibe with your suggestion to
spell out "Street" here but abbreviate it "St" to the west.)
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
The roads are two different road segments that do not connect. The road that now bears all the "Olive" names was originally Plank Rd, the major road through St Louis County when it was rural. The main road went through several name changes (Plank Rd, Olive Rd, Olive St, Olive Street Rd, Olive Blvd). But, it also was realigned, creating orphaned segments of road with business on them. So, depending on when the section of road was orphaned, it picked up different names. All the orphaned segments became "Road" for their type. There is no more Plank Rd (or orphaned Plank Rd segments). But, going in order, orphaned segments became Old Olive Rd, Old Olive Street Rd, Old Olive St Rd (to differentiate that it was orphaned off Olive Street Rd instead of Olive St), and the currently alignment is Olive Blvd (but the next set of orphans should be Old Olive Boulevard Rd). The only real way to tell the difference between Old Olive Street Rd and Old Olive St Rd is the address range. Old Olive St Rd only exists in the 13000 blocks. (Notice that it is two separate street segments which do not cross Lindbergh Blvd/US 67) http://maps.google.com/maps?f=q&ll=38.682679,-90.485764&spn=0.003874,0.006539&t=h&z=18 Old Olive Street Rd only exists in the 1 blocks. http://maps.google.com/maps?f=q&ll=38.67236,-90.405185&spn=0.015496,0.026157&z=16 There used to be an overlapping address range farther east (13005 Old Olive Street Rd is mapped below) http://maps.google.com/maps?f=q&q=13005+Old+Olive+Street+Road,+Olivette,+MO But it was eliminated when a mini-mall was built over it. The only real problem between the two street names comes when you try to find their intersections with Olive Blvd. Notice that Google has "fixed" this by turning Old Olive St Rd into Frontage Rd where it intersects Olive Blvd. (And if you search for any variant of "Old Olive" as a street by itself, it always returns only Old Olive Street Rd I think Old Olive Rd might exist in addresses only now and not have any physical road segments any more, but I'm not sure. If you follow Olive Blvd, you will find a lot of orphaned segments from old alignments with no names on Google Maps. The former Plank Rd inside St Louis City is still called Olive St and no longer connects to Olive Blvd, but does vaguely align with it. Anyway, keep in mind all of these various examples I've used over the last few weeks come from just one county (one big and relatively old county, but just one county). There are likely many many more exceptions out there among the thousands of counties in the US. --Brett 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: Mon, 17 May 2010 16:44:43 -0400 From: Nathan Edgars II Subject: [Talk-us] Street Naming Conventions To: talk-us@openstreetmap.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Lord-Castillo, Brett wrote: >But another good one close to us is "Old Olive Street Rd" and "Old Olive St >Rd" (both official names for different sections of the road). These two >streets run parallel to Olive St, Olive Street Rd, and Olive Blvd (all three >of these are different roads). So if "Old Olive Street Rd" and "Old Olive St Rd" are different, how do you distinguish them in speech? Or are they actually interchangeable names, as would seem logical (in other words, one or the other may be "official", but both are unambiguous and correct for all practical purposes)? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
I always go with my classic example (which all of the major online map services currently render incorrectly): North Outer 40 Road (which runs adjacent to and parallel to interstate 64). The name of the road is "North Outer 40". The type is "Road". It is named this because Interstate 64 used to be US Highway 40, and the road was set up to run parallel to Highway 40 on both side of the highway when it was a highway. The highway is now an interstate, but the reference to "40" was kept (so "Forty" is incorrect and it is not an address number). The road runs east-west mostly, but also runs north-south for an extensive stretch. South Outer 40 Rd runs alongside the south side of the interstate. As for parsing type, I've always liked the street that our EOC is on (see below). Depending on which part of the address you get, you might think the street type was "Dr", "Xing", "Blfs" or even the ever popular "Xing Dr". But another good one close to us is "Old Olive Street Rd" and "Old Olive St Rd" (both official names for different sections of the road). These two streets run parallel to Olive St, Olive Street Rd, and Olive Blvd (all three of these are different roads). If you have street name by itself and full name, then I could see possibly deriving all of these correctly. The problem comes when people interpret the street name incorrectly (e.g. "North Outer 40", "Outer 40", "40", "Outer", "North Outer"; "Ladue", "Ladue Bluffs", "Ladue Bluffs Crossing"; "Olive", "Olive Street", "Olive St", "Old Olive", "Old Olive St", "Old Olive Street". Not sure if four separate fields will create more data entry errors, or will create more attention to detail. 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- Message: 1 Date: Fri, 14 May 2010 13:16:22 -0700 From: Richard Finegold Subject: Re: [Talk-us] Street Naming Conventions To: val...@gmail.com Cc: OSM Talk US Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 10, 2010 at 20:18, Val Kartchner wrote: > 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 ? ? ? ? ?Type ? ?Suffix > ?200 ? ? West ? ?North Temple ? ? ? ? Street > ?200 ? ? East ? ?South Temple ? ? ? ? Street > ?200 ? ? North ? West Temple ? ? ? ? ?Street > ?50 ? ? ?East ? ?North Lakeview ? ? ? Drive > ?50 ? ? ?East ? ?South Lakeview ? ? ? Drive > ?2450 ? ?North ? E ? ? ? ? ? ? ? ? ? ?Street > ?300 ? ? ? ? ? ? Southgate ? ? ? ? ? ?Drive > ?4700 ? ?West ? ?3300 ? ? ? ? ? ? ? ? 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. I'll again claim that just one field would be enough -- the street name -- and the other three can be derived from their offsets; trivial for direction prefix, and slightly more complicated (requiring a dictionary/list of directions, anything left over goes into the street type field) for the latter two. Can you offer any examples where these three would be difficult to derive if one was provided only full name and street name? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Civil Defense Sirens?
We classify siren maps as homeland security information, just like pipelines, following the precedent from the Santa Clara County case. They are not part of the publically available datasets for St Louis County: http://www.stlouisco.com/plan/gis/spatial_data.html I cannot specify precisely why, but there is a good chance that another grassroots siren mapping project was conducted locally for the purpose of data-gathering for a siren hack attempt. Like pipelines and security perimeters, it is one of those areas that may not be that wise to map in an organized way in the United States unless you coordinate a little with local emergency management agencies. Is our agency going to do anything about it if mapping sirens is the OSM project of the week? No. But another agency who finds out about the project and has no idea what OSM is and has no notice from a local mapping that they are mapping out all the sirens on the ground for OSM might not be so friendly to that local mapping (especially if a siren hacker turns around and uses that information to plan an attack). --Brett 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: Mon, 3 May 2010 12:52:43 -0500 From: Jeffrey Ollie Subject: Re: [Talk-us] Civil Defense Sirens? To: "talk-us@openstreetmap.org" Message-ID: Content-Type: text/plain; charset=UTF-8 On Mon, May 3, 2010 at 12:29 PM, Lord-Castillo, Brett wrote: > Just wondering what would be the purpose of mapping civil defense sirens? Because they are there isn't a good enough reason? > Sirens are also one of those areas (like mapping major pipelines) that do > fall under homeland security protections for sunshine laws. Without some proof I call FUD. Anyway, sunshine laws are for governments, not for individual citizens. I'm not expecting people to drop in on the local emergency management agency and ask for a map of all the sirens... -- Jeff Ollie -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us End of Talk-us Digest, Vol 30, Issue 6 ** ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Civil Defense Sirens?
Just wondering what would be the purpose of mapping civil defense sirens? You have to make some significant decisions of what kind of information to include about the sirens (for example, without range and/or model, you cannot derive projected coverage; without directional coverage you cannot identify nearest covering siren). Sirens are also one of those areas (like mapping major pipelines) that do fall under homeland security protections for sunshine laws. Some jurisdictions (mostly cities) are open with their siren locations, some of them are very protective (mostly those places whose sirens have been subjected to attacks by siren hackers in the past or who have particularly significant security concerns). Mapping site specific sirens (like those used for electric generation facilities) can especially draw scrutiny. As for the feasibility, I recently did a project to map 210 sirens from aerial photos and ground work, and it was virtually impossible without prior knowledge of the siren locations and high resolution aerial oblique photos. In all, it took about 60 hours of work (and that was with a list of locations). --Brett 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: Mon, 3 May 2010 11:41:37 -0500 From: Jeffrey Ollie Subject: [Talk-us] Civil Defense Sirens? To: talk-us Message-ID: Content-Type: text/plain; charset=UTF-8 With the start of Tornado season in the Midwest upon us, I thought it would be interesting to map civil defense sirens: http://en.wikipedia.org/wiki/Civil_defense_siren However, I can't find any existing examples and either I'm tired or coming down with something but I can't really think of a good way to tag these either. As for rendering, we could use the International Civil Defense symbol: http://en.wikipedia.org/wiki/File:CivilDefence.svg Might make a good project of the week too... -- Jeff Ollie ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
-Original Message- From: Apollinaris Schoell [mailto:ascho...@gmail.com] Sent: Friday, April 23, 2010 9:47 AM To: Lord-Castillo, Brett Cc: 'talk-us@openstreetmap.org' Subject: Re: [Talk-us] Admin boundaries tied to roads On 23 Apr 2010, at 7:13 , Lord-Castillo, Brett wrote: >> On 19 Apr 2010, at 20:24, Apollinaris Schoell wrote: >>> On 19 Apr 2010, at 20:07 , Alan Mintz wrote: >>>> Not to mention that merging them will result in the inability to hide >>>> these >>>> boundaries. When doing a bunch of editing on a road that follows one, in >>>> the past, I've taken the time to verify that the boundary doesn't share >>>> any >>>> nodes with anything and then remove it from my local OSM file manually so >>>> I >>>> don't have to constantly deal with it. If it shares nodes with anything >>>> else, this is no longer possible. >> >>> fully agree, the good thing is these boundaries are tiger data and bad data >>> anyway and should be replaced with better boundaries >> >> While I understand the mantra of TIGER=Bad because of the state of the road >> data, this is not true for the boundary data. Most of the >> boundary data comes directly from recorded surveys (something not available >> for roads) and is not "bad data" for most of the United >> States. The rural areas would be the one exception (mostly because they did >> not have surveys converted to digital layers in 2000), but >> rural areas are also highly likely to have realigned boundary roads that no >> longer correspond to the original boundaries. >> > I can tell for sure that they are completely wrong in California. They are > not even close to USGS 24k, don't align with official county > borders from official sources and don't align with natural features, fences > which are sometimes visible on Yahoo. Yes, California is one of the well-known exceptions. Their LUCA program fell apart (and this time around has been split into two separate regions as a result). If you take the Midwest states though, like Iowa, Minnesota, Missouri with their 300+ counties between them, the TIGER lines are directly from official sources, especially the 2009 updates. 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On 19 Apr 2010, at 20:24, Apollinaris Schoell wrote: >On 19 Apr 2010, at 20:07 , Alan Mintz wrote: >> Not to mention that merging them will result in the inability to hide these >> boundaries. When doing a bunch of editing on a road that follows one, in >> the past, I've taken the time to verify that the boundary doesn't share any >> nodes with anything and then remove it from my local OSM file manually so I >> don't have to constantly deal with it. If it shares nodes with anything >> else, this is no longer possible. > fully agree, the good thing is these boundaries are tiger data and bad data > anyway and should be replaced with better boundaries While I understand the mantra of TIGER=Bad because of the state of the road data, this is not true for the boundary data. Most of the boundary data comes directly from recorded surveys (something not available for roads) and is not "bad data" for most of the United States. The rural areas would be the one exception (mostly because they did not have surveys converted to digital layers in 2000), but rural areas are also highly likely to have realigned boundary roads that no longer correspond to the original boundaries. --Brett 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: Mon, 19 Apr 2010 20:24:47 -0700 From: Apollinaris Schoell Subject: Re: [Talk-us] Admin boundaries tied to roads To: Alan Mintz Cc: talk-us@openstreetmap.org Message-ID: Content-Type: text/plain; charset=us-ascii On 19 Apr 2010, at 20:07 , Alan Mintz wrote: > At 2010-04-19 10:45, Mike N. wrote: >> I see that the separate VS tangled argument has been settled in the US by >> the "Duplicate Node attack bots", who have blindly merged all duplicate >> nodes. >> >> http://www.openstreetmap.org/browse/way/38855677 > > Is this really happening? Can someone describe exactly what criteria are > being used, and just how it was decided that this was a good idea? Seems > like the wrong thing to do - city and county boundaries are often defined > in law, or by survey, and do not necessarily keep up with changes in road > alignment. I have resisted editing most of these boundaries until/unless I > take the time to research the true definition of the boundary. > > Not to mention that merging them will result in the inability to hide these > boundaries. When doing a bunch of editing on a road that follows one, in > the past, I've taken the time to verify that the boundary doesn't share any > nodes with anything and then remove it from my local OSM file manually so I > don't have to constantly deal with it. If it shares nodes with anything > else, this is no longer possible. fully agree, the good thing is these boundaries are tiger data and bad data anyway and should be replaced with better boundaries > > Sounds a lot like the IMO ill-considered road name expansion that was > apparently agreed upon by a small group of people without input from the > majority of active mappers whose work has been damaged. agreed, no idea why this was done. it's a change without much benefit but lot's of damage. > > -- > Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
They say 'Rue Saint Louis', which is an alternate name for the street (but not the official postal name) or they say 'S T Louis Street'. I think the post office uses the different zip codes to sort things out; but that doesn't help with street routing which can get pretty screwed up depending on your device. People here are actually pretty used to saying "S T Louis" for different uses (for example, my email address). The street signs on St Louis St actually say "Rue St Louis" (with no street abbreviation). 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- From: andrzej zaborowski [mailto:balr...@gmail.com] Sent: Thursday, April 08, 2010 12:23 PM To: Lord-Castillo, Brett Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] Street Naming Conventions On 8 April 2010 15:48, Lord-Castillo, Brett wrote: > One issue with using unabbreviated names, is sometimes the abbreviations are > part of the official name. > Examples here: > 1st Community CU Dr (First Community Credit Union goes to a -different- > address) > River City Blvd/River City Casino Blvd; many people think the first is an > abbreviation of the former. It isn't, two different streets that will route > mail (and traffic) to two different sets of addresses > St Louis Street, which is different from Rue St Louis, which is different > from Saint Louis Street and Saint Louis Boulevard, which is still different > from The Boulevard St Louis. In each of those cases, the non-type > abbreviations are part of the name and expanding the abbreviations can turn > them into different streets. In "1st Community CU Dr" when you read it out, I guess you do say "... CU Drive". But the St Louis Street vs. Saint Louis Street? They're pronounced exactly same way and I'm sure 90% people will write both of them as "St Louis Street" in rush, are there seriously cases where these are different addresses? What do the people living at St Louis St say on the phone when asked for address? Cheers <>___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. 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- Message: 3 Date: Wed, 07 Apr 2010 09:42:42 -0400 From: Matthias Julius Subject: Re: [Talk-us] Street Naming Conventions To: talk-us@openstreetmap.org Message-ID: <87bpdv8jl9@julius-net.net> Content-Type: text/plain; charset=utf-8 andrzej zaborowski writes: > Hi, > > > I'd like to see them as separate tags, but I'd really like the name= > tag to remain consistent across the world, i.e. have an unabbreviated > name in it, that can be passed to something like a text-to-speech > system without having to keep a list of possible abbreviations for > every language in the database. Especially names like "St Park St" > (State Park Street) or "St Tropez St" (Saint Tropez Street) would be > difficult to deal with. Changing from unabbreviated to abbreviated in > a renderer or another tool is much easier on the other hand, with less > space for ambiguity. Yes, this is exactly my view, too. It is much easier for tools to abbreviate the string than to expand it without ambiguity. Because in the latter case it has to make assumptions. Matthias -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us End of Talk-us Digest, Vol 29, Issue 5 ** <>___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] California land cover import
I know we're not that big on commercial software, but the esri smooth/simplify tools will fix that first problem very quickly. You really cannot do a spline interpolation though, because that requires true curves which are not supported by the OSM format (nor PostGIS). You could do a polyline approximation of a spline interpolation, but after you simplify, interpolation, then approximate off a dataset that is already a generalization, how far away are you from the real world data? (To make this worse, the California shapefiles are polygon conversions of 5m raster data, hence the points every 5m. The nice part is that you can be reasonable certain that 5/2 * sqrt(2) meters is the correct allowable deviation for a smooth/simplify. For the last problem, if the ways are overlaying each other rather than overlapping, a conversion to a topological data format will eliminate that problem quickly. If the ways are truly crossing, than an esri topology can go a long ways towards fixing those. Instead though, I would suggest a direct conversion to raster (or get ahold of the original raster data) and then a smoothed raster to polygon conversion to fix that. 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, 29 Dec 2009 23:43:45 -0800 From: Subject: [Talk-us] California land cover import To: Message-ID: <000301ca8923$d29dd460$77d97d...@com> Content-Type: text/plain; charset="us-ascii" The state of California has some good landcover shapefiles on the Department of Forestry and Fire Protection site. They are sorted by county. The smallest are under a meg while the largest - Fresno - is more than 400 megs. The average size is around 30 to 40 megs. These would be a great addition to OSM since they contain valuable metadata. Once the areas have been added, the state will take on a similar look to states like Georgia and Massachusetts that have had statewide imports done. Another good example of what California can be is the Corine Land Cover (WikiProject Corine Land Cover). There are several challenges with the data. Here are a couple. * It is a huge dataset and will need some optimization. The straight lines have points every five meters, creating jagged edges that aren't visually attractive. Josm has a plugin but that's probably not the best way. A spline interpolation would really improve it dramatically. It will increase data size, but it's worth it. Maybe there is a batch mode program available to do that. Mapshaper has a tool to optimize a shapefile by reducing the details in the file. It may not be working though. Here is a rough idea of what the areas look like without being simplified. * Only vegetation data should be used. The urban/residential/water/unknown should be skipped since the quality isn't good enough for this purpose and would just create tons of conflicts with existing data. Also there is/will be better data available. * We can use some filters to split the shapefiles into different features. This is also great to prepare the OSM files for each type instead having it mixed all together. * All these polygons have overlapping ways. This should be avoided because it creates tones of duplicate nodes/ways. Each polygon should be split in single ways and the area defined with a relation. According to the description, mapshaper will do that to. There may be a way to do this with postgis or through a Perl script. Validator will just merge duplicate nodes, but can't fix duplicate lines. This is really a tricky thing that many other updates lack. Efficiency should be considered here. Also editing is easier then. This data shouldn't need much editing after import. Please feel free to add your comments and suggestions on the California Land Cover wiki page. This is also being posted to the imports list. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-us/attachments/20091229/3d9481ae/attachment-0001.htm -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us End of Talk-us Digest, Vol 25, Issue 47 *** ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Mapping Streams was RE: HI: Hawaii GIS Data
That text below is referring to the submerged lands act, but the submerged lands act only applies to tidally affected seaward nautical lands, not to inland navigable rivers. Inside the boundaries of states, a patchwork of common law and state laws dictate what is public and private, and it varies significantly from state to state. The private right to tidal lands extends from English Colonial Law and predates the Constitution, creating a hodge podge of at least 24 different land rights regimes for submerged lands under navigable waters. Through the commerce clause, actually navigable waters connecting to interstate water bodies can be federally regulated, but the federal government has chosen not to regulated inland submerged lands. The most extreme rights regime towards the public side is Oregon, where submerged land extends to the mean high tide line, and the dry sand beach has a public easement up to the vegetation line. In the opposite direction, Massachusetts not only considers submerged land to only extend to the mean low water line, but under Massachusetts General Law, submerged lands are privately held with an easement to fish, fowl, and freely pass for navigation between public waters. In other words, any mappers out there planning to do streams and rivers, check first on the state laws governing navigable streams in your state. To be navigable, a water body must connect with a continuous interstate waterway and be actually navigable (or tidally influenced); traverse by canoe is enough to be actually navigable. Any stream on private land which is not actually navigable is probably considered fully private land and not going to have a public easement (but again, check by state on that too before you attempt any mapping on private land). 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: Sat, 5 Dec 2009 09:49:36 -0500 From: Anthony Subject: Re: [Talk-us] Hawaii GIS Data To: Matthew Luehrmann Cc: Talk-us@openstreetmap.org Message-ID: <71cd4dd90912050649m48645d55s9cfdff52e8cf7...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Fri, Dec 4, 2009 at 11:40 PM, Matthew Luehrmann < matthew.luehrm...@gmail.com> wrote: > Just as a note for those interested in mapping streams and rivers, "the > riverbed and banks, up to the ordinary high water mark, are state land, > held > in trust for the public for navigation, fishing, and other non-destructive > visits." > Apparently this is US federal law, superseding any state law (at least for navigable streams and rivers) under the commerce clause. Interesting. However, you'd still need permission from the owner of the land where you start and end your journey, correct? -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-us/attachments/20091205/40a7e9eb/attachment-0001.htm <>___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
I'm still getting a handle on the schemas in use for OSM, and noticed that concept of matching address nodes to ways when doing imports. I'm not so sure this will be very functional for floodplain counties or heavy agricultural counties. We have thousands of addresses with no corresponding roads; the roads were wiped out in 1993 but the parcels still remain (and we even get regular 911 calls for those addresses on roads that have not existed for 15 years). Same thing for rural areas; plenty of addresses with no corresponding roads. As a further complication, it is very common for an address to have a completely different jurisdiction from the road, since roads are the main divider for municipal/unincorporated boundaries (and you have a lot of those with 90+ munis in 500 sq miles). 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] : US Chapter Call?
On the other hand, a work hours call also makes it a heck of a lot easier for government representatives to participate; as taking the call on a private line outside business hours as a government representative would not be allowed for many states. --Brett 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] NGA report on Conflation Services
NGA has publically released their report on conflation services https://www.1spatial.com/resources/pdf/Public_Release_Conflation.pdf Click the link "Conflation Services in an R&D Fusion Environment" Might be pretty useful, since the main focus of the report is feature matching in multilayer dataset conflation. 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- From: talk-us-boun...@openstreetmap.org [mailto:talk-us-boun...@openstreetmap.org] On Behalf Of talk-us-requ...@openstreetmap.org Sent: Friday, October 02, 2009 6:00 AM To: talk-us@openstreetmap.org Subject: Talk-us Digest, Vol 23, Issue 3 Send Talk-us mailing list submissions to talk-us@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-us or, via email, send a message with subject or body 'help' to talk-us-requ...@openstreetmap.org You can reach the person managing the list at talk-us-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Talk-us digest..." Today's Topics: 1. Re: U.S. Local Chapters (SteveC) 2. Re: U.S. Local Chapters (Bill Ricker) 3. Re: U.S. Local Chapters (Peter Batty) -- Message: 1 Date: Thu, 1 Oct 2009 19:45:03 -0700 From: SteveC Subject: Re: [Talk-us] U.S. Local Chapters To: Serge Wroclawski Cc: talk-us@openstreetmap.org Message-ID: <81c8b75e-49e0-4de7-bd7a-b14464fa1...@asklater.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes yeah I can set up a call, just gimme the word On 1 Oct 2009, at 12:06, Serge Wroclawski wrote: > On Thu, Oct 1, 2009 at 2:19 PM, Anthony wrote: > >> Is too much to ask for to have everyone interested in the >> conference call >> set up Skype? > > I would much, much prefer a standard conference call service. > > Those services are generally more reliable, easier to get working, > have consistency in terms of audio quality, and don't rely on > proprietary software. > > I won't harp on that last point too much (the others are fairly good), > but I know it can be an issue for some people and it'd be good to > avoid it if possible. > > What's the conference call system that OSM uses for other call-ins, > like the data import working group one? > > - Serge > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us > Yours &c. Steve -- Message: 2 Date: Thu, 1 Oct 2009 23:48:41 -0400 From: Bill Ricker Subject: Re: [Talk-us] U.S. Local Chapters To: talk-us-baya...@openstreetmap.org, talk-us Openstreetmap Message-ID: <54fc5fc00910012048h77f9f568n5f10db25184bc...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 1, 2009 at 2:19 PM, Anthony wrote: > I'd recommend setting up the draft bylaws prior to making the decision of > where to incorporate.? How we want to run the organization will help > determine where (and whether) to incorporate. Right, as otherwise the locality dictates what sort of bylaws you can have. Anthony's point on the bylaws talk page that a discussion of principles and alternatives should come before legally drafting seems wise -- and drafting thzlegalese to match our principles and the law of the chose state should be left to a professional. Massachusetts has several oddities in recommended not-for-profit bylaws and THREE separate annual reporting requirements. It's the only jurisdiction I have board / officer / bylaws-committee expertise in, and I would have to recommend incorporating a national entity elsewhere. There's probably a state with worse paperwork for a small board, but I don't know. The only safe early choice is probably Delaware ... provided you don't make replacement of provisional bylaws difficult, which error any good Delaware attorney should help a provisional board from making. Per expert I cited in previous post, it may be the only sane choice anyway. Having been a Director and Officer of a 501(c)(3) corporation subject to Discovery in Litigation, I can not recommend serving on a Board that does not have adequate Directors' Liability Insurance. -- Bill n1...@arrl.net bill.n1...@gmail.com I am not a lawyer, and Justice Scalia agrees it's better that way http://url.ie/2k04 -- Message: 3 Date: Fri, 2 Oct 2009 02:31:27 -0600 From: Peter Batty Subject: Re: [Talk-us] U.S. Local Chapters To: Bill Ricker Cc: talk-us Openstreetmap , talk-us-baya...@openstreetmap.org Message-ID: Content-Type: text/plain; charset="iso-8859-1" Thanks to Bill for his previous p
Re: [Talk-us] Bulk upload from sql server 2008 (via shapefile?)
Sounds good. Should I use any particular projection, or export out to unprojected WGS84? One of the major problems is that there are an awful lot of domains tied to the sql server tables. Going to take a while to convert the domain codes to domain descriptions. I also have to deal with losing topologies and z-values as well as converting field names to a dbf compatible form. So, the conversion will take a while, but it's doable :) I'll start with street centerlines. Once I get those to shapefile, what's the next step? 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 From: Ian Dees [mailto:ian.d...@gmail.com] Sent: Friday, September 04, 2009 10:10 AM To: Lord-Castillo, Brett Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] Bulk upload from sql server 2008 (via shapefile?) On Fri, Sep 4, 2009 at 9:56 AM, Lord-Castillo, Brett mailto:blord-casti...@stlouisco.com>> wrote: I posted this up through Nabble, but it's been sitting there 4 days without being accepted so I'm trying through the list instead: I have access to a significant amount of spatial data in sql server 2008 spatial format for my county, covered under public domain/CC Share Alike. It consists of about 70k addressed road centerline segments and 700,000 or so building outlines, light rail lines and stations, police stations, fire stations, schools, addressing points, hospitals, and care facilities. I have direct contact with the GIS coordinator to work on any licensing issues. My question though is, how do I get this data from sql server spatial to OSM? I can export out to any ArcInfo supported format (like shapefile). I would start with this: export the various themes to shapefiles and then we can work from there. I don't think anyone has any experience converting SQL Server 2008 to OSM, but there's tons of experience converting SHP to OSM. As for reconciliation after you get it into OSM format, it really depends on the areas that the data covers. If it's in a highly active area, then there's a greater chance that there will be more conflicts (but also possibly more people to help you). Once we get the OSM files, we can work on getting some help to merge old OSM with new OSM (perhaps from the Germans (who have already mapped everything in their own country ;-) )). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Bulk upload from sql server 2008 (via shapefile?)
I posted this up through Nabble, but it's been sitting there 4 days without being accepted so I'm trying through the list instead: I have access to a significant amount of spatial data in sql server 2008 spatial format for my county, covered under public domain/CC Share Alike. It consists of about 70k addressed road centerline segments and 700,000 or so building outlines, light rail lines and stations, police stations, fire stations, schools, addressing points, hospitals, and care facilities. I have direct contact with the GIS coordinator to work on any licensing issues. My question though is, how do I get this data from sql server spatial to OSM? I can export out to any ArcInfo supported format (like shapefile). I've read through working with shapefile to OSM, but could use a little more detailed help on this perhaps. As well, once the data is in osm format, how do I go about all the reconciles? Just the address points alone would easily take several hundred hours to reconcile. Can I look for community help on something like that if I make the data otherwise available? 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
