Re: [Talk-GB] New mapper has imported all Nottingham street lights
On 7/29/2014 1:51 PM, SK53 wrote: Don't need to say much more, other than it's an undiscussed import and if we'd thought it would be useful could have done it anytime in the past 18 months. Changeset is : https://www.openstreetmap.org/changeset/24412110 Will plan to revert in 1 days time if no further action by the mapper. I've contacted the user. As the import didn't meet some of the basic consultation/documentation requirements and appears to be cleanly revertable, I've started a revert. Paul Norman For the Data Working Group ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] City names translation
On 8/5/2014 12:06 AM, Pavlo Dudka wrote: It seems that the only place not allowed for adding name:** is UK. That's why I started this discussion here. Should we discuss it internationaly? There is a general understanding that name:xx is for the name in the language xx, not a translation of the name. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] NHD Hydro Connectors
Here in Canada with the NHN import the portion of streams through lakes and wider rivers were imported with sub_sea=stream sub_sea:type=inferred oneway=yes accuracy:meters=-1 (and source/attribution tags), but that import needed a lot of clean up after it. I've been changing the sub_sea=stream to waterway=stream|river as I go through my area doing cleanup. My recollection is that a few months ago you couldn't see the streams under natural=water areas but after a style change you could. -Original Message- From: David Fawcett [mailto:david.fawc...@gmail.com] Sent: Friday, February 18, 2011 8:59 AM To: Phil! Gold Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] NHD Hydro Connectors Thanks for your input Phil. I don't have strong opinions about what data should be stored, I just think that when the default public map looks ugly/broken, people start to question other data elements as well. It will be interesting to see if people can actually build and maintain hydro networks based on the imported NHD data. I would think that for the purpose of building networks, one might always want to work with the original data. As an aside, if one is trying to build a network, it is useful to know that in the Great Lakes, some shorelines are included in the streamlines data. The shoreline-based streamlines for islands can definitely throw an error in network creation because their start node and end nodes are the same. We also have to remember that the NHD is a 'living' data set. There is significant editing going on in two major watersheds (HUC8s) in my area. David. On Fri, Feb 18, 2011 at 10:36 AM, Phil! Gold phi...@pobox.com wrote: * David Fawcett david.fawc...@gmail.com [2011-02-18 10:13 -0600]: In some areas where the National Hydrography Dataset (NHD) has been imported, the rendering of the data is less than desirable. I am not sure if this is something that should be fixed in renderers or in the data. IMHO, it's a rendering issue. First off, it also affects the current best practice (as I understand it) of mapping wider waterways as riverbank plus linear way; if the linear way is tagged waterway=stream, you get the same artifacts. Secondly, it is often the case that waterways are considered to continue through bodies of water, which would indicate the necessity of the connecting linear ways to accurately reflect local naming of water features. I know of several places in my area where a river was dammed to form a lake, the lake is known as Such-and-such Reservoir, but the original river is still considered to be running through the middle of the reservoir and shows a such on maps. Thirdly, having a complete waterway network is a potentially useful thing (for many of the reasons the NHD adds the connecting ways in the first place) so their presence shouldn't be discouraged. My conclusion is just that the renderers need to handle linear streams on top of water areas (natural=water or waterway=riverbank) better and no tagging changes should be needed. Submitting a patch for this is on my list of things I plan to look at eventually if no one beats me to it, but that's a long list with other things ahead of stream rendering. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- I am his Highness' dog at Kew; Pray tell me, sir, whose dog are you? -- Alexander Pope, Epigram Engraved on the Collar of a Dog Which I Gave to His Royal Highness --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Proposed cleanup: NHD rivers
A mapnik rendering change has revealed a problem in some areas with NHD imported waterways. An example of the problem is at http://www.openstreetmap.org/?lat=45.3lon=-123.3zoom=9layers=M Essentially, all the streams are tagged as waterway=river, with waterway=stream being used for what appear to be intermittent streams. I propose doing the following changes. These changes would *only* be done to ways that have not been modified since import. I have experience with this type change from cleanup on Canadian NHN data. 1. Adding intermittent=yes to NHD streams. 2. Downgrading waterway=river to waterway=stream for non-rivers. 3. Joining rivers into a single way Steps 1 and 2 would be done in one set of imports while joining rivers would be done in a second pass. Spot checks in the area linked indicate this would cause no problems. If verification with imagery was necessary I'd use MapQuest's Open Aerial Map as it seems to be the highest quality in these remote areas. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed cleanup: NHD rivers
I checked with http://wiki.openstreetmap.org/wiki/NHD#Mapping and StreamRiver 46003 was mapped to waterway=stream, and the description is intermittent streams. As far as I can tell, nothing else was mapped to waterway=stream. NAIP imagery seems to verify this. Seeing that the FCode was imported, I'm thinking I'll use that to identify which are rivers and which are streams. Essentially, this will be changing 46003 to intermittent streams and 46006 to streams, with exceptions for 46006 where the name indicates it's a river. -Original Message- From: j...@jfeldredge.com [mailto:j...@jfeldredge.com] Sent: Sunday, March 20, 2011 2:42 PM To: OpenStreetMap talk-us list Subject: Re: [Talk-us] Proposed cleanup: NHD rivers Has anyone determined for sure that the streams you plan to tag as intermittent are so, in fact? This would require either getting confirmation from the organization that made the original survey, or at least checking with folks with local knowledge that a large. enough sample of the streams were, in fact, all intermittent. ---Original Email--- Subject :[Talk-us] Proposed cleanup: NHD rivers From :mailto:penor...@mac.com Date :Sun Mar 20 16:29:54 America/Chicago 2011 A mapnik rendering change has revealed a problem in some areas with NHD imported waterways. An example of the problem is at http://www.openstreetmap.org/?lat=45.3lon=-123.3zoom=9layers=M Essentially, all the streams are tagged as waterway=river, with waterway=stream being used for what appear to be intermittent streams. I propose doing the following changes. These changes would *only* be done to ways that have not been modified since import. I have experience with this type change from cleanup on Canadian NHN data. 1. Adding intermittent=yes to NHD streams. 2. Downgrading waterway=river to waterway=stream for non-rivers. 3. Joining rivers into a single way Steps 1 and 2 would be done in one set of imports while joining rivers would be done in a second pass. Spot checks in the area linked indicate this would cause no problems. If verification with imagery was necessary I'd use MapQuest's Open Aerial Map as it seems to be the highest quality in these remote areas. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed cleanup: NHD rivers
Name for 2. It might miss some rivers, but the data source doesn't differentiate between streams and rivers in any of the metadata. 3 is about making the rivers into single ways, more like a mapper would do by hand. I'm not really set on this step and if done it would be after steps 1 and 2 have been done everywhere. Looking at nhd:com_id it might cause problems with updating, so I'm thinking I'll drop this step for now. -Original Message- From: James U [mailto:jumba...@gmail.com] Sent: Sunday, March 20, 2011 4:42 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposed cleanup: NHD rivers 1 and 2 make sense to me. What criteria would you use for 2? I have done a fair bit of NHD imports and simply used the name, i.e. river, to classify rivers. Some parts of the country have different naming traditions that others. What is the rationale for 3? On Sunday, March 20, 2011 05:29:54 pm Paul Norman wrote: A mapnik rendering change has revealed a problem in some areas with NHD imported waterways. An example of the problem is at http://www.openstreetmap.org/?lat=45.3lon=-123.3zoom=9layers=M Essentially, all the streams are tagged as waterway=river, with waterway=stream being used for what appear to be intermittent streams. I propose doing the following changes. These changes would *only* be done to ways that have not been modified since import. I have experience with this type change from cleanup on Canadian NHN data. 1. Adding intermittent=yes to NHD streams. 2. Downgrading waterway=river to waterway=stream for non-rivers. 3. Joining rivers into a single way Steps 1 and 2 would be done in one set of imports while joining rivers would be done in a second pass. Spot checks in the area linked indicate this would cause no problems. If verification with imagery was necessary I'd use MapQuest's Open Aerial Map as it seems to be the highest quality in these remote areas. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed cleanup: NHD rivers
This is the view I subscribe to too. An example of two ways I would want to join would be http://www.openstreetmap.org/browse/way/68711710 and http://www.openstreetmap.org/browse/way/68710322 These differ only in nhd:com_id and they're both really short ways. In any case, I'd like to make it clear that there are two separate parts. The retagging of the ways, and the joining of them. The first one is a serious issue, visible out to z8 in the rendering and hopefully uncontroversial to change. The second one is a less important issue that it seems more debate is required on. For the retagging, I've done up a table at http://wiki.openstreetmap.org/wiki/User:Pnorman/NHDCleanup which explains the changes I'm proposing. I should of thought of a table earlier Also, I need to empathize that any data edited by users since the imports won't be touched without manual review. -Original Message- From: Richard Welty [mailto:rwe...@averillpark.net] Sent: Sunday, March 20, 2011 5:38 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposed cleanup: NHD rivers On 3/20/11 8:16 PM, Nathan Edgars II wrote: On 3/20/2011 8:13 PM, Richard Welty wrote: d suggest using relations to group ways that are parts of named rivers rather than trying to combine the ways. If the only difference between the ways is that NHD assigns a different ID number to them, not combining them seems silly. if the ids are consistent from one release to the next and there is any notion of doing an update later, then combining them destroys useful information. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed cleanup: NHD rivers
If there are no objections to the retagging part I'll proceed with retagging FCodes 46003 and 46006 as documented on http://wiki.openstreetmap.org/wiki/User:Pnorman/NHDCleanup I will not be joining waterways at this time. -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: Sunday, March 20, 2011 6:52 PM To: 'Richard Welty'; talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposed cleanup: NHD rivers This is the view I subscribe to too. An example of two ways I would want to join would be http://www.openstreetmap.org/browse/way/68711710 and http://www.openstreetmap.org/browse/way/68710322 These differ only in nhd:com_id and they're both really short ways. In any case, I'd like to make it clear that there are two separate parts. The retagging of the ways, and the joining of them. The first one is a serious issue, visible out to z8 in the rendering and hopefully uncontroversial to change. The second one is a less important issue that it seems more debate is required on. For the retagging, I've done up a table at http://wiki.openstreetmap.org/wiki/User:Pnorman/NHDCleanup which explains the changes I'm proposing. I should of thought of a table earlier Also, I need to empathize that any data edited by users since the imports won't be touched without manual review. -Original Message- From: Richard Welty [mailto:rwe...@averillpark.net] Sent: Sunday, March 20, 2011 5:38 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposed cleanup: NHD rivers On 3/20/11 8:16 PM, Nathan Edgars II wrote: On 3/20/2011 8:13 PM, Richard Welty wrote: d suggest using relations to group ways that are parts of named rivers rather than trying to combine the ways. If the only difference between the ways is that NHD assigns a different ID number to them, not combining them seems silly. if the ids are consistent from one release to the next and there is any notion of doing an update later, then combining them destroys useful information. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed cleanup: NHD rivers
This is now complete for the area west of Portland Oregon as a test. http://www.paulnorman.ca/blog/?attachment_id=96 shows the difference. About 99.8% of the data was untouched since it was imported. I checked the other dozen or so ways by hand. -Original Message- From: John Chambers [mailto:jcha...@gmail.com] Sent: Tuesday, March 22, 2011 3:48 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposed cleanup: NHD rivers I know of least one 46006 that I would consider a river (Tussahaw creek) , but doesn't have river in the name, but as bad as other NHD data I've seen is, this little problem will be small. upstream On Tue, Mar 22, 2011 at 4:50 PM, Paul Norman penor...@mac.com wrote: If there are no objections to the retagging part I'll proceed with retagging FCodes 46003 and 46006 as documented on http://wiki.openstreetmap.org/wiki/User:Pnorman/NHDCleanup I will not be joining waterways at this time. -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: Sunday, March 20, 2011 6:52 PM To: 'Richard Welty'; talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposed cleanup: NHD rivers This is the view I subscribe to too. An example of two ways I would want to join would be http://www.openstreetmap.org/browse/way/68711710 and http://www.openstreetmap.org/browse/way/68710322 These differ only in nhd:com_id and they're both really short ways. In any case, I'd like to make it clear that there are two separate parts. The retagging of the ways, and the joining of them. The first one is a serious issue, visible out to z8 in the rendering and hopefully uncontroversial to change. The second one is a less important issue that it seems more debate is required on. For the retagging, I've done up a table at http://wiki.openstreetmap.org/wiki/User:Pnorman/NHDCleanup which explains the changes I'm proposing. I should of thought of a table earlier Also, I need to empathize that any data edited by users since the imports won't be touched without manual review. -Original Message- From: Richard Welty [mailto:rwe...@averillpark.net] Sent: Sunday, March 20, 2011 5:38 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposed cleanup: NHD rivers On 3/20/11 8:16 PM, Nathan Edgars II wrote: On 3/20/2011 8:13 PM, Richard Welty wrote: d suggest using relations to group ways that are parts of named rivers rather than trying to combine the ways. If the only difference between the ways is that NHD assigns a different ID number to them, not combining them seems silly. if the ids are consistent from one release to the next and there is any notion of doing an update later, then combining them destroys useful information. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] border screwup by ToeBee needs reverting
The first of your examples ('015 node) appears to be more accurate than the
node it replaced in one of the ways,
http://www.openstreetmap.org/browse/node/263660932 which was farther away
from the monument (based on NAIP imagery)
In the second one ('476 node), the changeset improved the position of the
node. It wasn't aligned before. In any case, after the changeset it was only
about 8m off according to NAIP imagery.
I'd say that reverting the border fix changeset would be wrong, given the
number of problems it fixed with the borders. I'd say it was definitely
wrong to attempt to revert it over ToeBee's objections.
-Original Message-
From: Nathan Edgars II [mailto:nerou...@gmail.com]
Sent: Friday, March 25, 2011 12:56 AM
To: OpenStreetMap talk-us list
Subject: [Talk-us] border screwup by ToeBee needs reverting
User ToeBee has, in several changesets in February, aligned state
borders to exact lat/long. The problem is that this is not how the
borders are defined; instead they are based on work that the 19th
century surveyors did with the tools they had. Two obvious examples
follow:
http://www.openstreetmap.org/browse/node/158796015/history is the famous
Four Corners:
http://www.deseretnews.com/article/705298412/Four-Corners-marker-212-
miles-off-Too-late.html
http://www.openstreetmap.org/browse/node/158790476/history is the
northwest corner of Colorado, which is also marked by a large monument,
visible on aerials.
It's likely that any border node moved by ToeBee needs to be reverted. I
tried to do this after informing him (he's currently denying there's a
problem), but JOSM's reverter plugin is giving hundreds of conflicts.
This damage needs to be undone.
___
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] Proposed import of IBC data (was RE: [Talk-ca] NAD83-SCRS vs WGS84 Reference systems)
Adding talk-us@ and imports@ to the cc list since this touches the border. The IBC data matches decently with the NAIP and Bing imagery on the border, and very well with my 10cm Surrey imagery. The existing border data in OSM is about 20m away in parts (near monument 32 for example) The proposed tagging is man_made=survey_point ref=32 source=CA-US International Boundary Commission I don't think it's worth the effort to worry about any NAD83-CSRS vs. WGS84 differences. I've uploaded a sample at http://maps.paulnorman.ca/49th.osm -Original Message- From: Richard Weait [mailto:rich...@weait.com] Sent: Sunday, March 27, 2011 6:22 AM To: Daniel Begin Cc: talk...@openstreetmap.org Subject: Re: [Talk-ca] NAD83-SCRS vs WGS84 Reference systems On Sat, Mar 26, 2011 at 3:55 PM, Daniel Begin jfd...@hotmail.com wrote: Hi all, I need someone to confirm the following about reference system... Context: Paul and I are uploading US-Canada boundary monuments/turning points to get a stable and verifiable information. The data is available from their web site and I got the confirmation that the data can be used without any restriction. The data can be found here... http://www.internationalboundarycommission.org/products.html and it is available for NAD27 and NAD83-SCRS reference system. Context: For what I understand, The difference between NAD83-SCRS and WGS84 is 0-2 meters. To get a rigorous transformation from NAD83-SCRS to WGS84 we need to use shift grids describing the shift between NAD83 and NAD83-SCRS. These grids should be available through provincial agencies but I have been told that not all provinces have them available. Question1: Do I understand it properly? Question2: Considering that provided coordinates value/reference numbers can be read directly from their web site, it make sense for me to use NAD83-SCRS directly even if there is a 0-2 meter offset. Does it make sense for everyone? Bonjour Daniel! We do have others on this list with experience in re-projection. I hope they'll join in. I've asked about the shift grids on #osm-dev. If I remember correctly, the current Can-US border came from IBC data. How does the current border line match the monument data that you are considering? Should they be identical and are they? Could we pop this data into a tile overlay layer so we can look at it on existing OSM data (without the import)? Best regards, Richard ___ Talk-ca mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed import of IBC data (was RE: [Talk-ca] NAD83-SCRS vs WGS84 Reference systems)
For the area here, they appear to all have monuments or the imagery is of insufficient quality to determine. What's the difference between a survey point and a turning point? Is it that one has a small change in direction while the other has a large change in direction? For the 49th parallel, all of the monuments are of the form Mon xx or Mon. xx For the other regions, I see some are of the form TP xx. I don't think survey_point=turning_point is what we should use. http://taginfo.openstreetmap.de/keys/survey_point#values shows that it's mainly used to indicate the physical form of the survey point. -Original Message- From: Richard Weait [mailto:rich...@weait.com] Sent: Sunday, March 27, 2011 1:46 PM To: Daniel Begin Cc: impo...@openstreetmap.org; talk-us@openstreetmap.org; Paul Norman; talk...@openstreetmap.org Subject: Re: [Talk-us] Proposed import of IBC data (was RE: [Talk-ca] NAD83-SCRS vs WGS84 Reference systems) On Sun, Mar 27, 2011 at 4:40 PM, Daniel Begin jfd...@hotmail.com wrote: Thank Paul, a really good idea to include others as they are concerned :-) About tagging, I would agree with minor adjustments ... man_made=survey_point - agreed ref= - agreed to reference a monument id However, I would add a prefix for turning points, helping differentiate them from monuments. I propose the prefix tp : ref=tp 123 I'd prefer to see values without spaces, for ease of consuming downstream. Does the source distinguish between monuments and turning points? If not, perhaps following their lead makes sense by using their ref=123, and adding something like survey_point=turning_point, or similar? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What does the community want from a US local chapter?
-Original Message- From: Nathan Edgars II [mailto:nerou...@gmail.com] On 9/30/2011 1:48 PM, Richard Fairhurst wrote: I think you could make a case that OSM in the US is being held back by the community's failure to agree on a common tagging scheme for roads (about five years after every other country settled on one, and with no sign of it being resolved any time soon). Add Canada to the list: http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Highway.2 FRoad.2FCarriageway_Tagging_System From what I've seen when building relations outside of BC, the tagging is fairly consistent across Canada. It's just not documented. I think the difficulties for North American tagging stem from the fact that there is no system of government classifications in some areas that is meaningful for determining what to tag a road as. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Announcement: Address Improvement project
-Original Message- From: Toby Murray [mailto:toby.mur...@gmail.com] The one address component that I have seen missing is suite. We have a couple of places where businesses share housenumbers and use suite numbers or letters. I'm sure this is not uncommon. Some places write it as 123-A on the outside of the building while others actually say 123 Suite A so it's kind of ambiguous whether to just include it in the housenumber or split it into its own tag. But I've started using an addr:suite tag where it is listed as a suite. Since there are only 300 uses in the database I'm guessing no tools make use of this tag yet. I can't speak for certain about in the US, but on one summer work term I lived in a house with an A suffix, and found out lots about addressing when trying to get the cable installers to come to the right house. In this case the A was part of the house number and 112A had no connection to 112. What I see around here more often is suite numbers (e.g. 101, 102) that are placed in front of the number when written out, but sometimes are placed after on forms. Eg http://www.openstreetmap.org/browse/node/1052967131 where I mapped it as addr:housenumber=#104-7885 I don't view these types of addresses as a significant problem because OSM is not well-suited for mapping of multi-story buildings with many shops inside. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Combining State/County Borders Physical Features?
Sent: Saturday, October 15, 2011 11:42 AM Subject: Re: [Talk-us] Combining State/County Borders Physical Features? part 3, of course, is simplification. both 2) and 3) above have a lot of nodes. do we have any criteria stated anywhere about when simplification is in order, and what the target is when it is done? richard In the past when simplifying streams I've used JOSM with max-error set to 1.5, which I believe is in meters. For UBC buildings I used max-error=.1 In the first case I wasn't losing any accuracy since the ways were often off by more than 1.5m. In the second case I was losing accuracy, but the import source was too detailed. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NE2 doing mass retaggings
From: Nathan Edgars II [mailto:nerou...@gmail.com] Subject: Re: [Talk-us] NE2 doing mass retaggings On 10/19/2011 9:31 PM, Paul Norman wrote: He has a history in Canada of deleting data in the same manner http://www.openstreetmap.org/browse/way/50623496/history Are you sure you're not talking about yourself? The consensus on talk-ca@ was that NHS=* did not belong in OSM for a variety of reasons. Basically, it doesn't even correspond to a funding category. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NE2 doing mass retaggings
From: Nathan Edgars II [mailto:nerou...@gmail.com] Subject: Re: [Talk-us] NE2 doing mass retaggings On 10/20/2011 10:56 AM, Paul Norman wrote: From: Nathan Edgars II [mailto:nerou...@gmail.com] Subject: Re: [Talk-us] NE2 doing mass retaggings On 10/19/2011 9:31 PM, Paul Norman wrote: He has a history in Canada of deleting data in the same manner http://www.openstreetmap.org/browse/way/50623496/history Are you sure you're not talking about yourself? The consensus on talk-ca@ was that NHS=* did not belong in OSM for a variety of reasons. Basically, it doesn't even correspond to a funding category. So are you saying that a few mappers can decide that a valid tag cannot be used in their area? What if I decided to remove all local maxspeeds because nobody follows them? No one outside of Canada would tag a road as belonging to the Canadian National Highway System. You are raising a strawman argument by comparing it to maxspeed, which is used in more than one country. In any case, this is not the appropriate list to engage in an extended discussion as to if a Canadian government classification has any value for OSM and should not distract from the other points raised in this thread. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] High-visibility Vests
In another thread, the subject of high-visibility vests came up and I was wondering if there were any of these in North America. The wiki says the existing ones are sold by the OpenCycleMap shop, but they are listed as temporarily unavailable. In any case, shipping clothing from Europe is likely not the best option. Additionally, the vests aren't likely to meet North American high-visibility standards. In my day job I deal with high-vis vests too much, so I am familiar with this subject area. I believe a vest meeting CSA Z96, ANSI/ISEA 107 with MOT style trim would meet the requirements for use on US federally funded rights of way (See Federal Register/Vol 71, No 226/Friday November 24, 2006, p. 67792-67800), BC MOT roadways (Technical Circular T-09/05), other BC roadways (OHSR 8.24 + G8.24-1), Ontario, Saskatchewan, Manitoba, Alberta and I would expect the rest of North America. The FWHA put the normal price of a vest at $25. The maximum area of a non-retroreflective logo on a vest is 100 square cm. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Talk-ca] High-visibility Vests
For various reasons, the pattern used by vests in Canada (X on the back) is not particularly common in the US or Europe. From: Gregory [mailto:nomoregra...@googlemail.com] Sent: Thursday, October 27, 2011 5:04 AM To: talk-us@openstreetmap.org; talk...@openstreetmap.org Subject: Re: [Talk-ca] [Talk-us] High-visibility Vests I think it's better to order them in bulk, which the OpenCycleMap did and is probably why they are unavailable. Meeting a safety standard was a bit attractive so you can use them for other uses that don't care about the logo. I think some European countries require you to have a high-vis jacket in the car for when you break down. Some mappers in the UK like to wear high-vis when cycling, so use their OSM one even when not mapping. When the SotM12 venue is announced it might be could for all countries to see what the interest is and then let Andy Allan (of OpenCycleMap) know or someone do an order of several. Having them available at something like SotM is easier/cheaper than individual deliveries. On 24 October 2011 03:39, Martijn van Exel m...@rtijn.org wrote: I have about a dozen of them and am happy to lend them for mapping party purposes. They look like this: http://schaaltreinen.nl/openstreetmap-hi-viz-vest If it looks a little wrinkly, that's because I brought them from Europe ;) Martijn On Sun, Oct 23, 2011 at 6:12 PM, Paul Norman penor...@mac.com wrote: In another thread, the subject of high-visibility vests came up and I was wondering if there were any of these in North America. The wiki says the existing ones are sold by the OpenCycleMap shop, but they are listed as temporarily unavailable. In any case, shipping clothing from Europe is likely not the best option. Additionally, the vests aren't likely to meet North American high-visibility standards. In my day job I deal with high-vis vests too much, so I am familiar with this subject area. I believe a vest meeting CSA Z96, ANSI/ISEA 107 with MOT style trim would meet the requirements for use on US federally funded rights of way (See Federal Register/Vol 71, No 226/Friday November 24, 2006, p. 67792-67800), BC MOT roadways (Technical Circular T-09/05), other BC roadways (OHSR 8.24 + G8.24-1), Ontario, Saskatchewan, Manitoba, Alberta and I would expect the rest of North America. The FWHA put the normal price of a vest at $25. The maximum area of a non-retroreflective logo on a vest is 100 square cm. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- martijn van exel geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com ___ Talk-ca mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
From: Mike N [mailto:nice...@att.net] Subject: Re: [Talk-us] Address improvement through imports? Splitting ways for maxSpeed, public transport, cycle lanes, route relations, and lane counts are all value-added mapper observations, but still often conveniently span a number of blocks. It would be interesting to know if very heavily mapped areas all trend toward more than 1 way between intersections. From what I've seen, yes. There is just so much detail to add in an urban area. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Take your slice and map it!
From: Martijn van Exel [mailto:m...@rtijn.org]
Subject: [Talk-us] Take your slice and map it!
I don't know how to add a WMS layer in Potlatch (can you?)
There are three options for using a WMS layer in Potlatch that I am aware
of.
1. Use a wms to tms proxy like http://whoots.mapwarper.net/
2. Run your own wms to tms proxy
3. If using mapserver, have it serve tiles.
The latter is the most useful, if the version of mapserver supports it.
You need a URL like
http://192.168.1.5:7201/cgi-bin/mapserv?map=/path/to/mapfile.maplayers=surr
ey2011mode=tiletilemode=gmaptile={x}+{y}+{zoom}
Unfortunately, the ArcGIS mapserver Utah is running doesn't support
mode=tile as far as I can tell.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Semi-import of TIGER 2011 in a small area
From: Phil! Gold [mailto:phi...@pobox.com] Subject: [Talk-us] Semi-import of TIGER 2011 in a small area * Open the resulting .osm file in JOSM and delete everything I didn't want. This was accomplished by selecting all the roads I did want and then inverting the selection. Also, the deletion took a really long time. If I need to do this again, I'll probably use osmosis to cut out a bbox first and then just use JOSM to do the final paring. Giving JOSM substantially more RAM can help with this. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Finding new roads
From: Toby Murray [mailto:toby.mur...@gmail.com] Subject: Re: [Talk-us] Finding new roads On Mon, Jan 16, 2012 at 6:48 PM, Nick Hocking nick.hock...@gmail.com wrote: I believe that OSm's most usefull attribute is to be up to date. The only real way to do this is with a local mapper but bringing the USA up to Tiger 2011 up-to-datedness would be a great start. Are there tools to 1. Compare named OSM roads with Tiger 2011 roads and highlight just the new ones. I forget who originally posted this but the only thing along these lines that I've seen before is to convert new TIGER data to .osm and then load it up as a second layer in JOSM. Change the inactive color to something bright and then load current OSM data on top as the active layer. At an appropriate zoom level the bright colored, inactive background layer with new data will only show where there is not any existing OSM data to blot it out. Turning on wireframe mode will also help. Antialiasing can allow some of the background colour to be visible, but wireframe mode turns this off. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parabens - Voce foi sortedo(a) com 10.000 pontos fidelidade - Clique aqui e resgate.
From: Dave Hansen [mailto:d...@sr71.net] Subject: Re: [Talk-us] Parabens - Voce foi sortedo(a) com 10.000 pontos fidelidade - Clique aqui e resgate. On 03/08/2012 07:58 PM, James Mast wrote: Can somebody PLEASE kill this spam that's been showing up the last few days? I'd appreciate it. I'd suggest turning off spam in your email account, first. ;) Seriously... there's not a whole lot we can do. We can turn on list moderation, but that'll just mean that everyone's posts get delayed. We can also require folks to be members before posting, but that keeps new people away, and keeps folks from cc'ing us on discussions on talk@, for instance. Is turning on moderation for non-members an option? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] The vandalism has begun
Frederik, can we get these reverted? I'd do it myself but I'm not confident enough with the revert tools and I doubt this changeset will revert cleanly. In the particular example of way 44925685, a quick look shows no tags that could not be recovered with TIGER and odbl=clean. As an aside, wasn't the view expressed on the rebuild conference call to go with a v0 concept for ways, in which case parts of the tagging would remain on the 1st? -Original Message- From: Nathan Edgars II [mailto:nerou...@gmail.com] Sent: Sunday, March 11, 2012 1:59 AM To: OpenStreetMap talk-us list Subject: [Talk-us] The vandalism has begun Even before April Fools: http://www.openstreetmap.org/browse/changeset/10842511 I love how portions of US 2, US 83, and US 95 are now in Canada. http://www.openstreetmap.org/?lat=48.562lon=-112.387zoom=11layers=M http://www.openstreetmap.org/?lat=48.812lon=-101.089zoom=11layers=M http://www.openstreetmap.org/?lat=46.5966lon=-116.9202zoom=12layers=M ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Uploads to City of Salisbury, MD
If there are duplicated ways and nodes, perhaps reverting is the best option? From: Marc Zoss [mailto:marcz...@gmail.com] Subject: Re: [Talk-us] [Imports] Uploads to City of Salisbury, MD Dear Nick I would strongly advise to review and revise you conversion scripts. The move to select and delete these duplicated ways with JOSM seems a bit risky. However for the already uploaded data you possibly don't have much choices. Give it a go by using the following in JOSM's find function. tags:1 and closed and sby:bldgtype=* I have also noted that your import has generated quite some duplicate ways (and thus ton of nodes). JOSM's validator is your friend - check the data with it and remove automatically the dupes - better do it twice. Best regars Marc On 22.03.2012, at 00:08, AJ Ashton wrote: Hi Nick, The quality of these building footprints looks great, and it's the kind of thing I personally like to see imported because it's tedious to trace them accurately and difficult/impossible to capture them with GPS. And as you mentioned it can assist future placement of shops, amenities, etc. However, from downloading and looking at a random area in JOSM, I'm seeing some problems. You can't tell from the renders, but many buildings are there more than once as separate overlapping objects. Example: - http://www.openstreetmap.org/browse/way/153813132 - http://www.openstreetmap.org/browse/way/153808317 - http://www.openstreetmap.org/browse/way/153849919 It looks like the problem objects all have a 'sby:bldgtype' tag and no other tags, so it should be a straight-forward fix. I not exactly sure the best way to go about that, though. -- AJ Ashton ___ Imports mailing list impo...@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remapping coastlines
From: Toby Murray [mailto:toby.mur...@gmail.com] Sent: Saturday, March 24, 2012 1:22 AM To: talk-us Subject: [Talk-us] Remapping coastlines Paul Norman has been looking at coastlines as it relates to the license change. Turns out we have a big problem along the west coast. Does anyone know what the best usable source for coastline data in the US is? Surely there is something better than PGS? I poked around looking at some NHD data but didn't see an explicit coastline data set. But since I haven't worked with NHD much and, being in a landlocked state, haven't touched coastlines at all I'm looking for some input from someone with more experience on the subject. Thoughts? Pictures of the west coast and the great lakes, the two problem areas http://maps.paulnorman.ca/coastlines-na-lakes.png http://maps.paulnorman.ca/coastlines-na-west.png The east coast and gulf aren't too bad in comparison. Is adopting changesets an option if blars just uploaded PGS data for the west coast? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Proposed import: GeoBase Coastlines into Northwest Washington state
I propose replacing the PGS coastlines (largely imported by blars) in Northwest Washington state with GeoBase coastlines. GeoBase data covers part of NW Washington state (e.g. Canadian NHD area 08HAD00 covers the Washington coastline from Port Angeles to Port Townsend). Most of the existing PGS coastlines are scheduled for removal and this is a higher accuracy data source. GeoBase is well documented from Canada, so I'm just sending this to talk-us@. Sample data, imported from the same source, can be seen with the BC coastline from Alaska to Vancouver. I will not be replacing any objects except coastlines from PGS and coastlines traced from landsat or other low resolution imagery. The impacted coastlines will stretch from the northwest tip of the coastline near Neah Bay to Port Townsend and the Canada-US border to the coastline west of Anacortes as well as the San Juan islands. The tagging will be natural=coastline source=GeoBase, with appropriate changeset source tags indicating the exact file. The ways will undergo a mild simplification to reduce overnoding. I believe the basins I will be looking at are 08MHA00, 08MHF00, 08HAC00, 08HAD00, 08HA0X2 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed import: GeoBase Coastlines into Northwest, Washington state
From: Wim Lewis [mailto:w...@.org] Sent: Tuesday, March 27, 2012 11:27 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposed import: GeoBase Coastlines into Northwest, Washington state On Sat, 24 Mar 2012 17:50:13 -0700, Paul Norman penor...@mac.com wrote: I propose replacing the PGS coastlines (largely imported by blars) in Northwest Washington state with GeoBase coastlines. GeoBase data covers part of NW Washington state (e.g. Canadian NHD area 08HAD00 covers the Washington coastline from Port Angeles to Port Townsend). Most of the existing PGS coastlines are scheduled for removal and this is a higher accuracy data source. I've retraced significant chunks of the coastline around Hood's Canal and the Olympic Peninsula from higher-resolution imagery and occasional local knowledge (inlets, flats, rocks, spits). I'm all in favor of importing higher quality coastline, since PGS is fairly coarse, but I hope that it is done in a way that doesn't destroy other work that's been done. I believe I've managed to preserve all the edits. The data doesn't go as far south as the hood canal, it just covers the north coast of the Olympic peninsula, which was largly PGS. I preserved data where I saw it was better, but if I accidentally replaced any good data with less accurate data let me know where and I can revert that section. On an aside, if anyone retraces PGS coastline, please change the source=PGS tag ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] City boundaries on the Canada/US border
There are a significant number of cities in BC and Washington which have borders that in practice[1] coincide with the Canada/US border. Currently in OSM these are represented with many nearly-overlapping ways. The Canada/US border here consists of the BC-WA border, BC-ID border, BC-MT border, AB-MT border, SK-MT border, SK-ND border, etc. There are separate ways for the cities on the Canada side and cities on the US side. I am considering replacing these with one set of non-overlapping border ways. This would involve splitting the ways whenever a city ends or begins on either side of the border. The border would then consist of a BC-WA border in the water, a Surrey-Whatcom County border (in the water), a White Rock-Whatcom County border, a Surrey-Whatcom county border, Surrey-Blaine border, Langley-Blaine border, Langley-Whatcom County border, Abbotsford-Whatcom County border, Abbotsford-Sumas border, etc. This would reduce the number of ways present when you download a section of the border and have many advantages. The one big disadvantage is that it would boost the number of ways in the Canada and US relations. This increases the chance of conflicts and also increases the number of places it could be broken. Either way, the Canada/US border will remain very complex with so many different boundary relations ending there. If I do this, I will also align the borders to the IBC data (PD). I've investigated the accuracy of their data, and it agrees with the markers on the ground to within 10cm. I believe the most significant source of error in their data is the NAD83 to WGS84 conversion. [1]: The actual legal situation is much more complicated and serves as a good example of the problems that arise when you define what is supposed to be one line in multiple ways. The biggest oddity is that the Washington border extends out of the United States into Canada. All of the other oddities are just a few meters at most. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] City boundaries on the Canada/US border
From: Jeffrey Ollie [mailto:j...@ocjtech.us] Sent: Friday, March 30, 2012 8:21 AM To: talk-us Subject: Re: [Talk-us] City boundaries on the Canada/US border On Fri, Mar 30, 2012 at 9:50 AM, Toby Murray toby.mur...@gmail.com wrote: The problem with conflicts is if someone is splitting ways that are members of the US border relation down in Arizona while you are doing the same up in Washington. But in general I don't think this will be a huge problem. Much of the US border is either in water or sparsely populated areas where frequent edits are unlikely. Could this be mitigated somewhat by the use of super relations? IE on relation each for the US-Canada, US-Mexico, US-Pacific, US-Atlantic borders tied together with one super relation? Do any of the tools support these? Thinking about it, people shouldn't be splitting the ways that frequently, unlike the interstates which frequently have their member ways edited. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] City boundaries on the Canada/US border
From: Nathan Edgars II [mailto:nerou...@gmail.com] Sent: Friday, March 30, 2012 10:02 AM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] City boundaries on the Canada/US border On 3/30/2012 12:55 PM, Paul Norman wrote: From: Jeffrey Ollie [mailto:j...@ocjtech.us] Could this be mitigated somewhat by the use of super relations? IE on relation each for the US-Canada, US-Mexico, US-Pacific, US-Atlantic borders tied together with one super relation? Do any of the tools support these? I don't know, but don't map for the tools :) It would be nice if Mapnik crosshatched the inside of the boundary (mainly for places where not everything is incorporated). Can you tell me at a glance what here is inside or outside Orlando city limits? http://www.openstreetmap.org/?lat=28.5138lon=-81.35903zoom=17layers=M :) Yikes, that's complicated. I'm not sure that hatching will help much with a situation like that in general - what if the boundary between two cities is like that? Both would be inside a boundary and have the same shading. Nominatim will show you what is inside, e.g. http://nominatim.openstreetmap.org/details.php?place_id=153627246 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on remapping
From: David Litke [mailto:dwli...@comcast.net] Subject: Re: [Talk-us] Update on remapping I am a newbie, wonder why the current license change downtime is affecting data. Does the new license make some existing data illegel and hence they are removing it? Or are they making use of the downtime to do additional QC edits/deletions? The downtime is for two purposes. The first of these is a server move and postgresql upgrade for the database server. This is what is currently going on and is just turning the database on the old server to a file, copying it to the new server and loading it. The second stage of the process is for the license change. Right now there are two types of data in OSM: those which can be licensed under CC by-sa and those which can be licensed under CC by-sa or ODbL. The goal of the license change is to remove the content which can only be licensed under CC by-sa so all the data can be licensed under the ODbL. After this removal is completed then OSM will be made available under the ODbL license only. Until the rebuild is complete and a new planet file is published under the ODbL OSM remains published only under CC by-sa. This is, of course, a simplification, but should get the idea across. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Link to BadMap?
LA area on BadMap: http://cleanmap.poole.ch/?zoom=10 http://cleanmap.poole.ch/?zoom=10lat=34lon=-118layers=00B0 lat=34lon=-118layers=00B0 From: Charlotte Wolter [mailto:techl...@techlady.com] Sent: Sunday, April 08, 2012 1:34 PM To: talk-us@openstreetmap.org Subject: [Talk-us] Link to BadMap? Hello everyone, Does anyone know if there is a link to BadmaMap somewhere on the OSM Web site? So far I haven't been able to find it to fix LA stuff. Charlotte Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady The Four Internet Freedoms Freedom to visit any site on the Internet Freedom to access any content or service that is not illegal Freedom to attach any device that does not interfere with the network Freedom to know all the terms of a service, particularly any that would affect the first three freedoms. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] importing bus stops
From: Martijn van Exel [mailto:mve...@gmail.com] Subject: [Talk-us] importing bus stops Hi, Anyone here with experience importing bus stops? Any particular considerations? To make it more concrete, I have permission to import all UTA stops. They come in a shapefile similar to the one available for download here: http://gis.utah.gov/sgid-vector-download/utah-sgid-vector-gis-data- layer-download-index?fc=BusStops_UTA (That particular set of files is out of date, though) There's a number of properties that would map to OSM nodes pretty nicely: MAILBOX - create a separate node amenity= LIGHT - lit=yes SHELTER - shelter=yes BENCH - bench=yes (?) Unfortunately, all of these attributes are null. I was planning to just use what I know which is highway=bus_stop for the bus stops, and railway=tram_stop for the light rail stops. What differentiates them in the shapefile? I don't know the area so I don't know where there are any light rail stops To get back on topic, if anyone wants to help out devise a mapping from UTA stops file to OSM, I'd welcome some help. I've never done a local import before, and I'm not a particularly big fan of imports, so I want to proceed with caution. I threw together a draft translation file at https://github.com/pnorman/ogr2osm-translations/blob/master/utahbus.py To go farther, a local would need to provide some knowledge. 1. Are there unique ref numbers on the stops? Every bus stop here has a unique ID on its sign. If so, do these correspond to LOCATIONID? 2. What are the names of some bus stops? If they're named by the street they're on and the cross-street it should be possible to construct a name from the shapefile for each stop. (e.g. northbound far side 1st ave and main street) 3. The shapefile appears to have address data for each stop. Should the addr:*=* information be added? I also noticed a couple of other things when looking at the data. The spatial accuracy is decent. Some stops are a few meters off and on the road, not the sidewalk, but they're all near the shelters that I can see. Conflating this data with the existing data will be the hard part. If there hasn't been too much manual mapping of bus stops this could be done by hand. If there has, then you need to look at how to conflate the data. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
From: Alan Mintz [mailto:alan_mintz+...@earthlink.net] Sent: Monday, April 16, 2012 6:18 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Excellent progress, u.s. At 2012-04-16 14:06, Nathan Edgars II wrote: Or you can simply add odbl=clean if there's nothing ungood about the object (e.g. it was split from a TIGER way and the splitting is something you would have done anyway). Is this really sufficient? Can someone from the redaction squad comment? Can I protect/bless a way or node and prevent its redaction simply by (in good faith) adding this tag? Any ways that I have tagged with source=some_imagery;survey;image means I have aligned against imagery and personally photo-surveyed at least one street-name sign along it. It would certainly help to be able to just add odbl=clean to such ways that are complained about by the plugin instead of having to delete and re-add them, fix the intersections, and fix the relations. I'm also more likely to get it done, since it multiplies my productivity many times. If you've verified all of the tags on it from ODbL compatible sources (e.g. a survey you did), you can add odbl=clean and the way will be kept. The nodes may be deleted if they were created by a decliner. In this case what I generally do is select all the dirty nodes in the way and delete them, then re-trace the way. If all blars did was split the way then the nodes will still be clean. If he refined the geometry then the geometry will be reverted to what it was before. What I've been doing a lot of is going to a dirty way, deleting all the tags and then copying all of the tags from CanVec (Canadian equivalent of TIGER, but more reliable), pasting them to the way and adding odbl=clean. You have to be careful that you don't remove other clean data (mainly cycle route information here). To check that I open up the history (Ctrl-H) and see who added it. Generally it's not a decliner, so I can keep the tag. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] City boundaries on the Canada/US border
I started working my way across and the cleanup is progressing. I'm up to monument 31 so far. Once I get out of populated areas it should go quicker. The monuments are physically present on the ground, so their location could be improved by more accurate surveys. However, I doubt if any consumer GPS would be more accurate. The points agree with multiple sources of accurate imagery within the resolution of the imagery. I settled on ibc:ref for the turning points which don't have a survey_point on the ground. Those refs help me keep track of where I am. Starting in the water and going east, the border is now Delta-Whatcom County Surrey-Whatcom County White Rock-Whatcom County Surrey-Whatcom County Surrey-Blaine Langley-Blaine Langley-Whatcom County Abbotsford-Whatcom County Abbotsford-Sumas -Original Message- From: Toby Murray [mailto:toby.mur...@gmail.com] Sent: Friday, March 30, 2012 7:51 AM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] City boundaries on the Canada/US border On Fri, Mar 30, 2012 at 7:18 AM, Alexander Roalter alexan...@roalter.it wrote: Am 30.03.2012 11:17, schrieb Paul Norman: There are a significant number of cities in BC and Washington which have borders that in practice[1] coincide with the Canada/US border. Currently in OSM these are represented with many nearly-overlapping ways. The Canada/US border here consists of the BC-WA border, BC-ID border, BC-MT border, AB-MT border, SK-MT border, SK-ND border, etc. There are separate ways for the cities on the Canada side and cities on the US side. ... This would reduce the number of ways present when you download a section of the border and have many advantages. The one big disadvantage is that it would boost the number of ways in the Canada and US relations. This increases the chance of conflicts and also increases the number of places it could be broken. I merged the us/canadian border with the north dakota, minnesota and montana state borders and also county borders a while ago, and I agree that there should only be one way for one part of the border, this line being shared in all affected boundary relations. I don't really think this will increase conflicts, as if you delete one way of a border, all affected relations will be notified (at least in JOSM it's impossible to download a way without downloading all relations this way is connected. I did include city boundaries where available, but this was the case only on one city (Emerson, MB). In Europe, nearly all borders are made up of individual municipality border stretches (I once loaded italy's circumference, made up of 2500 ways). The problem with conflicts is if someone is splitting ways that are members of the US border relation down in Arizona while you are doing the same up in Washington. But in general I don't think this will be a huge problem. Much of the US border is either in water or sparsely populated areas where frequent edits are unlikely. I've done some splitting of ways for counties along both the north and south border so I think this would be fine too. Overlapping ways are a pain to deal with. Then again relations can be a pain too :) But at least they are cleaner. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] 25or6to4 NHD imports
The users 25or6to4 and 25or6to4_upload have been importing NHD data in Louisiana without the required consultation and with a few other problems with the import guidelines. Among other things, I asked them to talk to the community to figure out what should be done with the data they have already imported. Since they haven't responded, I'm asking the community for them. What should be done with this data? It could be reverted or left. The data does seem an improvement on the PGS that was there before, but I'm not a local so I don't have any strong opinion. Paul Norman For the DWG ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Fresno castradal imports
I happened across an import of Fresno castradal data from mid-2010 in the Fresno area. http://www.openstreetmap.org/?lat=36.77lon=-119.81zoom=15 is the general area but I haven't fully explored the extents. For a view of the data, see http://maps.paulnorman.ca/imports/review/fresno.png Based on source tags this import was of about 280k ways and their associated nodes. This likely totals about 1M objects. The tagging of a typical lot is as follows: attribution=Fresno_County_GIS fresno_APN=44329204 fresno_TX_area_CD=5199 fresno_lot_area=0.17 fresno_lot_depth=124.0 fresno_lot_width=60.0 landuse=residential lot_description=LOT 13 CLINTON TERRACE NO 2 lot_type=single family residential properties other_use=S primary_use=S01 secondary_use=000 source=http://www.co.fresno.ca.us/%5Cdepartmentpage.aspx?id=16313 Many lots have the fresno_lot* tags as 0.0. This is clearly absurd and the object's tags are inconsistent with its geodata. There are a number of problems with this data. These include 1. It is castradal data. The consensus is against dumping castradal data into OSM. 2. The tagging hasn't been converted to OSM values. The other_use, primary_use and secondary_use should map to something or perhaps not have been imported. 3. There are tags indicating the size of the lot. This duplicates the OSM geodata 4. Some lots are split in half, for example the school in the picture. 5. There aren't many curves, but what curves I can find are overnoded. 6. Some objects have no OSM tags at all. For example, http://www.openstreetmap.org/browse/relation/957260 or http://www.openstreetmap.org/browse/way/61615684 have no tags except for metadata from the import. 7. Some objects don't appear to correspond to anything on the ground. http://maps.paulnorman.ca/imports/review/fresno2.png is an example of this. The import is approximately the same age as the Bing imagery. 8. There are duplicate nodes where data was imported on top of other data. For example, http://www.openstreetmap.org/browse/node/768314177 http://www.openstreetmap.org/browse/node/767799968 http://www.openstreetmap.org/browse/node/767770150 With all of these problems I cannot think of any ways to fix the problems short of reverting the import. The tagging problems could be fixed by a script but the inherent problems of castradal data cannot be fixed without essentially deleting most of the import anyways. I propose to delete unmodified objects from this import. I will attempt to preserve areas like schools and fix them if possible. It should be possible to keep most of them but I won't be able to be sure until I get into the removal. Such a removal would have to be timed around the import and mechanical edit restrictions that will be in place during the rebuild process. If it occurred before or after the rebuild would depend on when the rebuild process starts and how long the consultation about this proposal takes. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Fresno castradal imports
From: Toby Murray [mailto:toby.mur...@gmail.com] Subject: Re: [Imports] [Talk-us] Fresno castradal imports On Thu, Apr 26, 2012 at 9:39 AM, Martijn van Exel m...@rtijn.org wrote: Hi, On Thu, Apr 26, 2012 at 12:54 AM, Paul Norman penor...@mac.com wrote: I happened across an import of Fresno castradal data from mid-2010 in the Fresno area. http://www.openstreetmap.org/?lat=36.77lon=-119.81zoom=15 is the general area but I haven't fully explored the extents. For a view of the data, see http://maps.paulnorman.ca/imports/review/fresno.png A few observations: 1. It is castradal data. The consensus is against dumping castradal data into OSM. I am not aware of such a consensus - consensus among who? Is it documented? I would expect such a consensus to appear in the Import Guidelines but it doesn't. Or do you mean there's a consensus against dumping data into OSM in general? If by 'dumping' you mean 'importing without consulting the community and without giving proper thought to attribute mapping and generalization / normalization of geometries' then yes, I'd say there's a consensus against doing that. I don't see why we would not cherry-pick useful and good cadastral data for import into OSM, however. It may be our only source of things like building outlines (are those generally in cadastral data in the US?) or address data in many parts. I don't mean to be nitpicking here, I just want to clarify what this consensus actually is so people looking for guidance on importing in the future can be more fully informed. [...] 8. There are duplicate nodes where data was imported on top of other data. For example, http://www.openstreetmap.org/browse/node/768314177 http://www.openstreetmap.org/browse/node/767799968 http://www.openstreetmap.org/browse/node/767770150 With all of these problems I cannot think of any ways to fix the problems short of reverting the import. The tagging problems could be fixed by a script but the inherent problems of castradal data cannot be fixed without essentially deleting most of the import anyways. Are these problems inherent of cadastral data in general, of this dataset in particular, or of the way this import was conducted? I propose to delete unmodified objects from this import. I will attempt to preserve areas like schools and fix them if possible. It should be possible to keep most of them but I won't be able to be sure until I get into the removal. The list of issues is long enough and the issues serious enough to warrant a revert. What I'm missing from this list is the issue I consider to be the most serious, which is that this user apparently has not consulted with anyone in the community about this import. Or has he/she? I think the area where there is fairly good consensus is that mass imports of plot boundaries is not welcome in OSM. There was an attempt last year at doing this in Arkansas that ended horribly with a blocked account and a couple hundred thousand empty nodes. There was also the more recent proposed import of Spanish cadastre data. I've made use of local lots information occasionally but there I'm importing a single object at a time, generally for the name of a school. In this case we have another instance of someone not considering the consequences of their import on the OSM community. Even if the data is good and valid (which doesn't seem to be a proven point in this case) if current tools are not able to deal with it, perhaps the import should wait and effort put into improving tools first. There is a lot more awareness of what makes a bad import now than there used to be. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Waterway directionality in drainage canals
From: Nathan Edgars II [mailto:nerou...@gmail.com] Sent: Saturday, April 28, 2012 2:24 AM To: Tag discussion, strategy and related tools; OpenStreetMap talk-us list Subject: [Talk-us] Waterway directionality in drainage canals It's the standard to draw a waterway in the direction of flow. I've questioned this several times, but it's an ingrained default. My question is more specific: what happens to a drainage canal that reverses direction? I offer the Everglades and surrounding agricultural land as an example. There are huge water conservation areas that store water. When it rains, gates are closed and opened to direct water into these. During a drought, gates send water back out into the canals for local use. When there's a big storm, water will instead go directly out to sea. So there are a lot of major canals that have no fixed direction. How should these be mapped? Is there any existing scheme that can show how water flows under different conditions? The same issue came up with minor drainage ditches and cranberry fields here. They're used to drain sometimes and sometimes to flood the field for harvest. I came up with the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/directional for directional=* but it's abandoned. One weakness with the proposal is that unknown values are a special case of directional=no, not directional=yes ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
See http://lists.openstreetmap.org/pipermail/talk-us/2012-April/008032.html for the full discussion around the removal In summary: - The Fresno import has a number of issues - No one is opposed to removal if there are no easier options for cleaning up the data - No one has proposed an easier option Given this, does anyone object if I go ahead with the proposed deletion of unmodified objects from the imports, attempting to preserve areas like schools and fix them if possible. I would time it to not be going on at the same time as the rebuild as to not impose additional load on the servers and to reduce the risk of conflicts. My initial estimates were 280k ways and a total of 1M objects. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
From: Paul Johnson [mailto:ba...@ursamundi.org] Subject: Re: [Talk-us] Fresno castradal imports On Fri, May 4, 2012 at 1:37 AM, Paul Norman penor...@mac.com wrote: See http://lists.openstreetmap.org/pipermail/talk-us/2012-April/008032.htm l for the full discussion around the removal In summary: - The Fresno import has a number of issues - No one is opposed to removal if there are no easier options for cleaning up the data - No one has proposed an easier option Given this, does anyone object if I go ahead with the proposed deletion of unmodified objects from the imports, attempting to preserve areas like schools and fix them if possible. More information isn't necessarily bad; I think it might be better to try to refine the imported data over time if possible. To clean up http://maps.paulnorman.ca/imports/review/fresno.png I would start by deleting most of the data. A couple of users, one local, have commented that the issues with the import make it difficult to edit in the area. I really can't see a way short of deleting it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
From: Nathan Mills [mailto:nat...@nwacg.net] Subject: Re: [Talk-us] Fresno castradal imports On 5/4/2012 4:21 PM, Ian Dees wrote: To the contrary, this whole conversation started because we received multiple complaints about this area from mappers who wanted to create data in this area but couldn't because of too much data. In that sense, this data is already handicapping the usefulness of OSM because it's deterring mappers from adding data to the area. That's a tooling problem, not a data problem. As an aside, parcel data is completely verifiable. Yes, it's a terrible pain in the butt, but it is perfectly possible to look up land records and survey the points or do it using a map. I've occasionally thought it would be nice to have a plugin for JOSM that could turn a metes and bounds description into a polygon. Copying from same source (the city) doesn't make it verifiable. Going to the site and surveying it is verifying. Parcel data sometimes relates to what is on the ground, but you can't always assume that. The second image in my original message was a good example of the parcels not representing anything on the ground[1]. The imagery and the import are from about the same date. I have observed similar issues with all other parcel data I have looked at. [1]: http://maps.paulnorman.ca/imports/review/fresno2.png ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
From: Paul Johnson [mailto:ba...@ursamundi.org] Subject: Re: [Talk-us] Fresno castradal imports On May 4, 2012 5:41 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: ...and we need to examine what our existing user tools and server processing and storage resources are and how they can handle the amount of data desired before just blindly throwing many times the existing data size at them. In Bakersfield, the building outlines and some landuse and other objects inflated the data size by ~1000%. Perhaps this makes for a good test case. By the way, didn't Spain and France both go through something similar not that long ago? No. The French community found property lot data to be not worth importing. The Spanish data that was eventually proposed for import did not contain lot data. I'm not sure if there's a new proposal in the works but as it stands the Spanish import is just for roads and gardens. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
From: Alan Mintz [mailto:alan_mintz+...@earthlink.net] Sent: Friday, May 04, 2012 3:06 PM To: talk-us@openstreetmap.org; impo...@openstreetmap.org Subject: Re: [Talk-us] Fresno castradal imports At 2012-05-04 01:37, Paul Norman wrote: See http://lists.openstreetmap.org/pipermail/talk-us/2012-April/008032.html for the full discussion around the removal In summary: - The Fresno import has a number of issues - No one is opposed to removal if there are no easier options for cleaning up the data - No one has proposed an easier option ? Both SteveA and Nathan Mixter (the original contributor) have responded in this thread, co-operatively. Yes. Stevea said it looked like it needed to be reverted in whole and nmixter said that there are issues and said if it comes to a revert, fine. Quotes below. No one laid out a plan for fixing the data and no one volunteered to clean it up. In the current discussion new people have commented who did not do so previously but still no one has come up with an alternative plan to clean it up. If someone believes that there is an alternate way to clean this up, please propose it and volunteer to carry it out! From: stevea [mailto:stevea...@softworkers.com] Subject: Re: [Talk-us] Fresno castradal imports However, as we now see, nmixter has sprayed Fresno with a large data upload, which looks to me (sorry, Nathan) like something which needs to be reverted in whole. As already noted here, many tags are superfluous, it is quite likely that good tests that Validator would have violently complained about were undone or simply ignored and uploaded anyway, and Nathan appears to not have tried to achieve consensus in a way that would have prevented this. That is the crux of the problem, not his raw data (which with some improvement and more consensus, can truly turn into something appropriate for OSM, in my opinion). From: Nathan Mixter [mailto:srmix...@hotmail.com] Subject: Re: [Talk-us] Fresno castradal imports Thanks for everyone's comments. I do take pride in making sure my imports are good. That said I realize there are issues with the Fresno import, one of my first imports. But I am not sure if we need to throw out the baby with the bath water just yet. If it comes to that, fine. I think the problems with the import can be fixed. I am surprised it took two years to mention and then from a person from Canada who I guess is doing a review for the license. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] 25or6to4 NHD imports
Minutely diffs are currently running from http://planet.osm.org/redaction-period/ You should read the caution first before consuming. From what I saw the imports were fairly clean. Some large objects, but that's to be expected with the large lakes in the region you were working in. If you're reviewing each object as you add it, which is certainly manageable with a size limitation, then this kind of falls into the grey area between an import and not. If you're running shp-to-osm.jar with the rules on the wiki you should be careful on some of the less common features. Lakes and such are likely to be fine but some of the less common NHD FCode to OSM tag mappings aren't great. Again, you're not likely to run to big issues if you stick to 0.5 square km areas since this will exclude most of them. From: Jason Straub [mailto:strau...@yahoo.com] Sent: Thursday, May 03, 2012 1:44 AM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] 25or6to4 NHD imports Howdy, After discussion with Toby, I am updating the list with my import efforts. First, hopefully this message goes through, as none of my previous ones have worked... Second, was introduced to a better way to create a new account, so the TexasNHD account will be used for uploads. Third, I have been taking the NHD shapefiles, pulling out only the areas more than 0.5 km^2 for this round of uploads. This edited shapefile was run through shp-to-osm.jar with the NHD rules file on the wiki, then uploaded piece by piece through JOSM. For error checking, have then redownloaded the areas that were uploaded and doublechecked for errors/open ways/dupe notes/etc. Once (if) we have minutely diffs going into the APIs, I will do a triplecheck for any more glitches. Jason 25or6to4 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address placement (was: Fresno castradal imports)
-Original Message- From: Toby Murray [mailto:toby.mur...@gmail.com] Sent: Friday, May 04, 2012 1:18 PM To: OpenStreetMap talk-us list Subject: Re: [Talk-us] Address placement (was: Fresno castradal imports) Moving this to a new thread because there is no address data in the Fresno import so this discussion is completely irrelevant. I believe NE2 started a thread about this a while ago and there wasn't too much response but since it came up again... On Fri, May 4, 2012 at 2:51 PM, Paul Johnson ba...@ursamundi.org wrote: On Fri, May 4, 2012 at 12:47 PM, Ian Dees ian.d...@gmail.com wrote: Because that information is useless in OSM. It was out of date the second someone ran the upload script and unless the city of Fresno decides to switch to OSM for their official tax plat information (which I'm pretty sure would be illegal in most jurisdictions), no one in the community can improve it. We should get rid of it. Property lines are still observable phenomenon, though. Depending on jurisdiction, it might require surveying from the nearest benchmark, but in many cases, there's markers embedded in the nearest curb or other devices indicating the most recent plot boundary. I mentioned the address nodes because it would be the only useful data to keep in OSM. As Toby mentioned, there's no such data. Though the address belongs to an area, so it would make sense to keep the corresponding boundary. Does it? Certainly for official records such as taxes it does. But this is outside of OSM's domain. In OSM, the use case for address data is geocoding and I would argue that general use geocoding users would rather get a building outline or even a node at the main entrance of a location, not the centroid of the property. In Fresno this may be pretty much the same thing but in less populated areas, the plot might be rather large and you would definitely want the address data to be where the actual residence is. There isn't a one-to-one relationship between addresses and lots. Strip malls both here and in the US will sometimes have an entirely different address (not just suite number) for each store even though they may be on one lot. Similarly you can get multiple buildings on one lot with different addresses. I have seen this both here and with some US data. These exceptions are less common for residential areas but you still see some. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] NHD data changes
I've been looking at the NHD data from the USGS site and have noticed a few recent changes from how they were described on the wiki. 1. The viewer has changed. http://viewer.nationalmap.gov/viewer/nhd.html will bring up a map you can use to download NHD data. This viewer does not work in Chrome but does work in IE. Subregions are pre-staged downloads, the others will take some time before you can download. Subregions can be directly downloaded from ftp://nhdftp.usgs.gov/DataSets/Staged/SubRegions/PersonalGDB/HighResolution/ Most subregions are available as a new NHD 931v210 file but some are still being generated. 2. NHD data is now available only as File Geodatabases (File GDBs, .gdb) and Personal Geodatabases (Personal GDBs, .mdb). My understanding is the default builds of QuantumGIS and GDAL on Windows can open Personal GDBs. On linux gdal can be compiled with drv_mdb or the pgeo driver can be used for Personal GDBs, or the filegdb driver can be used for File GDBs. This is moderately technical. 3. The NHD attributes changed with NHD v2.1. All the old mappings of NHD FCodes to OSM tags are outdated. For rivers and streams nothing has changed but others have. I haven't found a list of the 2012 changes. The two current FCode lists I am aware of are http://nhd.usgs.gov/userGuide/Robohelpfiles/NHD_User_Guide/Feature_Catalog/H ydrography_Dataset/Complete_FCode_List.htm and http://nhd.usgs.gov/NHDv2.1_poster_3_23_2012.pdf If you are planning something where you will be checking each object's tagging this will not affect you too much, although you may encounter more objects you have to retag. If you are considering proposing any kind of NHD import where you don't check each option I suggest you wait. I am working on a translation file but it takes a fair amount of time. There are a *lot* of FCodes and I need to look at some of each in multiple areas to see the appropriate tagging. Not all FCodes appear in all areas and what seems appropriate in one area may not be for all areas. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Road Expansions and Seattle Imports (if you're the Seattle importer, please read!)
From: Serge Wroclawski [mailto:emac...@gmail.com] Seattle importer, please read!) Getting back to the current TIGER expansion, I decided it would be a mistake to try a large scale import without having some way of ensuring that the uploads were being done correctly, and so I've been working on a queue based uploader. It will take these issues into account, handle retries, etc. Not to discourage you from the queue based uploader which would be generally useful, is it necessary in this case? When you have an interrupted import you don't know what you have to still upload without some work. In the name expansion case, couldn't you generate a new extract and run the code again? Many bulk-modification and bulk-deletion process can be run safely multiple times and I imagine this one could too. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] UVM-SAL Buildings
I have a few specific comments, and some more general ones From: William Morris [mailto:wboyk...@geosprocket.com] Subject: [Talk-us] UVM-SAL Buildings Howdy Folks, Trying this again, after a hiatus, here is a sample of a few hundred buildings from a UVM-SAL land use classification. In this case it's for an area just west of D.C. in Montgomery County, MD. I offer it for your consideration before I pull the import trigger: Before importing, don't forget to follow the other steps in the import guidelines about documenting it on the wiki. http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm Some steps I've taken to make it community-friendly include: - Removed all buildings that intersected existing OSM features - Removed all buildings smaller than 5000 square meters in area, since those residential structures weren't being very well-detected anyway - I hopehopehopehope the footprints survived their trip from QGIS through ogr2osm to JOSM (If there's anything wrong with the tags please let me know so I can solidify the process) Thanks again to Andrew Guertin for adapting ogr2osm so perfectly. Python has never been so easy. I noticed the following issues: The AREA and PERIMETER tags are superfluous - the area and perimeter can be trivially computed from the geodata. The LandCover tag also doesn't seem to serve any purpose as it only ever has one value. There are building=yes tags on ways in multipolygons - these should be on the MP, not on the ways. Did you run it through ogr2osm and then select type:way in JOSM by any chance? It would be better to write a translation file to apply the appropriate tags to the appropriate objects. If you did this, try my version of ogr2osm at https://github.com/pnorman/ogr2osm and let me know if the problem still occurs, since then it would be a bug. The detection seems pretty good. I was only able to find one false-positive and a couple places where buildings had merged together, as well as a couple of places where one building ended up split. Some of the ways seem a bit over-noded. Normally I'd suggest JOSM's simplify way tool but I'm guessing there might be a more effective point in the workflow to do this. Buildings tend to be rectangular and have a lot of straight lines so it's really noticeable where these don't. Errors which would not be particularly noticeable on a forest or a lake become more so on buildings. I'm hesitant to suggest a fix for this. I'm also not sure about the usefulness of the data. If a user later comes along and wants to improve it, it'd be faster to delete and recreate it than to improve the ways. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] UVM-SAL Buildings
From: Phil! Gold [mailto:phi...@pobox.com] Subject: Re: [Talk-us] UVM-SAL Buildings * William Morris wboyk...@geosprocket.com [2012-06-01 12:53 -0400]: is orthogonalization worthwhile in this case? I'm not sure it is. I tried using JOSM's orthogonalization tool on a number of buildings and every time got a result that was worse than the original data in terms of being misaligned with the imagery. Most of them ended up with lines rotated close to 45 degrees from the actual building's walls (i.e. JOSM's orthogonalization was almost maximally bad in this case). JOSM's orthogonalization can sometimes give very unusual results. If you have a bunch of buildings in an area all aligned if you select the buildings, select two nodes in a line (e.g. nodes from the street where the buildings are aligned with the street) and then orthogonalize it will do everything relative to the line joining those nodes which will often give better results. I'm not sure that the above method would actually help in this import. It might be an inherent problem with the data that the buildings end up blobby. Personally, I'm coming down on the side of it's too blobby as-is. Perhaps there's some way to make the building-recognition algorithm make less blobby buildings? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Creating PDF maps
You're asking two separate questions, one is on creating a PDF map, the other is a style sheet that shows something other than what osm.xml (the standard style on osm.org) does. I wrote mapbook (https://github.com/pnorman/mapbook) which will create a PDF using Mapnik's default AGG renderer. It works with any mapnik style file, although I find that osm.xml is not well suited to print. You can also render directly to a PDF as vectors with mapnik, but this is lower quality and larger than a high resolution bitmap. I had a look at the area in JOSM and I can't see much data that the osm.xml style doesn't render. What amenities were you thinking of that aren't rendering? Incidentally, could someone verify if http://www.openstreetmap.org/browse/way/159553109 exists? It shows on the high zoom imagery but not the lower zoom, and the lower zoom may be more recent. From: Clifford Snow [mailto:cliff...@snowandsnow.us] Sent: Wednesday, June 27, 2012 7:40 PM To: talk-us Subject: [Talk-us] Creating PDF maps Can someone point me to an easy to use resource to create a map in a pdf file? For example, Discovery Park in Seattle is a great resource. It has Puget Sound on the west side, great trails, hidden ponds, a cultural center, a veteran's cemetery, playgrounds, a some of the best views of the Olympic Mountains. I'd like to produce a map that could be sent out showing what's offered. I could just grab a screen shot, but Mapnik doesn't show all of the amenities. I'm thinking that I could use this example to convince others that using OSM beats the alternatives. So, what do you use? Thanks, Clifford ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] NHD Conversion
I have been working on a conversion for NHD data to .osm and decided it's time to post something. A few warnings - The conversion is not yet done. I estimate that the FCode conversions are about 90% done - This is designed to work on the pre-staged subregion files which are FileGDB or PersonalGDB. It is not designed to work on shapefiles. If you need to clip these files I have had success writing to a FileGDB. - The translation is written for NHD data model 2.1 and not all areas have been converted - The conversion process will only work with the latest version of ogr2osm. When writing these I implemented a few new features and fixed a few bugs - Post-processing is needed but I haven't figured out exactly what yet - The exact process for generating these files is not yet documented. It requires compiling gdal to support additional file formats I know there are multiple NHD translations written, but none that make use of the 2.1 data model I wrote this translation to deal with NHD data as it appears in the NHD database, not as it is documented on paper. It appears that some of the existing translations used the NHD FCode descriptions without checking them against real data. Without further ado, the translation is at https://github.com/pnorman/ogr2osm-translations/blob/us_nhd/us_nhd.py To use it: 1. Compile gdal with PersonalGDB support 2. Download a subregion 3. Download ogr2osm and fetch the us_nhd branch of ogr2osm-translations 4. Run it on a sub-region As this is a difficult process, I've prepared some samples of small areas at http://maps.paulnorman.ca/imports/nhd/20120706/ 0413: Rochester, New York 0310: Punta Gorda, Florida 1026: Manhattan, Kansas 1501: Hoover Dam 1711: Blaine, Washington gnis:fcode is in for debugging purposes. I am not sure about keeping FDate but have left it in for now. Significant post-processing is still required. I intend to simplify ways, join ways (glom) based on ReachCode then strip out ReachCode. It would be nice if when I finished this work there was a way for it to be used. I could create .osm files for all of the US easily enough but I'd like to avoid repeating the mistakes that were made with CanVec. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: Post bot cleanup
From: Toby Murray [mailto:toby.mur...@gmail.com] Subject: Re: [Talk-us] Fwd: Re: Post bot cleanup And this time to the list... (cures you, lack of reply-to!) On Thu, Jul 19, 2012 at 11:16 AM, the Old Topo Depot oldto...@novacell.com wrote: Toby's post yesterday using the modified live edit bot osmZmiany seems a good way to help focus on areas. Toby, do you think it possible to serialize the state of the edits as you displayed yesterday so that they could be used as a zoomable reference to areas potentially needing review ? Ehh... not sure OSMZmiany is the best tool for this. Once you get a lot of nodes loaded in, it takes up a few hundred MB of RAM and performs like crap. Like 5 seconds to zoom/pan. However I do have an idea or two to make something that would work better. I will have to tinker with it tonight and see if it is practical. I can build a .osc file that represents all the bot changes to a given square (e.g. LA) It'll take a bit of coding so I might not get it done today, but it shouldn't be too hard. I'm also wondering if a routing regression suite exists anywhere that could be used to help identify broken interstates and other major ways, as the tagging changes and 2 node bridges that were likely deleted will take time to identify. There was something like this back when the TIGER import was new to help people connect major highways across county lines. Does anyone know the technical details or if it would be practical to bring back? It is documented here: http://wiki.openstreetmap.org/wiki/TIGER_fixup/250_cities/routing_grid I think it's practical, I've given some thought to doing this. Maybe query one of the routing services to build it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD import: what data quality is acceptable?
From: Kevin Kenny [mailto:kken...@nycap.rr.com] Subject: [Talk-us] NHD import: what data quality is acceptable? A few months ago, I tried to get started on trying to resume the NHD import in my area - and some of the places where I hike. I'm trying to check results with both P2 and JOSM, and tripping over a lot of things, which made me put the project back on hold for a while. (I had some other things to be about.) But now I'm starting to reconsider again, after hearing that there are others out there thinking the NHD import is desirable for an Open Trail Map. I mentioned this in a message earlier today. So, let me review some of the things that have me scratching my head. (1) The mapping from NHD feature codes to OSM tags is incomplete (and not quite consistent). That's fine; for all the FCodes in my area, I've been able to find features that I'm familiar with that I can describe. So I think I have that problem fairly well licked. (I may have to invent a tag or two, like waterway=rise and waterway=sink to describe streams that go underground and appear again in karst terrain.) The mappings on the wiki are not only incomplete and inconsistent, they're for an older NHD version and sometimes clearly wrong. I posted a better one (http://lists.openstreetmap.org/pipermail/talk-us/2012-July/008502.html) earlier this month but it didn't attract any comments, and it's not complete either. It handles most of the FCodes but still is missing a couple. It also needs some post-processing to clean up over-noded ways and some other matters. The main weakness with NHD data that I find is that there is no way to distinguish between an OSM waterway=stream and waterway=river ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD import: what data quality is acceptable?
From: James Umbanhowar [mailto:jumba...@gmail.com] Sent: Sunday, July 22, 2012 6:43 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] NHD import: what data quality is acceptable? On Sun, 2012-07-22 at 18:33 -0700, Paul Norman wrote: The main weakness with NHD data that I find is that there is no way to distinguish between an OSM waterway=stream and waterway=river Why not use the name? The name is the best way I've found and is in fact what I'm using (https://github.com/pnorman/ogr2osm-translations/blob/69434ec55a48e9e4858ef3 5f2489949b2020e527/us_nhd.py#L234) but it's not 100% No way is perhaps a bit strong, no fully reliable way would be more accurate. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD import: what data quality is acceptable?
From: Kevin Kenny [mailto:kken...@nycap.rr.com] Sent: Monday, July 23, 2012 5:45 AM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] NHD import: what data quality is acceptable? On 07/22/2012 09:33 PM, Paul Norman wrote: The mappings on the wiki are not only incomplete and inconsistent, they're for an older NHD version and sometimes clearly wrong. I posted a better one (http://lists.openstreetmap.org/pipermail/talk-us/2012-July/008502.htm l) earlier this month but it didn't attract any comments, and it's not complete either. It handles most of the FCodes but still is missing a couple. It also needs some post-processing to clean up over-noded ways and some other matters. Right. I downloaded and looked at your code, but I was already pretty far along when you posted that message. I'd mostly been working by diligently examining, each time I encountered an FCode that I haven't seen before, what the feature actually is, from personal knowledge. (I then often presume that other features having the same FCode are the same general sort of thing.) This unfortunately falls short. I find that you need to check the FCode across at least 3 different parts of the country to be sure. I've found there are regional variations in how FCodes are used. I hope to get back to my code in the next week. With the redaction it hasn't been a high priority. Also, no one has proposed a NHD import lately. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Kern County Import Cleanup
I happened to be looking at Kern County and noticed two problems with the imports that seem to be systemic over the area. The first is classification of empty areas as landuse=residential (e.g. http://www.openstreetmap.org/browse/relation/540695 http://www.openstreetmap.org/browse/way/53993995) I'd suggest deleting these as no landuse appears to appropriate here The second is a similar issue, mountainside areas in landuse=farm (e.g. http://www.openstreetmap.org/?lat=35.26lon=-118.47zoom=14) While doing this cleanup I would suggest removing attribution, description, kern:Comb_Zn, kern:Zn_Cd1 and setting source=Kern_County_GIS The appropriate solution for most of the ways/multipolygons seems to be to delete them, but I'll leave this to you since you're familiar with the extents of the upload. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New version of US redaction map
It’s all CC BY-SA right now so you’d be okay now, but I think it’d be a problem in the future under both CC BY-SA and ODbL if you were mix the data in this way. From: Martijn van Exel [mailto:m...@rtijn.org] Sent: Monday, August 13, 2012 7:09 PM To: Mike N Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] New version of US redaction map On Mon, Aug 13, 2012 at 12:27 PM, Mike N nice...@att.net wrote: On 8/13/2012 12:48 PM, Martijn van Exel wrote: The main new thing is that it now shows deleted ways as well Very nice - this map and Toby's are very useful. I see that the deleted ways are purple. One thing I have noticed is that it would be nice to detect a new roadway having been added under the old deleted roadway, and automatically remove the notification. Interesting idea. My US database is currently catching up with reality, so I can't really try until that has completed, but I do have an idea how to make that work. Without relying on human tagging like in the Inspektor. What I would do is select all (current) ways that overlap the bounding box of the deleted way and that are created after 7/15, then calculate the hausdorff distance between the deleted way's geometry and the results of that query. If we get a close match, it is *very likely* that the way has already been remapped. Identical highway= tags may further corroborate this. What I am not so sure about is using the non-compliant geometry and tags this way, from a legal perspective. Anyone who can offer any ideas on that? Martijn -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Kern County progress
It's good to see some progress made on cleaning these up. Just be clear, are you proposing a new import at this time? From: Nathan Mixter [mailto:srmix...@hotmail.com] Sent: Monday, August 20, 2012 2:45 PM To: talk-us; imports Subject: [Talk-us] Kern County progress I have begun cleaning up the area around Kern County, California. It is starting to not only look better but be less cluttered. I originally imported landuse data from both Kern County and the City of Bakersfield. Some areas from these two agencies overlapped around Bakersfield, and I have been going through and trying to remove these. The city data were quite good and included landuse areas, buildings, parks and even individual trees within the city. The county data tended to be generic in several places. It also was slightly misaligned in spots particularly in the rural areas, possibly due to the projection it was created with by the county. I have been going through and systematically deleting the redundant areas and breaking down the over used landuse=farm and landuse=residential tags into more specific areas. And in the process, I have been covering some of the ugly white space that has remained empty. A lot of the areas are now natural=heath. There is not really any good way to differentiate between meadow and heath areas. Still seems like they can be used interchangeably sometimes. I've been trying to use meadow for an area that can be used for grazing. I just started using the heath tag for open areas generally on areas east of Highway 5. It's not a perfect option but at least it kind of matches the work others have done around Las Vegas and in the desert. I've been trying to integrate the existing Kern County data with the FMMP farm data, which I have imported for other counties around the state as well. As part of the cleanup, I am adding some new buildings in Bakersfield from city data. I am only adding new building that have been added since the original import and verifying that they don't exist to avoid dups. Probably less than 1,000 total new buildings. Originally, I included bak:fac_type1, bak:fac_type2 and bak:fac_type3 tags on some buildings to correspond to tags in the data. These are not needed and can be removed en mass by a script in the future. I am leaving those tags out and incorporating them into the building= tag (ie building=residential, building=commercial) for new buildings. I also created a long overdue Kern County page on the wiki to keep track of the changes (http://wiki.openstreetmap.org/wiki/Kern_County,_California). Thanks to everyone who has contacted me to help out with the cleanup and offered advise. If anyone is interested in helping or has any suggestions, feel free to jump in or let me know. Nathan, ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Kern County progress
Treating this as a new import, I have a few questions Is there a page on the wiki with the information called for in http://wiki.openstreetmap.org/wiki/Import/Guidelines#Document_your_import_on _the_wiki? There is the Kern County page, but that is a page for the county, not a page for an import. What software do you plan to use to convert shapefiles to OSM? Can you post an example of the data in .osm format, that way we can see how the data tagging as well as the accuracy is. The metadata for the Bakersfield source contains the following clause You agree not to provide a copy or partial copy of any data to any other party, including consultants under contract with you, without disclosing that the copy or partial copy was obtained from The City of Bakersfield and without attaching a duplicate of these Terms and Conditions. I know that you had informally obtained different permissions for some data but that it wasn't particularly well documented. Could you obtain clearer permission, including for the data previously imported. From: nmix...@gmail.com [mailto:nmix...@gmail.com] On Behalf Of Nathan Mixter Sent: Monday, August 20, 2012 7:03 PM To: Paul Norman; imports Subject: RE: [Talk-us] Kern County progress Yes, I guess it would be considered as a new import since it includes new data not originally included from the city. But it is a selective import since not all the data is new. I plan to do it in several small uploads so I can verify the accuracy. On Aug 20, 2012 6:36 PM, Paul Norman penor...@mac.com wrote: It's good to see some progress made on cleaning these up. Just be clear, are you proposing a new import at this time? From: Nathan Mixter [mailto:srmix...@hotmail.com] Sent: Monday, August 20, 2012 2:45 PM To: talk-us; imports Subject: [Talk-us] Kern County progress I have begun cleaning up the area around Kern County, California. It is starting to not only look better but be less cluttered. I originally imported landuse data from both Kern County and the City of Bakersfield. Some areas from these two agencies overlapped around Bakersfield, and I have been going through and trying to remove these. The city data were quite good and included landuse areas, buildings, parks and even individual trees within the city. The county data tended to be generic in several places. It also was slightly misaligned in spots particularly in the rural areas, possibly due to the projection it was created with by the county. I have been going through and systematically deleting the redundant areas and breaking down the over used landuse=farm and landuse=residential tags into more specific areas. And in the process, I have been covering some of the ugly white space that has remained empty. A lot of the areas are now natural=heath. There is not really any good way to differentiate between meadow and heath areas. Still seems like they can be used interchangeably sometimes. I've been trying to use meadow for an area that can be used for grazing. I just started using the heath tag for open areas generally on areas east of Highway 5. It's not a perfect option but at least it kind of matches the work others have done around Las Vegas and in the desert. I've been trying to integrate the existing Kern County data with the FMMP farm data, which I have imported for other counties around the state as well. As part of the cleanup, I am adding some new buildings in Bakersfield from city data. I am only adding new building that have been added since the original import and verifying that they don't exist to avoid dups. Probably less than 1,000 total new buildings. Originally, I included bak:fac_type1, bak:fac_type2 and bak:fac_type3 tags on some buildings to correspond to tags in the data. These are not needed and can be removed en mass by a script in the future. I am leaving those tags out and incorporating them into the building= tag (ie building=residential, building=commercial) for new buildings. I also created a long overdue Kern County page on the wiki to keep track of the changes (http://wiki.openstreetmap.org/wiki/Kern_County,_California). Thanks to everyone who has contacted me to help out with the cleanup and offered advise. If anyone is interested in helping or has any suggestions, feel free to jump in or let me know. Nathan, ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Canada and US Imagery bounds
I've gone and updated the imagery bounds and bboxes for both Potlatch 2 and JOSM for the North American imagery sources. JOSM should now only suggest a source if it actually covers the area. Potlatch 2 will still suggest sources even if they don't cover the area because potlatch 2 only supports bboxes, not polygons and the bbox for most of the US sources looks like http://www.openstreetmap.org/?box=yesbbox=-124.819%2C24.496%2C-66.930%2C49. 443 I have also set up bc_mosaic, a source covering Greater Vancouver, Fraser Valley, and the Sea 2 Sky corrider up to Pemberton. Both JOSM and PL2 should suggest it. The source is the various sources listed on http://imagery.paulnorman.ca/tiles/about.html combined into one layer. The individual layers will be faster but not as convenient. To update the layer information in JOSM use the reload button to the right of the map on the Imagery Preferences tab of Preferences. You may of course find that if you live right on the border that some suggestions are not ideal but the error is now measured in hundreds of meters, not hundreds of kilometers. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US-Canada Border between BC and Washington State
The survey points are based on IBC data (which they view as PD) and are supposed to be accurate within a few cm and the limits of NAD83 to WGS84 conversion (a few more cm). I've verified a few by the lower mainland with survey and against a few sources of accurate imagery and their data seems accurate within the limits of the imagery. You can see a clearing along parts of the border in that area so it's accurate to within 20 meters. I know that Washington State argued that they were not responsible for the border costs in Blaine because it was not part of the state since the state ended at the 49th parallel and the border is north of the 49th there. What I'll do is go and eliminate duplicate border ways, like I did with the lower mainland. From: Clifford Snow [mailto:cliff...@snowandsnow.us] Sent: Monday, September 17, 2012 4:49 PM To: talk-us Subject: [Talk-us] US-Canada Border between BC and Washington State I've been doing some work in the North Cascades National Park. It appears that the border between the US and Canada is wrong. Look at http://www.openstreetmap.org/?lat=48.9841 http://www.openstreetmap.org/?lat=48.9841lon=-121.743zoom=13layers=M lon=-121.743zoom=13layers=M It appears that the boarder sags to the south. I see tags man_made = survey_point which would indicate that the border placement is correct. Can anyone recommend how to validate the border placement? -- Clifford I have promised to cut down on my swearing and drinking, which I have. Unfortunately, this has left me dim-witted and nearly speechless. Adapted from The Lion by Nelson DeMille -or- If you can't explain it simply, you don't understand it well enough. Albert Einstein ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Talk-ca] US-Canada Border between BC and Washington State
I'm uploading a changeset that should fix most of the border problems. Some tagging problems may remain with the parks but it shouldn't be necessary to adjust the geometry. I did note that some of the US parks to the south need to be turned into boundary relations and have their ways de-duplicated. I didn't really touch the woods because those don't stop at the border From: Clifford Snow [mailto:cliff...@snowandsnow.us] Sent: Monday, September 17, 2012 8:16 PM To: talk...@openstreetmap.org Subject: [Talk-ca] (no subject) I'm doing some work in the Washington State and noticed some problems along the border between BC and Washington State. I asked for help on the talk-us mailing list. I originally though the border was incorrect. However, because the border doesn't track exactly along the 49th parallel there appears to be some administrative areas that don't match up with the actual border. See http://www.openstreetmap.org/?lat=48.9803 http://www.openstreetmap.org/?lat=48.9803lon=-121.7579zoom=12layers=M lon=-121.7579zoom=12layers=M Paul Norman wrote: On Mon, Sep 17, 2012 at 5:49 PM, Paul Norman penor...@mac.com wrote: The survey points are based on IBC data (which they view as PD) and are supposed to be accurate within a few cm and the limits of NAD83 to WGS84 conversion (a few more cm). I've verified a few by the lower mainland with survey and against a few sources of accurate imagery and their data seems accurate within the limits of the imagery. You can see a clearing along parts of the border in that area so it's accurate to within 20 meters. I know that Washington State argued that they were not responsible for the border costs in Blaine because it was not part of the state since the state ended at the 49th parallel and the border is north of the 49th there. What I'll do is go and eliminate duplicate border ways, like I did with the lower mainland. There is a large multipolygon with a source of CanVec 6.0 - NRCan that should probably extend to the border. However I'm not sure. I'm wondering if anyone in Canada could investigate. The area is defined as natural=wood. BTW - I'm using USDA National Forest Services Topo Maps to add in rivers, streams, etc. I see streams coming into the US from BC, but we don't have any corresponding stream in Washington. Clifford I have promised to cut down on my swearing and drinking, which I have. Unfortunately, this has left me dim-witted and nearly speechless. Adapted from The Lion by Nelson DeMille -or- If you can't explain it simply, you don't understand it well enough. Albert Einstein ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remap-a-tron level 2 complete! Suggestions for level 3?
From: Martijn van Exel [mailto:m...@rtijn.org] Sent: Friday, September 28, 2012 8:29 AM Subject: Re: [Talk-us] Remap-a-tron level 2 complete! Suggestions for level 3? Level 4 Tiger unedited roads that are highway residential and have no name. How many of those are there? They would only be candidates if they actually have names. How would we know this? Most of the ones I've seen weren't really residential roads but were agricultural tracks or paper roads. That being said, I'm not sure this is a great use case for remap-a-tron because you can't get the names from imagery. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map update - 2012-09-26
From: Dave Hansen [mailto:d...@sr71.net] Subject: [Talk-us] Whole-US Garmin Map update - 2012-09-26 Does your map cover Mexico/Canada? Yes!! I have, for the purposes of this map, annexed Ontario in to the USA. Some areas of North America that are close to the US also just happen to get pulled in to these maps. This might not happen forever, and if you would like your non-US area to get included, let me know. Could you annex part of BC into the west coast? Adding the CA-Cambell River, CA-North Vancouver, CA-Kamloops and CA-Kelowna would cover most of the population of BC and add some waters within the US 12 NM limit as well as get the drivable part of the west coast within one file (which would include the route I'm taking to SOTM-US) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Burlington, Vermont road classification
From: Andrew Guertin [mailto:andrew.guer...@uvm.edu] Subject: Re: [Talk-us] Burlington, Vermont road classification On 10/18/2012 05:07 PM, Richard Weait wrote: On Thu, Oct 18, 2012 at 4:48 PM, Andrew Guertin andrew.guer...@uvm.edu wrote: Hi, There are two active mappers in the Burlington, Vermont area, and we disagree about how the roads should be classified, so we're looking for more opinions. If you are both local mappers, I suggest that you actually meet face to face and share a beverage. [...] While not a bad idea, I don't think that this is necessary or helpful for this case. We're both impressed with each other's work, and (it seems through text at least) perfectly willing to accept the other's viewpoint, it's just that now we've realized that the docs are ambiguous enough to make *both* viewpoints valid, and we'd like to choose the one that most closely matches the rest of the map, especially in nearby areas. The unfortunate answer - it isn't consistent. When it comes to road classifications in the US and Canada, each state or province is like its own country would be in Europe. In Europe, funding models and government classifications are generally consistent on a country-wide basis. When each state classifies differently, it follows that OSM classifications are going to differ. In BC we find the government classifications generally unhelpful so we don't pay them much attention (http://wiki.openstreetmap.org/wiki/Canada:British_Columbia#Highways_and_pro vincial_roads) Hopefully someone from Vermont can chime in with another view from the state, but from afar, either viewpoint is valid. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] press from SOTM US
From: Toby Murray [mailto:toby.mur...@gmail.com] Sent: Saturday, October 20, 2012 12:59 AM To: Talk Openstreetmap Subject: Re: [Talk-us] press from SOTM US On Fri, Oct 19, 2012 at 10:48 PM, Richard Welty rwe...@averillpark.net wrote: we got some. Carl Frantzen of Talking Points Memo asked me about coming to SOTM US and i urged him to do so. he did and here we are: http://idealab.talkingpointsmemo.com/2012/10/openstreetmap-part-1-new- cartographers.php Not quite sure what the little paragraph about move away from its open source roots. is all about. He kind of dropped that in there like a live hand grenade and then didn't say any more about it. Apparently this will be in parts 2 and 3. Having been at the session where I think this statement came from, I can assure everyone that there was absolutely no talk about moving away from an open license! :) Well, there's a difference between open source and open data. My understanding is that OSM is an open data project, but the OSM services run by OSMF are open source. There are non-open source tools for working with OSM data like ESRI's ArcGis OSM editor or Maperitive. The downside to closed-source software in a project like OSM is that you're a lot less likely to get help from the people in the community who have already faced similar challenges. The discussion was about the fact that some companies are very afraid of share-alike licenses and it is preventing them from using our data to its fullest potential. There is some uncertainty about when exactly the share-alike clause is activated. One specific example that was mentioned: If you use OSM data to geocode a user's address, does the user database then have to be shared? That's apparently how the lawyers tend to read it but in my mind this would be silly. We have no use for a company's user database even if it were possible to release it without breaking every privacy law on the books. Not even the OSMF shares its user table, so in my mind also this is a silly reading of the ODbL. I believe part of the confusion is because the case law around what is and isn't a derivative work is not well defined. There might be a scenario on which after distributing a user's exact location you also have to release the address corresponding to that location if requested... but if the data is accurate and the geocoder is any good, you can just do the reverse geocoding. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Stripping TIGER tags
I've been going through my time-lapse photos from the way down to Portland. A large part of what I'm doing is adding tags to the I 5, mainly lit=yes/no since you can't get much else at night. Because I'm editing the tags anyways, I'm stripping off unnecessary or incorrect tiger:* tags. Often this leaves me with no tiger:* tags. What's the best practice in this case? Currently I'm adding a source=TIGER 2005 in some cases and leaving nothing behind when I feel there's nothing left of TIGER. Any thoughts? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD Imports
From: Russ Nelson [mailto:nel...@crynwr.com] Sent: Saturday, October 27, 2012 6:19 PM To: OSM US Talk List Subject: Re: [Talk-us] NHD Imports I would like to have every stream in the U.S. available as a .osm file. So, say, I am running along some road or railroad, and I see a stream that doesn't exist in OSM yet. Rather than doing the clicky-click myself, it would be great if I could load up the NHD version of that stream. I could compare it against the aerial photos, and the data already in OSM, and decide for myself if I want to use that or do the clicky click. For what it's worth, I'm working on this, but it's hard work and takes time to do it right. I'd be open to coordinating with someone else, but they'd need some basic python knowledge, the ability to compile gdal to read .mdb, the ability to use git to work with others, and the experience required to develop translations. Also, some of the other software pieces needed aren't there yet. NHD is massive and I have no idea how some parts of the toolchain will work when I start throwing hundreds of gigs of data at them. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD imports
From: Nathan Mixter [mailto:nmix...@gmail.com] Sent: Sunday, October 28, 2012 1:39 PM To: talk-us Subject: Re: [Talk-us] NHD imports In June, user Bsupnik converted the entire NHD dataset into OSM format. The files are available at http://bsupnik.dev.openstreetmap.org/NHD. He mentioned that he was working on creating better quality files. The files that he created look good. They are missing the names though. It looks like they just need a couple minor tweaks because the files generally looked good. Just wondering if any progress has been made. These would be ideal once the bugs are worked out so people could review and upload the data in their area. I downloaded a random area (17010104) and looked at these. There were no real OSM tags on the ways, only gnis:fcode, gnis:ftype, nhd:com_id and source. I'd question anyone proposing an import with both fcode and ftype because ftype can be inferred from fcode. Also, it suffers from an inherent limitation by splitting it up among multiple files. This method loses the connections between the layers, resulting in duplicate nodes and the topology not being connected. I looked at a separate-layer approach when I first started looking at NHD and with how NHD is structured with many interdependent layers it doesn't make sense to do it that way. You have to merge all the layers together as a multi-layer file and then convert to OSM. I'm not sure if shp-to-osm can handle multi-layer sources. A couple of other specific issues with these conversions: - They're of 2011 data, not the latest NHD data - I wasn't able to find a rules file from bsupnik for the conversion, so they can't be rerun with latest data. He hasn't been active on the lists since 2011 and hasn't replied - The NHD data model changed since 2011 If anyone is aware of where the file with the rules bsupnik used resides, please let me know. It would really help what I'm working on. Also, needless to say, someone who wanted to import a basin would need to read and follow http://wiki.openstreetmap.org/wiki/Import/Guidelines ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] What to do with unnamed NHD streams
Background: I'm working on converting NHD to .osm format NHD is an extremely large data set. It's about 25G of zipfiles and all of this converted to .osm would total about 3 TB. This is about 10x-15x times the size of planet.osm. There are three factors that lead to this large size. The third is what this email is about 1. The NHD covers a massive area. 2. Some ways are very over-noded. The NHD accuracy standard is 12m error 90% of the time. Running a 1m simplify in JOSM reduces the number of nodes to 25%-50% of what it was before. Like everything with the NHD, this varies from region to region. I'm thinking a 2.5m simplification would be best - it's 1/5th of the accuracy standard. Of course, running a simplification on a dataset this large is a challenge in itself. 3. A lot of NHD is very minor streams only of use to hydrologists. There are streams that you would be hard pressed to locate if you were there in person and in some cases they do not exist anymore. A sensible solution in any NHD translation may be to drop any FCode 46003 (intermittent) streams without a name. It may also be worth dropping FCode 46006 (perennial) streams without a name. I've looked at a couple of regions with this adjustment made and they seem a lot more reasonable. The data is a lot more manageable and of more relevance to a general purpose map like OSM. There are also a lot fewer cases of streams that no longer exist. Does anyone have any thoughts on what should be done in a NHD translation with these streams? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What to do with unnamed NHD streams
From: Michal Migurski [mailto:m...@teczno.com] Sent: Sunday, October 28, 2012 8:58 PM To: OpenStreetMap US Talk Subject: Re: [Talk-us] What to do with unnamed NHD streams Does [NHD] all come in shapefile form? The simplification would be a relatively easy (though time-consuming) task for PostGIS on a server with sufficient storage, outputting new shapefiles for ogr2osm. I can help with this using one of our office servers that we use for such tasks. It comes in .mdb or .gdb form. These could be loaded into postgis and I've considered doing it. My home server has the storage and cores to do it, but I don't think it would help. The problem is you need to convert to .osm and *then* simplify. If you do this in the other order you have problems where one object intersects another (e.g. because they share a geometry for a portion of them). You end up simplifying away the intersection points and your resulting ways won't end up correctly sharing nodes. The most common example of this is when a stream meets a lake. At the meeting point you have a FCode 55800 from NHDFlowline in the water, a FCode 4600x from NHDFlowline on the land side and a FCode 390xx or 436xx from NHDArea as the bounds of the lake. Without simplification the output will have the three ways sharing a node at the intersection point. If you simplify before converting you could simplify away the point on the NHDArea and then you'll no longer have the node sharing. You can run into similar issues where a simplification of a NHDFlowline takes it away from a NHDPoint, resulting in the point no longer being on the line. I would *really* like to be able to simplify prior to ogr2osm as it would dramatically decrease the size of the nodes data in-memory and decrease conversion time, I just can't see how to do it prior to processing. JOSM's simplify ways function works okay, although it doesn't deal with the case of two ways sharing nodes very well. 3. A lot of NHD is very minor streams only of use to hydrologists. There are streams that you would be hard pressed to locate if you were there in person and in some cases they do not exist anymore. A sensible solution in any NHD translation may be to drop any FCode 46003 (intermittent) streams without a name. It may also be worth dropping FCode 46006 (perennial) streams without a name. Can these be simplified to a lower level of accuracy? In principle yes, and I'll try it with JOSM. I'm not sure how it'd turn out. I have a feeling it will still result in a lot of low-value ways. Perhaps drop nameless 46003 which often don't correspond to anything noticeable and use heavier simplification on 46006? I'm not convinced this would be a good option, but I'll see how it looks in a couple basins. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What to do with unnamed NHD streams
From: Michal Migurski [mailto:m...@teczno.com] Sent: Monday, October 29, 2012 12:04 AM To: OpenStreetMap US Talk Subject: Re: [Talk-us] What to do with unnamed NHD streams On Oct 28, 2012, at 11:41 PM, Paul Norman wrote: From: Michal Migurski [mailto:m...@teczno.com] Subject: Re: [Talk-us] What to do with unnamed NHD streams On Oct 28, 2012, at 10:29 PM, Paul Norman wrote: The problem is you need to convert to .osm and *then* simplify. If you do this in the other order you have problems where one object intersects another (e.g. because they share a geometry for a portion of them). You end up simplifying away the intersection points and your resulting ways won't end up correctly sharing nodes. There are ways around this, by first de-duping the shared edges or nodes. Topology preservation is not terribly difficult if you prepare your data, for example by splitting lines and polygons at intersections (as in your lake example), simplifying only the parts and then reconstructing the original geometries. Do you have a link to an example of the PostGIS magic to do this? It's beyond what I could do. I implemented a version of this here: http://github.com/migurski/Bloch Without digging into the code too deeply, the short version is that you can use the intersection of two shapes to arrive at something like a topology. For a pair of polygons that share a border, the ST_Intersection() results in a linestring that forms the border, which you can ST_Difference from each border to get the remaining pieces. The expensive part is the gigantic pairwise comparison to come up with the full list of all feature pairs that touch each other or come really close. I'll have a look tomorrow - I'm too tired to give it thought right now. A slight complication I found is that you can't just go for intersections but you also have to go to near intersections - sometimes the NHD data is off by a couple cm. I don't know if this will pose a practical issue for the simplification. Possible to round every node position to 1e-7 degrees? Yes - this is in fact what ogr2osm does. It internally nanodegrees and all positions are integers, and it groups nodes within 100 nanodegrees by default[1]. I'm not sure how to do this to a .mdb although it may be possible to do when loading the files. My initial thoughts are that if I'm loading into PostGIS I don't really want to export out of it, I'd prefer to go immediately to ogr2osm. Currently I don't have the ability to read from PostGIS in ogr2osm but I've considered adding it and it shouldn't be hard. [1]: It's late enough that I'm not 100% sure on the exact number of decimal places used without checking. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What to do with unnamed NHD streams
From: Michal Migurski [mailto:m...@teczno.com] Subject: Re: [Talk-us] What to do with unnamed NHD streams On Oct 29, 2012, at 12:03 AM, Michal Migurski wrote: Do you have any sample NHD extracts that might be usable for a test drive? All of NHD can be found at on the USGS FTP site, but you need to compile gdal with 3rd-party toolkits to be able to use them. This is quite often a pain. I clipped out a small part of Kansas I was testing with early, converted it to a set of shapefiles and posted it at http://took.paulnorman.ca/imports/NHDH0202_shp.zip I should note that some information is lost in the shapefile conversion (long field names). For space reasons I dropped the WBD_HU layers. The first step of my converting is to remove them anyways. Awesome, downloading! Yum: https://dl.dropbox.com/u/30204300/NHD.png I can see that the water areas are also represented as centerlines, how would you import these? What's been recommended for rivers is to have both a waterway=riverbank (although some people prefer natural=water) for the water area and a waterway=river down the middle. I carry the same convention to small and medium lakes where it makes sense. Some lakes don't have a clear flow to them in which case it doesn't make sense. For NHD this means applying the same logic to FCode 55800 ARTIFICAL PATHs as to 4600x STREAM/RIVERs, done with https://github.com/pnorman/ogr2osm-translations/blob/dfea94216149fe9c567a367 a5eb50426c51f1ddf/us_nhd.py#L235 55800 ARTIFICAL PATHs are not be confused with 33400 CONNECTORs, which I drop. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] What to do with unnamed NHD streams
From: Jaakko Helleranta.com [mailto:jaa...@helleranta.com] Sent: Monday, October 29, 2012 5:52 AM To: Paul Norman Subject: Re: [Imports] What to do with unnamed NHD streams Hi Paul, Where can I get my hands on this data / its documentation? I'm actually most interested about the documentation (for different than this import reasons) but could try to take a look at the data too (.. If I know/can figure out how to). Frequently I end up having to search for a particular FCode online to find the relevant docs. NHD 2.0 has the data model (but not FCodes) described at http://nhd.usgs.gov/NHDDataDictionary_model2.0.pdf NHD 2.1 has a poster at http://nhd.usgs.gov/NHDv2.1_poster_3_23_2012.pdf but it does not fully describe some of the FCodes. http://nhd.usgs.gov/userGuide/Robohelpfiles/NHD_User_Guide/Feature_Catalog/H ydrography_Dataset/Complete_FCode_List.htm is the most complete FCode list although the descriptions are often very terse. The pre-staged data is at ftp://nhdftp.usgs.gov/DataSets/Staged/SubRegions/PersonalGDB/HighResolution/ or ftp://nhdftp.usgs.gov/DataSets/Staged/SubRegions/FileGDB/HighResolution/ I've found that looking at the documentation alone is not ideal. There are subtle oddities to NHD that you will only pick up by examining the data. The comments in https://github.com/pnorman/ogr2osm-translations/blob/us_nhd/us_nhd.py are my notes which might be somewhat helpful. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD imports
This is only a partial reply - I should have more detail this afternoon when I have more time. From: Ben Supnik [mailto:bsup...@xsquawkbox.net] Subject: Re: [Talk-us] NHD imports 2. The conversion required running a non-GUI tool, which meant having command line skills, etc. This is actually a plus for me - handling all of NHD without command line scripts would be difficult. There's a *lot* of data. So I ran the import script over the entire data set and uploaded the resulting .osm files so individuals could use them. There was a third step I was hoping could be solved: if you new to OSM, importing data isn't trivial. Richard Fairhurst had a cool feature in Potlatch 2 where PL2 could be told of the presence of a vector layer and import it visually. But I was never able to get the data to work with PL2. This is actually mostly solved now - http://www.cyclestreets.net/edit/locate/ has a PL2 instance which has a vector layer background for all of the UK. There are a few issues like loading many GB of data into the server supplying the vector layer and making it available without deploying your own PL2 instance, but these are fairly minor. I used shp-to-osm-0.8.2, jar'd by someone else (I am not a big java nerd, sorry) and the latest rules at the time from the Wiki. If it is useful, I can send anyone who wants them a rip of the rules file I was using at the time and/or the JAR, bt... Ah, good to know. - The NHD data model changed since 2011 Yeah, I was something like that a few months after I put this down and went oh hell I haven't had time to look at what happened; is the data model a major revision to the point where everything I did makes no sense, or is it just renaming of fields? The common FCodes have remained the same but some of the less common ones have changed. Other issues about the import: - I wouldn't say it is split from multiple files - rather I would say it is not joined - that is, the splits are the sub-basin splits that I think persist in the NHD. Actually, I take that back - I think the tool chain intentionally avoids really huge OSM entities to avoid imports that can fail. The splits I'm talking about are being split into layers. You have lakes on one layer and rivers on another, etc. The splits by area remain similar although I believe the pre-staged files cover a larger area (HUC4 basins) than what you were given did. - There should be OSM codes like waterway=bla on at least -some- of the data. The import program rules from the time did include FCODE and FTYPE and had no facility to drop entities that had only NHD but no OSM tags. At the time this was also considered not-so-good, but I wasn't in a position to rebuild the tool. Maybe I picked an odd region or layer. There are some areas in the NHD that are quite different from all the others and use FCodes in different ways. I should know the dangers of concluding something by looking only at one part of NHD :) So at the time I was annoyed that we couldn't just import all of NHD at once and 'get lakes everywhere' but while that would get a lot of waterbodies into empty places, it's probably not good for OSM or the US mapping community. That's my view too. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Difficult USA mapper(s)
From: Martijn van Exel [mailto:m...@rtijn.org] Sent: Wednesday, October 31, 2012 2:18 PM To: Richard Weait Cc: Serge Wroclawski; d...@osmfoundation.org; Ian Dees; talk- u...@openstreetmap.org Openstreetmap Subject: Re: [Talk-us] Difficult USA mapper(s) It's hard to come up with guidelines when you don't know the specifics, but let me throw in some thoughts based on what I read: 1) If you were to take administrative action on an account, blocking it either temporarily or permanently, how do you prevent the same person (or group of people, or bot, using the account) from starting fresh under a new guise? My limited knowledge of these matters suggests that this would be a Hard Problem. If it is, blocking accounts is a toothless measure that doesn't even deserve all that much consideration. If it isn't, I'm curious to know how it works, but that's possibly for another thread. I am reasonably confident that the means exist to block someone and keep them blocked. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Operation Cowboy - preparations
From: Matthias Meißer [mailto:dig...@arcor.de]
Sent: Thursday, November 01, 2012 9:51 AM
To: talk-us@openstreetmap.org
Subject: [Talk-us] Operation Cowboy - preparations
Hi US community,
4. *Further Imagery*
Is there other or better imagery than Bing for certain areas? How can we
promote this to the other volunteers?
If there is JOSM or PL2 should suggest it.
https://josm.openstreetmap.de/wiki/Maps has a list of imagery. JOSM goes by
polygon and PL2 goes by bbox. Polygons are more accurate but you should be fine
in the US.
The main imagery source to be aware of country-wide is the USGS aerials. Where
I've examined them they're very well aligned although not always as high a
resolution. They should be suggested but
http://{switch:a,b,c}.tile.openstreetmap.us/usgs_large_scale/{zoom}/{x}/{y}.jpg
should work in JOSM.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US
From: Serge Wroclawski [mailto:emac...@gmail.com] Subject: Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US Since local conditions vary so widely across the US, having more tags gives mappers more flexibility to tag what they see. How does it give them more flexibility to tag what they see? Are you suggesting that this replace (rather than supplement) the name tag? My understanding from the SOTM-US talk is that he proposes redefining what the name tag means and that for a street like K Street NW the name of that street is simply K. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US
From: Mark Gray [mailto:mark-os...@hspf.com] Subject: Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US In taginfo, I see there is already some use: 86023 instances of associatedStreet 14921 instances of Street This is still small compared with: 15461897 addr:street Every time I tag addr:street, I wonder how well it works. What will happen when someone decides to expand the name of the street or edit a prefix or suffix? How does an address stay associated with a street when the link between them, the name, can be edited in either place while no change is made to all the other things on this street? Each addr:street could contain its own unintentional variation of the street name. Having talked to people who process the data for use with geocoding, addr:street is a lot more robust than associatedStreet relations and a lot easier to process. Auto-complete helps with name consistency. I think the reason is that addr:street can be broken each time the name of a road changes while associatedStreet can be broken each time someone edits the street or address for any reason. Although addresses aren't fixed in practice streets aren't often renamed and every way split has a good chance of breaking the relation. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Alaska CPD boundaries
I've been cleaning up and converting the Alaska admin boundaries and relations and I've come across two questions where I could use some more local feedback. I'm not finished yet, I still have to go back and fix some mistakes (ugh) and de-duplicate more ways. As no one had touched most of the boundaries since an import in 2008 I doubt that anyone feels too strongly about them. (a) CPD tagging Alaska is not divided into counties[1] but into boroughs instead. These boroughs do not cover the entire land area of the state. The remainder is part of the unorganized borough (see http://en.wikipedia.org/wiki/Unorganized_borough) The census bureau divided the unorganized borough into 11 census areas. These have no legal significance but serve to sub-divided the state into convenient parts. In spite of this they are in many ways like counties. I've tagged them the same as counties (admin_level=6) but I'm not convinced that this is the best tagging. (b) Coastline boroughs/CPDs For a reference on terms, see http://www.nauticalcharts.noaa.gov/csdl/images/GIS_marineboundaries.jpg I'm not sure where the way showing the limit of the coastline boroughs should be. Currently it is an approximated offset coastline with digitizing artifacts. The options I see are (1) The 12 nautical mile limit (US territorial sea claims) (2) The 3 nautical mile limit (state submerged land limit, traditional territorial sea claims limit) (3) The coastline way (4) The existing crudely drawn inaccurate imported limit. The way for (2) does not exist and would need to be created. Within the accuracy we're likely to have in the region there is no difference between the mean higher high water coastline and the mean lower low water coastline. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Alaska CPD boundaries
From: Paul Norman [mailto:penor...@mac.com] Subject: [Talk-us] Alaska CPD boundaries (2) The 3 nautical mile limit (state submerged land limit, traditional territorial sea claims limit) I'm sort of answering my own question, but the latest TIGER data has it at this limit. I'll go ahead and propose reimporting these - what's existing is too messy to fix up piecemeal and after having reviewed it, it's all unmodified old imported data anyways. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Proposed import: Alaska Boroughs/CPDs
In Alaska the Boroughs and CPDs are the equivalent of counties. I recently cleaned up much of the Canada/Alaska border and in the process looked at the counties data. I have come to the conclusion that it is better and easier to remove the existing counties data and reimport from TIGER 2012. Additionally Alaska created new counties in 2007 and 2008 and these are not reflected in the existing data. Before I did my edits the counties were essentially untouched. Now they're half-fixed but many remain a mess, particularly in coastal regions where there is poor alignment. The majority of the data is in regions where the population density is minimal and we are unlikely to get any eyes on the ground. There is more detail at http://wiki.openstreetmap.org/wiki/Alaska/TIGER_Counties, but in brief the import will be more accurate, not override any existing contributions except mine and be better tagged. I started a discussion about the tagging of boroughs/CPDs which are not exactly like counties at http://lists.openstreetmap.org/pipermail/talk-us/2012-November/009563.html but it shouldn't be difficult to come back later and retag if required as there are a total of 29 objects that could potentially need retagging. It would be a lot easier to retag them post import then to try to retag the current data. I will have to integrate the data with the existing Canada/Alaska border and will preserve that as it is based on the extremely accurate IBC data. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] 3 mile limit
(subject changed because this isn't really about the CPDs anymore) From: Greg Troxel [mailto:g...@ir.bbn.com] Sent: Monday, November 26, 2012 4:48 AM To: Paul Norman Subject: Re: [Talk-us] Alaska CPD boundaries I'm sort of answering my own question, but the latest TIGER data has it at this limit. When did 3 change to 12 as a claimed territory limit? Do you think TIGER is perhaps just not paying attention, because there are no residents from 3 to 12, so they don't care? My standard reference for this is NOAA's short white paper: http://www.nauticalcharts.noaa.gov/csdl/docs/GIS_Learnaboutmaritimezones1pag er.doc The 3 mile zone was extended by Proclamation in 1988. TIGER changed at some point from the coastline (one of them) to the 3 mile limit (from one of the coastlines). As a practical matter the maintaining an accurate coastline definition is difficult - it ended up extremely messy in some areas with all of the little sandbars and islands as detached parts I can't see that TIGER would ever use 12 for boroughs and CPDs - that's outside the state submerged lands. If the state should use the limit of 3 instead of 12 is a different question. OSM is about the ground truth so I don't know what a sailor would say if asked where they were between the 3 mile and 12 mile limits. My experience with borders is with the Canada-US border in BC. Legally speaking you can enter what Washington State claims before you enter the US. At other points it's the other way around. We just go for a consistent set of borders representing what's on the ground. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed import: Alaska Boroughs/CPDs
-Original Message- From: Frederik Ramm [mailto:frede...@remote.org] Sent: Monday, November 26, 2012 8:00 AM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Proposed import: Alaska Boroughs/CPDs Hi, On 11/26/12 05:51, Paul Norman wrote: There is more detail at http://wiki.openstreetmap.org/wiki/Alaska/TIGER_Counties, but in brief the import will be more accurate, not override any existing contributions except mine and be better tagged. Will these new borders correctly re-use parts of the existing coastline and/or state boundary, or will things look like http://www.openstreetmap.org/?lat=36.26415252685547lon=- 95.7297134399414zoom=15 or http://www.openstreetmap.org/?lat=57.16290593147278lon=- 92.50400304794312zoom=15 (both featured on Worst of OSM in the past)? As mentioned, they'll reuse the existing country and state boundary (they're the same for Alaska). On the coast side it turns out that they're defined going to the limit of the state submerged lands which is 3 miles away from the coastline so this isn't an issue and it wouldn't be near any existing boundaries. The current boundaries are pretty bad, see http://www.openstreetmap.org/?lat=70.332lon=-150.568zoom=10 or http://www.openstreetmap.org/?lat=70.48lon=-160.17zoom=9 Or really, just see anywhere on the north slope. I merged the ways so you didn't have individually tagged 100 node sections and now it's one properly done relation, but the geometry is still a horrid mess. Something I didn't mention was import size. This would be on the order of 35k-37k nodes. That's a lot of nodes for the number of ways, but we're talking about kilometers between nodes still. Alaska is *huge*. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Alaska CPD boundaries
From: Greg Troxel [mailto:g...@ir.bbn.com] Sent: Monday, November 26, 2012 4:48 AM Subject: Re: [Talk-us] Alaska CPD boundaries The census bureau divided the unorganized borough into 11 census areas. These have no legal significance but serve to sub-divided the state into convenient parts. In spite of this they are in many ways like counties. I've tagged them the same as counties (admin_level=6) but I'm not convinced that this is the best tagging. If they're just a census division, it seems wrong to call them boroughs (treating them like counties with a different name). Boroughs as counties seem right - it's the way the state divides things less than a state and more than a town. The point of admin_level is government, and census boundaries (for the sole convenience of the census bureau, presumably) are not in any way governments. I must admit I've flipped back and forth on my views on this. I initially wasn't sure if they should be in but I've convinced myself that they should be and admin_level=6 is probably the best. In neither case are we tagging boroughs or CPDs as counties as counties. We're tagging them as admin_level=6 which is what counties in the other 49 states are tagged as. admin_level=6 isn't automatically associated with counties. boundary=administrative is for administrative boundaries, not just government boundaries. Normally the government boundaries are the most meaningful ones but here there are no government boundaries. From a data consumer's perspective I think any analysis done is likely to treat the CPDs as equivalent to the boroughs. They have their own FIPS codes too. Now, if someone local were to come and say the CPDs are meaningless and irrelevant or I say I'm from a CPD the same way someone would say they're from a borough I'd be happy and we'd have a good answer but I don't believe anyone who's commented on the list is a local. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed import: Alaska Boroughs/CPDs
From: Toby Murray [mailto:toby.mur...@gmail.com] Subject: Re: [Talk-us] Proposed import: Alaska Boroughs/CPDs I have been doing a lot of work on county borders in the lower 48. I got to Alaska and the current state of the data plus the whole unorganized borough thing made me go huh? I'll come back to that... later and I haven't made it back yet due to Operation Cowboy and Thanksgiving. Given the state of the data and the changes that have happened in recent years, I think a complete reimport may be a decent way of moving forward. On the unorganized borough, I'm not really sure what the best solution is. One use for county borders in GIS applications is to associate data with them, a lot of times based on the county FIPS code. It looks like these Census Areas do have a county level FIPS code so I do think they have a place in OSM. Whether or not they get an admin_level=6 tag... I don't know. Given that the comments received have been generally positive and the concerns raised are addressed I'm going to go ahead and start post-processing the data so I can merge it in as well as figuring out how the heck to identify all the existing imported borough/CPD boundaries, all tagged differently. Just to be clear, I'm not adjusting the state border in this import. I think it might need adjusting but that's independent of the import. The CPD tagging might get adjusted in the future post-import when we better figure out how to tag CPDs. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed import: Alaska Boroughs/CPDs
From: Paul Norman [mailto:penor...@mac.com] Subject: Re: [Talk-us] Proposed import: Alaska Boroughs/CPDs Given that the comments received have been generally positive and the concerns raised are addressed I'm going to go ahead and start post- processing the data so I can merge it in as well as figuring out how the heck to identify all the existing imported borough/CPD boundaries, all tagged differently. Completed successfully. Because the boundaries are now much less nodey the boundaries went from about 170k nodes to 25k nodes. I added wikipedia=* and website=* tags as applicable. Wikipedia tags should help Nominatim determine importance when there are two places with the same name. As most states aren't adding counties at the rate that Alaska has added boroughs I doubt it'll come up again but I documented the SQL I used to identify and delete the existing boundaries without conflicts on deleted nodes at http://wiki.openstreetmap.org/wiki/Alaska/TIGER_Counties. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Addressing
Ogr will read personal geodatabases with the appropriate drivers so ogr2osm will read them, so if the legal issues can be sorted out there's no problem. From: Steven Johnson [mailto:sejohns...@gmail.com] Sent: Thursday, November 29, 2012 10:04 AM To: Open Street Map Talk-US Subject: Re: [Talk-us] US Addressing I'm wholeheartedly behind this effort as address data have long been an interest. So I just had a quick look at obtaining data for Arlington, VA. The data (current as of May 2012) are available on CD for cost of reproduction ($125) and includes address points, plus parcels, zoning, flood control zones, etc. The data are furnished in ArcGIS *personal* database format ONLY. (I have access to ArcGIS, so could theoretically convert them.) The data are copyrighted and Arlington County owns all rights to the data and allows use ...as an acknowledged source to produce maps or analysis but you may not redistribute, resell, or copy the data (except for back-up purposes). Probably other jurisdictions out there that place similar conditions on their data. -- SEJ -- twitter: @geomantic -- skype: sejohnson8 Common sense is the collection of prejudices acquired by age eighteen. -- Einstein On Thu, Nov 29, 2012 at 12:28 PM, Ian Dees ian.d...@gmail.com wrote: On Thu, Nov 29, 2012 at 10:51 AM, Jeffrey Ollie j...@ocjtech.us wrote: The Iowa DNR has an ongoing project to provide statewide geocoding data. As of this summer they had about 50% of the state covered: http://iagiservicebureau.blogspot.com/2012/06/first-batch-of-geocoding-proje ct-points.html It would be fairly trivial to convert these shape files and import them. That is awesome. I'm adding data to the spreadsheet based on this listing here: ftp://ftp.igsb.uiowa.edu/gis_library/counties/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tools for analysis of road networks?
It's worth noting that the results will be in Mercator meters, not meters.
I have OSM loaded into a pgsnapshot db and can run queries on request.
Something else is that tags-'highway' in ( 'motorway', 'primary',
'secondary' ) will NOT use indexes on tags.
tags @ hstore('highway', 'motorway') OR tags @ hstore('highway',
'primary') OR tags @ hstore('highway', 'secondary') should be significantly
faster with proper indexes.
From: the Old Topo Depot [mailto:oldto...@novacell.com]
Sent: Wednesday, December 05, 2012 9:06 AM
To: Richard Welty
Cc: talk-us@openstreetmap.org
Subject: Re: [Talk-us] tools for analysis of road networks?
Richard,
If the data you're using is in PostGIS ST_Length will give you the length of
all the ways of interest within a bounding box, and, if you reproject to
EPSG:900913 before calling the function you'll get the results in meters.
select ST_length( ST_Transform( linestring, 900913 ) ), id, tags-'highway'
as htype, tags-'name' as name from ways where
tags-'highway' in ( 'motorway', 'primary', 'secondary' )
AND bbox ST_GeometryFromText( 'POLYGON(( -120 34, -119 34, -119 35, -120
35, -120 34 ))', 4326 )
If helpful and you have a bounding box of interest I have an up to date
planet file I can run the query on and send you results
HTH
On Wed, Dec 5, 2012 at 7:14 AM, Richard Welty rwe...@averillpark.net
wrote:
On 12/5/12 10:04 AM, Frederik Ramm wrote:
Hi,
On 12/05/2012 03:55 PM, Richard Welty wrote:
i'm looking at a need to do some analysis estimation based on road nets
extracted from OSM; the goal is to be able to estimate things like time to
complete ground surveys (e.g., TIGER review and collection of hydrant
locations.)
are there any libraries or tools kicking around that folks might have
developed and would be willing to share?
Not a big help but there's a tool in SVN called osm-length that will report
how many metres of each highway type there are in any given OSM XML file.
Could be a start.
thanks, that could be a big help. whatever i develop, i expect to have to
work out
away to distinguish between urban/suburban/rural networks as there is a
distinct
difference in time to survey, although right now i am reluctant to
characterize how
much it really is.
richard
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
--
John Novak
585-OLD-TOPOS (585-653-8676)
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] City of Seattle imports
Apologies for the length, but there are quite a few points to address, some of a specific nature and others more general. Because I'm replying to points across several messages and the formatting in this thread has become screwed up I'll be reformatting messages and re-ordering them so that they make more sense. Imports, as you can probably tell, are an area I care about. Full disclosure: I maintain ogr2osm, the software used for converting geometries in the proposed import. See https://github.com/pnorman/ogr2osm for more information. While I support address imports in principle it is important that they are done right. Back in 2010 I did an address import and although on the whole it was successful I learned some lessons. Jeff Meyer @ http://lists.osm.org/pipermail/imports/2012-December/001602.html From this page: http://wiki.osm.org/wiki/Import/Guidelines#A_checklist, can you advise as to the checklist steps we are not following, or which steps should be added to this checklist? http://wiki.osm.org/wiki/Import/Guidelines#Discuss_import_with_community requires that consultation be done with imports@ and the appropriate local communities. This certainly includes talk-us@. Jeff Meyer @ http://lists.osm.org/pipermail/imports/2012-December/001598.html The current plan is to focus on addresses and building outlines. Sources are currently suggested to be tagged as: source:addr=data.seattle.gov source:path=data.seattle.gov so as to accomodate other sourcing information for those points and ways, as appropriate. The value of source=* tags on objects is debatable. Source tags on changesets are a very good idea but it's not clear if they're a good idea for objects. There are arguments either way. I am working on an as yet unproposed address import and in the initial version I will be proposing I will not be adding source tags to objects. If after consideration you do decide that source tags are worthwhile I would recommend just source=data.seattle.gov. This corresponds with the general practices for the use of source tags. Remember that source tags exist for the convenience of mappers and if they become inconvenient they are not worthwhile. Source tags that are long and cryptic do not help mappers. Some imports have used source tags where it necessary to look up the exact value of the source tag because it was so long and complicated. I quickly found that it wasn't clear what to do with the source tags when editing the addresses, primarily to merge with buildings or POIs. If it wasn't clear to me, the importer, I'm pretty sure it was unclear to other editors. Jeff Meyer @ http://lists.osm.org/pipermail/imports/2012-December/001602.html How will you handle object conflation? Manually and methodically. Although not a trivial problem there is work underway on code that will handle the address-address conflation (https://github.com/pnorman/addressmerge). Address-POI and address-building conflation remains a purely manual job. It shouldn't be too hard to merge addresses with buildings they are within when the building has only one address within in and the building does not itself have an address. Addresses placed by building doors outside the building itself add complications but I expect they are solvable. Having said that it shouldn't be too hard, it's not trivial. Jeff Meyer @ http://lists.osm.org/pipermail/imports/2012-December/001602.html Where is the source of your transformation scripts? From the email above: some translation instructions Cliff has put together. We will include the specific translation code either at a github page or on the http://wiki.osm.org/wiki/Seattle page. Where are the specific data files you're transforming? They are at data.seattle.gov we will provide links to the sources. We will also consider posting separate snapshots of these source datafiles if we can figure out where to host them. To be able to sensibly comment on the tagging and data quality we really need a sample .osm showing what the data is like. One option for hosting it is an account on the dev server. See http://wiki.osm.org/wiki/Dev_Server_Account for more information on this. If this is a problem you could email me a file and I could host it on one of my servers. Because I maintain ogr2osm I'm comfortable reading very complex translations and determining the results without actually running the code. Most people aren't and a .osm file is a good way for people to access the tagging and data quality. Another option for documenting tagging is an appropriate page on the wiki. When I was working on the Alaska county import I documented the tagging I would be using at http://wiki.osm.org/wiki/Alaska/TIGER_Counties#Tagging before I had written the translation file. The correct tagging for the county data was pretty obvious. It also gave me a chance to document the changeset tagging. Jeff Meyer @
Re: [Talk-us] MassGIS building conversion
From: Alex Barth [mailto:a...@mapbox.com] Subject: Re: [Talk-us] MassGIS building conversion On Dec 9, 2012, at 3:51 PM, Jason Remillard remillard.ja...@gmail.com wrote: But, in general, I don't think the MassGIS ID's should be included since they are just the center of mass of the buildings, and there is no indication that they will be preserving them as they update the data set. This is interesting that the id (STRUCT_ID?) is to be dropped. If MassGIS does not track an ID on buildings, how do they properly use this data? Do they use an id that is not in the current data set? Generally speaking preserving such an id would be useful IMO for enabling clear references to outside datasets. E. g. Any future work with the data after it's imported will have to handle buildings without IDs. I included IDs in two of my imports and have found them useless. I think that without a clear plan to use them (i.e. one with code) you shouldn't be including government department specific metadata like this. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] MassGIS building conversion
From: Alex Barth [mailto:a...@mapbox.com] Subject: Re: [Talk-us] MassGIS building conversion Hi Paul - On Dec 10, 2012, at 6:06 PM, Paul Norman penor...@mac.com wrote: Any future work with the data after it's imported will have to handle buildings without IDs. I included IDs in two of my imports and have found them useless. I think that without a clear plan to use them (i.e. one with code) you shouldn't be including government department specific metadata like this. How specifically did you find them useless? I mean was it just that to your knowledge nobody's using them or is there something inherently broken in the case of your imports (e. g. those id's change outside of OSM and hence can't be used as reference). Neither, and it's nothing specific to my imports. Any update strategy has to be able to handle the case where objects are created in OSM without the IDs or the IDs get broken in OSM because they can't be verified. Because anything you do has to handle the case of no IDs, what's the point of them? Lots of people include IDs because they think they might be useful but very seldom are they actually used. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Know of a local user group? Update the page!
I'd say the wiki is likely the least used of the various channels for local OSM communities. Because as part of the DWG I've had to contact local communities in various ways I've seen (in some kind of rough order resembling popularity) - Mailing lists - OSM.org forums - Facebook - Google groups - Other forums I don't see the wiki used very often and I don't think the wiki format is well-suited for a community to use to communicate. From: Jeff Meyer [mailto:j...@gwhat.org] Sent: Monday, December 10, 2012 3:38 PM To: Alex Barth Cc: talk-us@openstreetmap.org Talk Subject: Re: [Talk-us] Know of a local user group? Update the page! Noticing how many of these user groups host sites outside of OSM, is there any update on making the OSM wiki more social / functional for local area community building? (followup to SOTM birds of a feather discussion) Seems suboptimal to have so much out of band activity without greater cross-community OSM social networking. Not saying it's broke, just could be better. : ) - Jeff On Mon, Dec 10, 2012 at 2:48 PM, Alex Barth a...@mapbox.com wrote: Hey everyone - If you're running / aware of a user group in your town, I'd love to ask you for a quick minute to update this page - thank you! http://wiki.openstreetmap.org/wiki/WikiProject_United_States Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 tel:%28%2B1%29%20202%20250%203633 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Jeff Meyer Global World History Atlas www.gwhat.org j...@gwhat.org 206-676-2347 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Mappy Hour suggestions?
From: Steve Coast [mailto:st...@asklater.com] Subject: Re: [Talk-us] Mappy Hour suggestions? Try to find new audiences, this mailing list is saturated with your target market already. So, try google ads or a banner on osm.org. Work with existing local groups (e.g. the seattle group had no real heads up about at least 2 out of the 3 meetings). How do the Seattle local group or other local groups engage with the wider US community? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] MassGIS Building Import Start
A couple of initial comments: Has some kind of simplify been run on the data? Although most of the buildings are quite good some of the curved ones are overnoded (e.g. http://took.paulnorman.ca/imports/massgis/noded.png) If your documentation conflicts with the requirements of the import guidelines (http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a ccount) around a dedicated account it may lead to people importing your data getting blocked. You've asked for a check of the reprojection in the data directory but I don't actually see a data directory anywhere. Could you provide a link? From: Jason Remillard [mailto:remillard.ja...@gmail.com] Sent: Wednesday, December 12, 2012 5:15 PM To: talk-us@openstreetmap.org; impo...@openstreetmap.org Subject: [Talk-us] MassGIS Building Import Start Hello Everybody, I would like to kick off the MassGIS building import. This following is copy/paste from the current wiki ( http://wiki.openstreetmap.org/wiki/MassGIS_Buildings_Import). The external links will work on the wiki. -- On Dec, 2012 http://wiki.openstreetmap.org/wiki/MassGIS MassGIS released a high quality data layer for all http://www.mass.gov/anf/research-and-tech/it-serv-and-support/application-s erv/office-of-geographic-information-massgis/datalayers/structures.html buildings in the entire state of MA. Previously http://wiki.openstreetmap.org/wiki/MassGIS MassGIS only had buildings for Boston and its nearby suburbs. The plan is as follows. Source Data License All http://wiki.openstreetmap.org/wiki/MassGIS MassGIS data is in the public domain. See http://wiki.openstreetmap.org/wiki/MassGIS MassGIS page, and talk-us http://lists.openstreetmap.org/pipermail/talk-us/2012-December/thread.html archives for detailed discussion. A previous (incomplete) version of this data that covers the Boston area has already been imported. From the MA Secretary of state Office http://www.sec.state.ma.us/pre/prepdf/guide.pdf Frequently Asked Questions, first question is What records are public? Every document, paper, record, map, photograph, etc., as defined by law, that is made or received by a government entity or employee is presumed to be a public record From the MA Secretary of state http://www.sec.state.ma.us/arc/arcres/residx.htm Duplication Services, last section. Records created by Massachusetts government are not copyrighted and are available for public use. Copyright for materials submitted to state agencies may be held by the person or organization that created the document. Patrons are responsible for clearing copyright on such materials. For more information on copyright law, please see the U.S. Copyright Office's web page at lcweb.loc.gov/copyright. Scripts A script was written to convert MassGIS shp files to OSM file. Each town has its own zip. Inside of the zip is two OSM files. The first file has all of the buildings, the second file has only the buildings missing from OSM. This has been completed, data is https://docs.google.com/a/twincoastmetrology.com/folder/d/0B6HixOxli_6ldGVk REtxdk5lWGM/edit here. jremillard will update these files. The scripts used for the shape to OSM conversion are also at the same link as the data. Status Tracking A google docs https://docs.google.com/spreadsheet/ccc?key=0Ar0iC0thXzOjdFc4c3diOGZiNlNtX2 ZoOVNacTE3R3c spreadsheet will be used to track progress on each town. People helping with the import will be able to claim a town, mark as town as already building complete, or mark it as skip for the final automated import because of data problems. Who Is Doing This So far OSM users ingalls and jremillard are working on the import. We will work on getting as much help as possible. Getting Help Use the MA osm database extract to get a list of users that have added 10 or more buildings in 2012. We will contact these users and ask if could help with the import. Not completed. Manual Imports - Step 1 It is expected that users doing the town by town import will use their normal osm accounts. The https://docs.google.com/a/twincoastmetrology.com/folder/d/0B6HixOxli_6ldGVk REtxdk5lWGM/edit data will be download into JOSM, visually inspected, fixing any problems, then uploaded. Schema The OSM files that are in the ZIP file will only be tagged with building=yes. The MassGIS building STRUCT_ID will not be included. First, MassGIS made no attempt at preserving the STRUCT_ID when they updated the data set to include the entire state. The MassGIS STRUCT_ID, is based on X,Y centroid, when they updated the building locations, all of the ids changed. Second, No actual scenario came up in the discussion on why somebody might want to link the OSM structure back to the MassGIS data. In fact, nobody could come up with a case where previous imports that did include the original id turned out to be useful to somebody. Thirdly, if somebody really, really does need to link the OSM building to the MassGIS
Re: [Talk-us] [Imports] MassGIS Building Import Start
Imports which don't follow the guidelines may be asked to stop or blocked. This includes imports where the appropriate community consultation wasn't done, imports with legal problems, imports without a dedicated account, and various weird problems. Most cases are dealt with via a private message or a 0-hour block which forces them to log on to osm.org and read it. From: Jeff Meyer [mailto:j...@gwhat.org] Sent: Wednesday, December 12, 2012 6:56 PM To: Paul Norman Cc: Jason Remillard; impo...@openstreetmap.org; OpenStreetMap US Talk Subject: Re: [Talk-us] [Imports] MassGIS Building Import Start Paul - can you elaborate on the point about users being blocked if not using a dedicated account? The guidelines don't point this out it seems contrary to the spirit of there being no right way of doing things in OSM. (Not a policy I agree with, but que sera...). Who does the blocking? Thanks, Jeff ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] MassGIS Building Import Start
CanVec operates with each user using a dedicated account. Using a dedicated account doesn't mean sharing an account. From: Clifford Snow [mailto:cliff...@snowandsnow.us] Sent: Wednesday, December 12, 2012 8:37 PM To: nicholas ingalls Cc: OpenStreetMap US Talk Subject: Re: [Talk-us] [Imports] MassGIS Building Import Start On Wed, Dec 12, 2012 at 7:15 PM, nicholas ingalls nicholas.inga...@gmail.com wrote: In regards to this and previous imports, I have found that this is by no means the law when it comes to imports. In Canada we have / and still are in the lengthy process of importing canvec data for the whole country. We do this in a distributed approach. Each user can upload the data with their own account. This is MUCH better in many cases as it encourages people to upload the canvec data in their own area instead of a user sitting hundreds of miles away uploading with a generic account. It also allows people to be held responsible (in a good way) for their data. With a generic account being used by multiple people mistakes are harder to track to the source. By using individual accounts problems can be more easily tracked. Ie a user is not fixing validator issues before uploading causing problems. With a single user account tracking down the specific uploader is near impossible. I agree with this approach, using individual user id instead of having to create a new import id. We have at least two types of imports, manually by users and bulk done by scripts as well as bots that correct problems. For manually imports I feel using the existing id should be sufficient. For bulk imports, which large needs to be defined, a separate id might be useful. To make it real clear, to me a manual import is cutting and pasting one or more elements (nodes, ways, polygons and multipolygons.) Bulk imports use scripts, such as bulk_upload.py. Where the Mass import is being done manually, I'd go with their plan to use existing user ids. If the user screws up one import, the others might be perfect. Would we expect to remove all of their other imports for one error, or just expect the user to correct the problem? I don't think so. It might help the community to explain exactly why a new id is necessary and what harm not using a separate id creates. I know this criteria has been discussed at length on the discussion list, but I have yet to register any compelling reasoning. -- Clifford OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
