Re: [Talk-us] U.S.-Mexico border fence update

[Paul Norman]

On 1/24/2017 11:24 AM, Michael Corey wrote:

Thanks, folks, these are good suggestions. I think posting the map in
Github is a good first step -- we first have to iron our our licensing
so it's compatible with OSM and with our own licenses.


Just to note, if it's based on the OSM border data, it's automatically 
ODbL and compatible with OSM, so there should be no problems there.


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

Re: [Talk-us] [Imports-us] OSM-Colorado Mappy Hour Denver Buildings Import Discussion

[Mike Thompson]

The data here:
http://gis.drcog.org/datacatalog/content/planimetrics-2014-building-roofprints

Doesn't seem to match the description on the wiki.  Perhaps it has already
been converted partly to the OSM tagging (e.g. sheds and garages are
separate)?



On Tue, Jan 24, 2017 at 6:20 PM, Mike Thompson  wrote:

> Russ,
>
> This is very exciting to see this coming along.  Let me know how I can
> help. Hopefully we can use its success to convince other government bodies
> in Colorado to allow us to import their data into OSM!  Here are a few
> comments.
>
> re: "The Denver Regional Council of Governments (DRCOG), in partnership
> with local governments and public entities, has purchased detailed
> infrastructure data..." - This makes it sound like they purchased a
> commercial dataset, which raises questions about licensing in my mind.  I
> suspect that what happened is they "contracted for the collection of
> detailed infrastructure data..." In other words, it was work for hire, and
> they own all rights to the data,. Therefore, as long as the right official
> within DRCOG signs off, we are good (no third party vendor has any
> ownership rights in the data and doesn't have to be consulted). If this is
> in fact the case, someone may wish to change the wording.
>
> "Tagging Plans", "OTHER_TAG" - does this contain any useful information we
> can map to OSM tags?
>
> re: "Building Roofprints (poly) - Stereo-compiled (3D)"
> * Where applicable, are the buildings in the source data orthogonal
> (square corners) - like we try to create in OSM?
> * re "multi-level commercial/industrial buildings" I presume this means a
> building that has multiple roof heights, not multiple levels/floors inside
> the building. For example a building that has one section that is two
> stories high and has a roof height of 20 feet, and another section that is
> three stories high and has a roof height of 30 feet.
> * re "multi-level commercial/industrial buildings" - consider relations
> to group the various building parts together. [1]
>
> A "parking structure" should probably be tagged:
> amenity=parking
> parking=multi-storey  [3]
> (not sure it should get a building tag)
>
> A "tank" should probably not be tagged as building=, but rather just
> man_made=storage_tank [2]
>
> Not all "medical" buildings will be hospitals.
>
> Nothing is said about how the features other than buildings will be
> imported.
>
> Nothing is said about how the imported data will be conflated with the
> existing OSM data (I see there is a place holder).
>
> re "Merge Colorado Office of Information Technology (OIT) state address
> layer..." - does this data have a ODbL compatible license?
>
> Mike
>
> [1] https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
> [2] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstorage_tank
> [3] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking
>
>
> On Tue, Jan 24, 2017 at 4:21 PM, Russell Deffner 
> wrote:
>
>> Greetings all, this is a cross-post :)
>>
>>
>>
>> For some of you this may be old news/reminder.  Last spring the Denver
>> Regional Council of Governments approached our local group, OSM-Colorado
>> , to discuss if and how a ton of
>> planimetric data that they have collected and released as public domain
>> could also be added to OpenStreetMap.  Since then we’ve been discussing
>> with the local mappers and working together with DRCOG to prepare a pilot
>> import for their building dataset and we’re very close to that goal. This
>> email is mainly a ‘last call’ for the local/US community to review what we
>> have outlined on the wiki: http://wiki.openstreetmap.org/
>> wiki/Denver_Planimetrics_Import before we send notice to the main
>> imports list.
>>
>>
>>
>> The other thing this email is, and why I’m cross-posting, is because we’d
>> love to have you come discuss the import and other OSM stuff at a Mappy
>> Hour tomorrow the 25th; details: https://www.meetup.com/OSM-Col
>> orado/events/237116910/
>>
>>
>>
>> Of course if you can’t make mappy hour please email me any comments,
>> thoughts, suggestions or advice; thank you!
>>
>> =Russ
>>
>>
>>
>> Russell Deffner
>>
>> russdeff...@gmail.com
>>
>>
>>
>> ___
>> Imports-us mailing list
>> imports...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports-us
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports-us] OSM-Colorado Mappy Hour Denver Buildings Import Discussion

[Mike Thompson]

Russ,

This is very exciting to see this coming along.  Let me know how I can
help. Hopefully we can use its success to convince other government bodies
in Colorado to allow us to import their data into OSM!  Here are a few
comments.

re: "The Denver Regional Council of Governments (DRCOG), in partnership
with local governments and public entities, has purchased detailed
infrastructure data..." - This makes it sound like they purchased a
commercial dataset, which raises questions about licensing in my mind.  I
suspect that what happened is they "contracted for the collection of
detailed infrastructure data..." In other words, it was work for hire, and
they own all rights to the data,. Therefore, as long as the right official
within DRCOG signs off, we are good (no third party vendor has any
ownership rights in the data and doesn't have to be consulted). If this is
in fact the case, someone may wish to change the wording.

"Tagging Plans", "OTHER_TAG" - does this contain any useful information we
can map to OSM tags?

re: "Building Roofprints (poly) - Stereo-compiled (3D)"
* Where applicable, are the buildings in the source data orthogonal (square
corners) - like we try to create in OSM?
* re "multi-level commercial/industrial buildings" I presume this means a
building that has multiple roof heights, not multiple levels/floors inside
the building. For example a building that has one section that is two
stories high and has a roof height of 20 feet, and another section that is
three stories high and has a roof height of 30 feet.
* re "multi-level commercial/industrial buildings" - consider relations to
group the various building parts together. [1]

A "parking structure" should probably be tagged:
amenity=parking
parking=multi-storey  [3]
(not sure it should get a building tag)

A "tank" should probably not be tagged as building=, but rather just
man_made=storage_tank [2]

Not all "medical" buildings will be hospitals.

Nothing is said about how the features other than buildings will be
imported.

Nothing is said about how the imported data will be conflated with the
existing OSM data (I see there is a place holder).

re "Merge Colorado Office of Information Technology (OIT) state address
layer..." - does this data have a ODbL compatible license?

Mike

[1] https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
[2] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstorage_tank
[3] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking


On Tue, Jan 24, 2017 at 4:21 PM, Russell Deffner 
wrote:

> Greetings all, this is a cross-post :)
>
>
>
> For some of you this may be old news/reminder.  Last spring the Denver
> Regional Council of Governments approached our local group, OSM-Colorado
> , to discuss if and how a ton of
> planimetric data that they have collected and released as public domain
> could also be added to OpenStreetMap.  Since then we’ve been discussing
> with the local mappers and working together with DRCOG to prepare a pilot
> import for their building dataset and we’re very close to that goal. This
> email is mainly a ‘last call’ for the local/US community to review what we
> have outlined on the wiki: http://wiki.openstreetmap.org/
> wiki/Denver_Planimetrics_Import before we send notice to the main imports
> list.
>
>
>
> The other thing this email is, and why I’m cross-posting, is because we’d
> love to have you come discuss the import and other OSM stuff at a Mappy
> Hour tomorrow the 25th; details: https://www.meetup.com/OSM-
> Colorado/events/237116910/
>
>
>
> Of course if you can’t make mappy hour please email me any comments,
> thoughts, suggestions or advice; thank you!
>
> =Russ
>
>
>
> Russell Deffner
>
> russdeff...@gmail.com
>
>
>
> ___
> Imports-us mailing list
> imports...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] OSM-Colorado Mappy Hour Denver Buildings Import Discussion

[Russell Deffner]

Greetings all, this is a cross-post :)

 

For some of you this may be old news/reminder.  Last spring the Denver
Regional Council of Governments approached our local group, OSM-Colorado
 , to discuss if and how a ton of
planimetric data that they have collected and released as public domain
could also be added to OpenStreetMap.  Since then we've been discussing with
the local mappers and working together with DRCOG to prepare a pilot import
for their building dataset and we're very close to that goal. This email is
mainly a 'last call' for the local/US community to review what we have
outlined on the wiki:
http://wiki.openstreetmap.org/wiki/Denver_Planimetrics_Import before we send
notice to the main imports list.

 

The other thing this email is, and why I'm cross-posting, is because we'd
love to have you come discuss the import and other OSM stuff at a Mappy Hour
tomorrow the 25th; details:
https://www.meetup.com/OSM-Colorado/events/237116910/ 

 

Of course if you can't make mappy hour please email me any comments,
thoughts, suggestions or advice; thank you!

=Russ

 

Russell Deffner

russdeff...@gmail.com

 

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

Re: [Talk-us] U.S.-Mexico border fence update

[Michael Corey]

Thanks, folks, these are good suggestions. I think posting the map in
Github is a good first step -- we first have to iron our our licensing
so it's compatible with OSM and with our own licenses.

So this will likely not happen this week, but hopefully soon.

Thanks again!

Michael Corey
Senior News Applications Developer
o: 510.809.3178
twitter: @mikejcorey

On 01/24/2017 08:57 AM, Martijn van Exel wrote:
> We could devise a MapRoulette challenge out of it (and could claim that 
> OpenStreetMap has a tight border with Mexico before the Trump administration, 
> AND nobody paid for it)
> Martijn
> 
>> On Jan 23, 2017, at 4:35 PM, Clifford Snow > > wrote:
>>
>> Michael,
>> Sharing your new work on GitHub would be a good start. The community could 
>> look at the work and see how to best incorporate it into OSM. 
>>
>> (We could tag the existing fence as before_trump and if anything actually 
>> gets built as by_trump. )
>>
>> Clifford
>>
>> On Mon, Jan 23, 2017 at 2:13 PM, Michael Corey > > wrote:
>> Hello:
>>
>> (Also posted in imports)
>>
>> Several years ago I did a lot of work adding sections of the U.S.-Mexico
>> border fence to OSM. In light of the new U.S. president's intention to
>> expand the fence/wall system, I have been updating that work for our
>> news organization. We have now mapped the entire existing fence with
>> significantly more official data and more information about individual
>> segments.
>>
>> I would like to share this work back into OpenStreetMap, but it may be
>> difficult to modify or sync up with my old work, since I have
>> changed/added/subtracted significant features.
>>
>> Does anyone have thoughts on how to do this most efficiently and without
>> causing major headaches? I would like to share the maps on both OSM and
>> on Github, so I will need some kind of workflow to keep everything
>> synced up.
>>
>> The current fence is captured by this relation:
>>
>> https://www.openstreetmap.org/relation/2266294 
>> 
>>
>> Any advice people have from past experience would be most welcome.
>>
>> Thanks much,
>>
>>
>> --
>>
>> Michael Corey
>> Senior News Applications Developer
>> o: 510.809.3178 
>> twitter: @mikejcorey
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-us 
>> 
>>
>>
>>
>> -- 
>> @osm_seattle
>> osm_seattle.snowandsnow.us 
>> OpenStreetMap: Maps with a human touch
>> ___
>> 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] U.S.-Mexico border fence update

[Martijn van Exel]

We could devise a MapRoulette challenge out of it (and could claim that 
OpenStreetMap has a tight border with Mexico before the Trump administration, 
AND nobody paid for it)
Martijn

> On Jan 23, 2017, at 4:35 PM, Clifford Snow  > wrote:
> 
> Michael,
> Sharing your new work on GitHub would be a good start. The community could 
> look at the work and see how to best incorporate it into OSM. 
> 
> (We could tag the existing fence as before_trump and if anything actually 
> gets built as by_trump. )
> 
> Clifford
> 
> On Mon, Jan 23, 2017 at 2:13 PM, Michael Corey  > wrote:
> Hello:
> 
> (Also posted in imports)
> 
> Several years ago I did a lot of work adding sections of the U.S.-Mexico
> border fence to OSM. In light of the new U.S. president's intention to
> expand the fence/wall system, I have been updating that work for our
> news organization. We have now mapped the entire existing fence with
> significantly more official data and more information about individual
> segments.
> 
> I would like to share this work back into OpenStreetMap, but it may be
> difficult to modify or sync up with my old work, since I have
> changed/added/subtracted significant features.
> 
> Does anyone have thoughts on how to do this most efficiently and without
> causing major headaches? I would like to share the maps on both OSM and
> on Github, so I will need some kind of workflow to keep everything
> synced up.
> 
> The current fence is captured by this relation:
> 
> https://www.openstreetmap.org/relation/2266294 
> 
> 
> Any advice people have from past experience would be most welcome.
> 
> Thanks much,
> 
> 
> --
> 
> Michael Corey
> Senior News Applications Developer
> o: 510.809.3178 
> twitter: @mikejcorey
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us 
> 
> 
> 
> 
> -- 
> @osm_seattle
> osm_seattle.snowandsnow.us 
> OpenStreetMap: Maps with a human touch
> ___
> 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] I think I got this right...

[Martijn van Exel]

The only problem I can see is that you may then have three levels of relation 
hierarchy[1] which I find troublesome because it will make numbered route 
management harder for most people to know how to do.

Don’t get me wrong, I don’t particularly like the complexity of having to 
maintain each member role either, but I think this could be more easily fixed 
by smart JOSM parsing (or a JOSM plugin) than having more levels of relations. 
I also think the member role approach would probably sit better with the 
international community.

Martijn

[1] Super-super-relation for state, super-relation for cardinal direction, 
relations for each direction.

> On Jan 23, 2017, at 12:12 PM, Paul Johnson  > wrote:
> 
> On Mon, Jan 23, 2017 at 12:14 PM, Martijn van Exel  > wrote:
> Well, in this case, the only way to know for a routing application what the 
> cardinal direction is, is to look at the member roles. Either that our you 
> slice the relation up even more to have separate relations for east / west / 
> north / south, which to my mind would make for a too-convoluted relationship 
> hierarchy. What is your thought on indicating cardinal direction in this case 
> if not as member role?
> 
> I'm not sure where the problem is with child relations with direction=* tags 
> as one of the relation tags is exactly.  Sure, takes more to set up, but it's 
> easier to maintain long term.
> ___
> 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