[Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

Gee, what a lot of good chatter here on this list!  However, neither this list 
(nor this requestor) have heard a peep about changing a couple dozen Amtrak 
route network=* tags so all have value Amtrak.  Too easy?  I might simply ask 
forgiveness rather than permission or for feedback, though consensus still 
doesn't feel it has fully emerged, so I'll hold off on this minor change until 
at least somebody says something!

Rail USA does slowly and surely get better.  Nice to be here, everybody.

Remaining in listening mode,
SteveA


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] 'address' tags in Massachusetts

[Max Erickson]

>There is a talk-us-massachusetts@ and I think review of your proposed
>mechanical edit should include that list.

Okay. This is pretty preliminary still, I just decided that feedback
was a good idea. Does that list overlap enough with this one that you
forwarding the message would be sufficient?

>I suspect people would be amenable, but it would be good to publish the
>code, and the proposed files to upload, so that they can be reviewed.

I've put the code at https://github.com/maxerickson/massadd

I guess I should have mentioned in the earlier message that it does
some (conservative) formatting cleanup. Tidying uppercase and
expanding a small number of abbreviations.

There's no OSM file because I don't think it is ready for upload (it's
quick enough to generate if you have curl and python3 installed). The
data at the gist does fully reflect the changes the script would
currently make.

>Also, it certainly makes sense that there are some values that are hard
>to parse.  The obvious approach is to just leave them out (and leave
>them for manual fixing or another day), but I'm not really sure exactly
>what you are proposing to do.

At the moment if the 'address' field is not parsed without error the
script doesn't do anything with that object. There's some 'address'
fields that are parsed incorrectly (mostly they include a po box or a
unit and could be excluded by matching for those). That's part of the
not being ready.

>As for nodes with both the old addr tag and new ones, you imply that the
>simplest way is to clean them up before a mechanical edit.  But that
>implies that if they aren't fixed first, you might do something to those
>nodes, and that seems against the spirit of the mechanical edit policy,
>which involves refraining from changes that you can't basically prove
>are correct.  But I don't expect you'd be doing that, so perhaps you can
>expand on what you meant.

Yeah, it isn't implemented yet but that is what I would do, skip those objects.

Overall I'm not in any hurry, but the majority of the address parse
correctly and after an edit would be used by more data consumers and
show up more clearly in editors and so on. It's something like 100
manual fixes to clear the way for about 3900 automatic splits.


Max

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] 'address' tags in Massachusetts

[Greg Troxel]

There is a talk-us-massachusetts@ and I think review of your proposed
mechanical edit should include that list.

I suspect people would be amenable, but it would be good to publish the
code, and the proposed files to upload, so that they can be reviewed.
(I'm not clear on the rules for mechanical edits; I'm just asking for
that as a local who is not comfortable with non-trivial mechanical edits
without published code.)

Also, it certainly makes sense that there are some values that are hard
to parse.  The obvious approach is to just leave them out (and leave
them for manual fixing or another day), but I'm not really sure exactly
what you are proposing to do.

As for nodes with both the old addr tag and new ones, you imply that the
simplest way is to clean them up before a mechanical edit.  But that
implies that if they aren't fixed first, you might do something to those
nodes, and that seems against the spirit of the mechanical edit policy,
which involves refraining from changes that you can't basically prove
are correct.  But I don't expect you'd be doing that, so perhaps you can
expand on what you meant.

Greg


signature.asc
Description: PGP signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Microsoft Building Import for Greenville, SC

[Mike N]

There is some question about the overall accuracy of the height data in 
this import, but I think the units are correct in meters.  For example, 
the Landmark Building [1] is a known height of 305 feet / 92 meters. [2] 
Mapillary view (from a distance) [3] .


   Microsoft measured it at 101 meters / 331 feet; an error of 26 feet. 
 Since the building is on a slope, it's not known what reference was 
used as the base in the Microsoft height measurement.   A measure of 101 
feet would be 1/3 of the actual height and not what I would expect.


  Hopefully the units weren't mixed by using different units for 
different buildings.  I couldn't see any indication of this in the 
original shape file.


[1] https://www.openstreetmap.org/way/41979319#map=19/34.85453/-82.39767
[2] 
https://www.emporis.com/buildings/127342/landmark-building-greenville-sc-usa
[3] 
https://www.mapillary.com/app/?lat=34.855667=-82.39939=17=photo=lPCYDmX9ZV5E8JMd6xG3Kw


On 3/25/2018 2:54 PM, Leon Karcher wrote:

Hello Mike,

I think that you have made the same mistake as they made with the 
Tampa/Clearwater, FL Microsoft building data import: The height is given 
in feet and inches, but you used metre scheme (x.y) instead of x'y". An 
example:


This commercial building 
 is never 16 meters tall as 
said in its height tag. (View on Mapillary 
) 
If you compare further buildings, you will see that this is applicable 
for all others.


I hope you still can fix it, because the managers of the Florida import 
didn't.


Thanks,
Leon

2018-03-25 20:36 GMT+02:00 Mike N >:


In accordance with Step 6 / item 4 of the imports checklist, the
import and QA is now completed.

Thanks to Microsoft for making building and height data available
and multiplying the efforts of a few local mappers!


On 3/14/2018 10:21 PM, Mike N wrote:


FYI, this is proceeding with 2 people, on dedicated accounts
Greenville_SC_City_MSImport_1 and Greenville_SC_City_MSImport_2

On 1/24/2018 8:28 PM, Mike N wrote:


The OSM Upstate SC group is planning an import of Microsoft
building shapes for the city of Greenville, SC.   The
candidate wiki page is at

https://wiki.openstreetmap.org/wiki/Greenville_SC_Building_Import


    The actual import won't take place for 1-2 months yet to
allow time to review the plans.

    Mike



___
Talk-us mailing list
Talk-us@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-us




___
Talk-us mailing list
Talk-us@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-us






___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Microsoft Building Import for Greenville, SC

[Leon Karcher]

Hello Mike,

I think that you have made the same mistake as they made with the
Tampa/Clearwater, FL Microsoft building data import: The height is given in
feet and inches, but you used metre scheme (x.y) instead of x'y". An
example:

This commercial building  is
never 16 meters tall as said in its height tag. (View on Mapillary
)
If you compare further buildings, you will see that this is applicable for
all others.

I hope you still can fix it, because the managers of the Florida import
didn't.

Thanks,
Leon

2018-03-25 20:36 GMT+02:00 Mike N :

> In accordance with Step 6 / item 4 of the imports checklist, the import
> and QA is now completed.
>
> Thanks to Microsoft for making building and height data available and
> multiplying the efforts of a few local mappers!
>
>
> On 3/14/2018 10:21 PM, Mike N wrote:
>
>>
>> FYI, this is proceeding with 2 people, on dedicated accounts
>> Greenville_SC_City_MSImport_1 and Greenville_SC_City_MSImport_2
>>
>> On 1/24/2018 8:28 PM, Mike N wrote:
>>
>>>
>>> The OSM Upstate SC group is planning an import of Microsoft building
>>> shapes for the city of Greenville, SC.   The candidate wiki page is at
>>>
>>> https://wiki.openstreetmap.org/wiki/Greenville_SC_Building_Import
>>>
>>>The actual import won't take place for 1-2 months yet to allow time
>>> to review the plans.
>>>
>>>Mike
>>>
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Microsoft Building Import for Greenville, SC

[Mike N]

In accordance with Step 6 / item 4 of the imports checklist, the import 
and QA is now completed.


Thanks to Microsoft for making building and height data available and 
multiplying the efforts of a few local mappers!



On 3/14/2018 10:21 PM, Mike N wrote:


FYI, this is proceeding with 2 people, on dedicated accounts 
Greenville_SC_City_MSImport_1 and Greenville_SC_City_MSImport_2


On 1/24/2018 8:28 PM, Mike N wrote:


The OSM Upstate SC group is planning an import of Microsoft building 
shapes for the city of Greenville, SC.   The candidate wiki page is at


https://wiki.openstreetmap.org/wiki/Greenville_SC_Building_Import

   The actual import won't take place for 1-2 months yet to allow time 
to review the plans.


   Mike



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] 'address' tags in Massachusetts

[Max Erickson]

Many POIs in Massachusetts have reasonable address information stored
as a single value in the address tag (mostly from imports before the
'addr:*' scheme was established). Something like 1/2 of the uses of
'address' in OSM are in MA. I'd like to do a mechanical edit that
parses the individual pieces of the addresses and moves them into the
appropriate tags. Here is the work in progress data for the parsing:

https://gist.github.com/maxerickson/1ece717992043316bc615b8a98821efd

There's a few dozen addresses where the simple parsing I've written
doesn't work (lines start with "ERROR") and a few dozen more where a
PO Box means that the proposed parsing is wrong, with the PO box
appearing in the street or such. There's also about 100 occurrences of
an existing 'addr:*' value that does not match the data in the
'address' tag (these aren't visible in the gist). The simplest way to
deal with these issues is to clean them up before applying a
mechanical edit, so feel free to take a look at a couple and clean
them up.


Max

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us