[OSM-talk] Congratulations to new OSMF board members Jean-Marc, Tobias, and Eugene

[Michal Migurski]

As it says in the subject, congratulations to our three new board members!

I’m especially excited to see representation for the dynamic, exciting 
Philippines community.

I hope good things happen in 2021. I greatly enjoyed running for the board 
again this year and I was pleased to see a lot of energetic conversation on 
this list. I’m thrilled to see strong, boardly-supported momentum for a 
meaningful code of conduct thanks to the efforts of Céline, Heather, and 
everyone else who participated and commented on that topic. A CoC was one of my 
three campaign priorities and there’s no reason it must happen exclusively in 
the context of the board itself. We’ve already seen fast action from the 
previous board to put this in the hands of the LCC WG and I look forward to 
helping push that forward.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions

[Michal Migurski]

Hi Robert, Christoph, and Mateusz, thanks again for continuing to engage in 
this thread!

I’m going to post just once more since I think we’re reaching the limits of how 
much I can say on behalf of my employer here. I’m participating as a way to 
make myself available for questions and feedback during the board campaign, 
expand on my manifesto and Q, and hopefully make a case for why I’d be a 
helpful addition to the OSMF board.

I want to make sure that I am not mischaracterizing the points of view 
expressed upthread, so I’ll do my best to restate them: attribution is a form 
of remuneration or gratitude to the mappers who build the map, its high visual 
prominence is a sign of respect toward the OSM project, and the desired goal of 
attribution is to inform end-users of the ingredients that make up a basemap 
they’re seeing. This is adapted and condensed from Christoph’s wiki entry, I 
hope I’m conveying the key points correctly. As a board member, these points of 
view will be important for me to understand.

Commenters on this topic have compared OSM attribution to commercial 
attribution for data vendor companies, and suggested using their model of 
requiring equally-prominent logos and links. OSM is bigger and more important 
than this. I can talk more about why if anyone’s interested but the short 
version is that frontline engineers and designers at companies who use OSM data 
create powerful internal pressure to choose OSM in serious “build vs. buy” 
debates. OSM often wins because of its openness and flexibility, and its key to 
growth is awareness and participation from motivated experts. This is a much 
more interesting winning strategy than that employed by commercial vendors.

The OSMF board supports the interests of community members, and I would seek to 
do the same. I’ll improve the board’s decisions with respect to large, 
organized OSM community members poorly represented by past boards or venues 
like this talk@ list. I’d like to see other contributors like humanitarian 
mappers or new geographies on the board as well, and my manifesto calls for 
support of the candidates from Cameroon and the Philippines.

Thanks again to those of you who participating in the conversation.

For those using or defending rape metaphors, shame on you.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Dec 2, 2020, at 1:50 PM, Michal Migurski  wrote:
> 
> Hi Robert, Martin, Alexandre, Jochen, Richard, Tom:
> 
> Thanks for your followups in this conversation! I am speaking here as an 
> individual and not on behalf of Facebook, so I’m going to focus on the areas 
> relevant to board candidacy.
>  
> First, the text of the ODbL is explicit about “reasonably calculated” 
> awareness. FB believes its maps comply with this. The ODbL does not require 
> that “every” person see the attribution. It requires that “any” person can. 
> FB’s attribution to OSM is available to any viewer in a place that is 
> commonly associated with attribution.
> 
> Successful attribution guidelines published by the OSMF will make it much 
> easier to decide how to interpret the ODbL. As a board member with experience 
> in cartography design & implementation and OSM-relevant companies my 
> involvement will make it more likely that the eventual attribution guidelines 
> work for everyone.
> 
> A few of you have pushed back on my “beyond the ODbL” framing in my prior 
> reply. I don’t want to repeat myself too much, but the ODbL is very terse and 
> leaves a lot of room for interpretation. Common practices for data 
> attribution in map and non-map domains rely on click-through interactions 
> like the ones FB uses. This is a completely reasonable way to make users 
> aware of the source of map data to the extent that viewers know that maps are 
> made of data, that it is often sourced externally, and that the words in the 
> corner of a map are relevant to how that basemap was produced and not (for 
> example) the location of a friend or venue overlaid on top of it. The 
> community here on talk@ is understandably focused on basemap attribution, but 
> in the context of the many hundreds of ways that FB uses maps in its products 
> and the many sources of that data, there’s also important design and 
> interaction considerations with dramatically more needs to keep in balance. 
> The power of OSM has always been its openness to new kind of uses beyond 
> simple display maps. My interest as a board member is in maintaining this 
> open approach to uses that are bigger, weirder, more niche, or otherwise 
> different than OSM might have previously imagined.
> 
> Second, Jochen examines further the issue of conflict of interest. All of us 
> involved in OSM represent a var

Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions

[Michal Migurski]

Hi Robert, Martin, Alexandre, Jochen, Richard, Tom:

Thanks for your followups in this conversation! I am speaking here as an 
individual and not on behalf of Facebook, so I’m going to focus on the areas 
relevant to board candidacy.
 
First, the text of the ODbL is explicit about “reasonably calculated” 
awareness. FB believes its maps comply with this. The ODbL does not require 
that “every” person see the attribution. It requires that “any” person can. 
FB’s attribution to OSM is available to any viewer in a place that is commonly 
associated with attribution.

Successful attribution guidelines published by the OSMF will make it much 
easier to decide how to interpret the ODbL. As a board member with experience 
in cartography design & implementation and OSM-relevant companies my 
involvement will make it more likely that the eventual attribution guidelines 
work for everyone.

A few of you have pushed back on my “beyond the ODbL” framing in my prior 
reply. I don’t want to repeat myself too much, but the ODbL is very terse and 
leaves a lot of room for interpretation. Common practices for data attribution 
in map and non-map domains rely on click-through interactions like the ones FB 
uses. This is a completely reasonable way to make users aware of the source of 
map data to the extent that viewers know that maps are made of data, that it is 
often sourced externally, and that the words in the corner of a map are 
relevant to how that basemap was produced and not (for example) the location of 
a friend or venue overlaid on top of it. The community here on talk@ is 
understandably focused on basemap attribution, but in the context of the many 
hundreds of ways that FB uses maps in its products and the many sources of that 
data, there’s also important design and interaction considerations with 
dramatically more needs to keep in balance. The power of OSM has always been 
its openness to new kind of uses beyond simple display maps. My interest as a 
board member is in maintaining this open approach to uses that are bigger, 
weirder, more niche, or otherwise different than OSM might have previously 
imagined.

Second, Jochen examines further the issue of conflict of interest. All of us 
involved in OSM represent a variety of interests that we bring to the map. My 
candidacy for the board is explicitly driven by a desire to see commercial and 
organizational use of OSM better represented in the OSMF. In some specific 
cases there may be a conflict of interest where I’d recuse myself, but in 
general it’s much more likely that FB and other companies’ need for a 
high-quality, free, global map with a healthy org behind it is *strongly 
aligned* with OSMF’s interests. I’ve held this belief for many years and in 
many organizations. As a board member I would work with members representing 
other OSM constituencies to make sure all these overlapping needs and desires 
lead to an OSM that’s stronger together.

Thanks everyone for your words in the thread so far. The annual election 
process is important because it’s one of the only venues OSM has typically had 
to ask itself tough questions and make important decisions.

-mike.

----
michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Nov 30, 2020, at 11:00 AM, Michal Migurski  wrote:
> 
> Hi everyone,
> 
> I’m excited to be running for the OSMF board this year! In 2021, OSM’s 
> community has two opportunities to grow stronger together: we should make the 
> OSM organization support a wider diversity of participants and we must 
> succeed at starting to manage our technical operations professionally.
> 
> I’d like to make myself available for conversations with anyone who has 
> questions about my candidacy, manifesto, priorities, or really anything else. 
> I did this last year when I ran and ended up having a few really fun 
> conversations with community members. I’m blocking these four times over the 
> next two weeks prior to the close of voting and AGM on Dec 12; get in touch 
> via email if you’d like to chat by text, voice, or video!
> 
>   • Dec 1, 16:00 PST – 
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201201T16=388=1
>  
> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201201T16=388=1>
>   • Dec 3, 8:00 PST – 
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201203T08=388=1
>  
> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201203T08=388=1>
>   • Dec 4, 16:00 PST – 
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201205T16=388=1
>  
> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=

Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions

[Michal Migurski]

Great questions, thanks Mateusz!

I’ll start with #2 because the answer is very straightforward: I would recuse 
myself from cases where there is a conflict of interest between the 
OpenStreetMap Foundation and my employer or other organizations whose boards I 
serve on (currently PlanScore, Facebook, GreenInfo Network, and Digital 
Democracy).

#1 is a two-parter.

Facebook is in compliance with the ODbL license which requires that attribution 
be “reasonably calculated to make any Person that uses, views, accesses, 
interacts with, or is otherwise exposed to the Produced Work aware” of OSM’s 
contribution to a map. FB’s attribution approach in keeping with best practices 
seen from other commercial users of display maps.

Parts of the community have expressed a desire to see attribution that goes 
beyond the ODbL. OSMF and its LWG have been developing new OSM-specific 
attribution guidelines since late 2019 with proposed rules for different screen 
sizes, number of clicks, and privileged position of OSM contributors relative 
to other data sources. Currently, these are not yet finalized. Once these are 
released, Facebook would revisit attribution decisions in light of the wishes 
of the OSMF.

I hope this answers your questions!

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Dec 1, 2020, at 9:12 AM, Mateusz Konieczny via talk 
>  wrote:
> 
> (1)
> In 2019 you answered
> 
> "we’re moving toward a consolidated approach to maps at Facebook. Thus, you 
> will soon
> see us take a more uniform approach to the way we handle attribution across 
> all map
> surfaces across the company"
> 
> to question[1] about illegal OSM data use (without proper attribution) by 
> Facebook, MAPS.ME
> and Moovit[2].
> 
> Do you consider current attribution used by Facebook as sufficient and 
> displayed to all users,
> as required by ODBL license?
> 
> 
> 
> (2)
> Would you recuse yourself from cases where there is conflict of interest 
> between OSM
> and Facebook?
> 
> For example on issues such us
> - enforcing attribution requirements
> - protecting OSMF from takeover by corporations, such as Facebook
> - handling paid/organized editing
> 
> ?
> 
> 
> [1] 
> https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board/Answers_and_manifestos
>  
> <https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board/Answers_and_manifestos>
> [2] MAPS.ME still has insufficient attribution, with 1.5 sec flash on opening 
> and "MAPS.ME"
> attribution otherwise, Moovit fixed its attribution in Android app
> 
> Nov 30, 2020, 21:04 by m...@teczno.com:
> Absolutely!
> 
> 
> michal migurski- contact info and pgp key:
> sf/cahttp://mike.teczno.com/contact.html 
> <http://mike.teczno.com/contact.html>
> 
>> On Nov 30, 2020, at 11:53 AM, Mateusz Konieczny via talk 
>> mailto:talk@openstreetmap.org>> wrote:
>> 
>> Is it also OK to ask questions also in public via mailing list?
>> 
>> 
>> Nov 30, 2020, 20:00 by m...@teczno.com <mailto:m...@teczno.com>:
>> Hi everyone,
>> 
>> I’m excited to be running for the OSMF board this year! In 2021, OSM’s 
>> community has two opportunities to grow stronger together: we should make 
>> the OSM organization support a wider diversity of participants and we must 
>> succeed at starting to manage our technical operations professionally.
>> 
>> I’d like to make myself available for conversations with anyone who has 
>> questions about my candidacy, manifesto, priorities, or really anything 
>> else. I did this last year when I ran and ended up having a few really fun 
>> conversations with community members. I’m blocking these four times over the 
>> next two weeks prior to the close of voting and AGM on Dec 12; get in touch 
>> via email if you’d like to chat by text, voice, or video!
>> 
>> • Dec 1, 16:00 PST – 
>> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201201T16=388=1
>>  
>> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201201T16=388=1>
>> • Dec 3, 8:00 PST – 
>> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201203T08=388=1
>>  
>> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201203T08=388=1>
>> • Dec 4, 16:00 PST – 
>> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201205T16=388=1

Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions

[Michal Migurski]

Absolutely!


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Nov 30, 2020, at 11:53 AM, Mateusz Konieczny via talk 
>  wrote:
> 
> Is it also OK to ask questions also in public via mailing list?
> 
> 
> Nov 30, 2020, 20:00 by m...@teczno.com:
> Hi everyone,
> 
> I’m excited to be running for the OSMF board this year! In 2021, OSM’s 
> community has two opportunities to grow stronger together: we should make the 
> OSM organization support a wider diversity of participants and we must 
> succeed at starting to manage our technical operations professionally.
> 
> I’d like to make myself available for conversations with anyone who has 
> questions about my candidacy, manifesto, priorities, or really anything else. 
> I did this last year when I ran and ended up having a few really fun 
> conversations with community members. I’m blocking these four times over the 
> next two weeks prior to the close of voting and AGM on Dec 12; get in touch 
> via email if you’d like to chat by text, voice, or video!
> 
> • Dec 1, 16:00 PST – 
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201201T16=388=1
>  
> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201201T16=388=1>
> • Dec 3, 8:00 PST – 
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201203T08=388=1
>  
> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201203T08=388=1>
> • Dec 4, 16:00 PST – 
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201205T16=388=1
>  
> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201205T16=388=1>
> • Dec 9, 8:00 PST – 
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201209T08=388=1
>  
> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201209T08=388=1>
>  
> 
> Read my complete manifesto on the Wiki for more about why I think I’d make a 
> good OSMF board member: 
> https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos/Michal_Migurski#Manifesto
>  
> <https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos/Michal_Migurski#Manifesto>
>  
> 
> -mike.
> 
> 
> michal migurski- contact info and pgp key:
> sf/cahttp://mike.teczno.com/contact.html 
> <http://mike.teczno.com/contact.html>
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

[OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions

[Michal Migurski]

Hi everyone,

I’m excited to be running for the OSMF board this year! In 2021, OSM’s 
community has two opportunities to grow stronger together: we should make the 
OSM organization support a wider diversity of participants and we must succeed 
at starting to manage our technical operations professionally.

I’d like to make myself available for conversations with anyone who has 
questions about my candidacy, manifesto, priorities, or really anything else. I 
did this last year when I ran and ended up having a few really fun 
conversations with community members. I’m blocking these four times over the 
next two weeks prior to the close of voting and AGM on Dec 12; get in touch via 
email if you’d like to chat by text, voice, or video!

• Dec 1, 16:00 PST – 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201201T16=388=1
 
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201201T16=388=1>
• Dec 3, 8:00 PST – 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201203T08=388=1
 
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201203T08=388=1>
• Dec 4, 16:00 PST – 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201205T16=388=1
 
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201205T16=388=1>
• Dec 9, 8:00 PST – 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201209T08=388=1
 
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Campaign+Office+Hours=20201209T08=388=1>
 

Read my complete manifesto on the Wiki for more about why I think I’d make a 
good OSMF board member: 
https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos/Michal_Migurski#Manifesto
 
<https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos/Michal_Migurski#Manifesto>
 

-mike.

--------
michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

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

Re: [OSM-talk] more engaging “about” page

[Michal Migurski]

I turned this into a PR, 

https://github.com/openstreetmap/openstreetmap-website/pull/2735

This change covers just the two English locales.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Jul 27, 2020, at 9:59 AM, Alex Dawn  wrote:
> 
> I'd agree with that, it was quite a while before I registered an account. 
> Then I did do GIS for work, but was thinking there's probably a big 
> difference between loading a couple of shape files and being a "GIS 
> professional" who makes and manages a world map. Turns out there's not, more 
> nudges to make baby steps would be good.
> 
> Get Outlook for Android <https://aka.ms/ghei36>
> From: Martin Koppenhoefer 
> Sent: Monday, July 27, 2020 4:06:52 PM
> To: talk@openstreetmap.org 
> Subject: [OSM-talk] more engaging “about” page
>  
> Looking at
> 
> https://www.openstreetmap.org/about <https://www.openstreetmap.org/about>
> 
> I thought it was not very engaging and we might want to make some small 
> adjustments to make it more inviting for people to contribute.
> 
> Specifically the paragraph:
>> Community Driven
>> OpenStreetMap's community is diverse, passionate, and growing every day. Our 
>> contributors include enthusiast mappers, GIS professionals, engineers 
>> running the OSM servers, humanitarians mapping disaster-affected areas, and 
>> many more. To learn more about the community, see the OpenStreetMap Blog 
>> <https://blog.openstreetmap.org/>, user diaries 
>> <https://www.openstreetmap.org/diary>, community blogs 
>> <https://blogs.openstreetmap.org/>, and the OSM Foundation 
>> <https://www.osmfoundation.org/> website.
>> 
> 
> it points to the official blog, user diaries, community blogs and the osmf 
> website.
> 
> My suggestion would be to
> 
> 1. add “people like you, e.g. ” before “enthusiast mappers, GIS 
> professionals, ...”  and to
> 
> 2. add “how to contribute” as link to “ 
> https://wiki.openstreetmap.org/wiki/How_to_contribute 
> <https://wiki.openstreetmap.org/wiki/How_to_contribute>” right after “see” 
> and before “the OpenStreetMap blog, user diaries.”
> 
> What do you think?
> 
> Cheers Martin 
> 
> sent from a phone
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

[OSM-talk] Q site update from Ops (was: our Q site help.openstreetmap.org is dying)

[Michal Migurski]

Hi Everyone,

Since Tobias Wrede started this thread in May, the Ops group has discussed the 
Help site during our regular meetings. We understand the importance of the Q 
site and acknowledge that the software running it is old and under-maintained.

In addition to the possibility of moving the site to a new platform like the 
ones mentioned in this thread, we’ve also verified that all past Q content 
can be archived [1] regardless of future platform and talked about potential 
underlying causes of the frontend script problems some users have experienced 
[2]. Currently, the Ops group has two initial conclusions:

1) We aren’t able to confirm the extent of the Javascript problems described in 
this thread because we lack a front-end monitoring that would provide this 
information. Our existing monitoring extensively covers the underlying server, 
shenron [3], alongside superficial uptime measurements [4].

2) The Q server is shared by Trac and SVN services which are being deprecated 
over the next month [5]. Deprecating Trac and SVN will allow us to better 
isolate and observe problems that Q is experiencing, and perhaps solve them 
by removing these competing services on one of OSM’s older pieces of hardware.

Over the next two months, I’ll be watching the thread [2] for reports of new 
failures. If these continue past August when SVN and Trac have been deprecated, 
we’ll add monitoring to better understand their cause and determine what work 
may be needed to fix or migrate OSM’s Q site.

-mike.

Links:
1. https://ops.pads.ccc.de/meeting-202006-A (archiving report starts at line 
173)
2. 
https://help.openstreetmap.org/questions/74831/why-does-the-add-a-new-comment-button-sometimes-not-work?
 
3. 
https://munin.openstreetmap.org/openstreetmap.org/shenron.openstreetmap.org/index.html
 
4. https://uptime.openstreetmap.org  
5. https://lists.openstreetmap.org/pipermail/dev/2020-July/030958.html 

Ops Meeting Minutes:
- https://ops.pads.ccc.de/meeting-202005-B (July 1)
- https://ops.pads.ccc.de/meeting-202006-A (June 4)
- https://ops.pads.ccc.de/meeting-202007-A (May 22)


> On May 20, 2020, at 12:28 AM, Tobias Wrede  wrote:
> 
> Hi,
> 
> we have several channels in OSM to facilitate discussions and support. First 
> touch point for new users is often help.openstreetmap.org. Questions relating 
> to mapping in general, tagging, editors, development, OSM based applications 
> are asked there and get answered in most cases.
> 
> The site is based on OSQA, a software which has not been maintained in some 
> time. Some application errors have surface in the past but had to be ignored 
> since no fixes are coming from OSQA any more. Until now we could live with 
> that. They were annoying but not critical. There are open tickets on OSM 
> github to move the help site to some other framework 
> (https://github.com/openstreetmap/operations/issues/149, 
> https://github.com/openstreetmap/operations/issues/377) but there isn't 
> exactly an abundance of volunteers to take care of that.
> 
> Usability of help.openstreetmap.org has now seriously worsened over the past 
> few days with some js error popping up for longer and longer times 
> (https://help.openstreetmap.org/questions/74831/why-does-the-add-a-new-comment-button-sometimes-not-work).
>  Buttons to support formatting questions and answers are gone, comments 
> cannot be added and moderation functions (reporting, converting questions to 
> comments etc.) are not working anymore.
> 
> If this continuous we can shut down the site soon. Even if this problem got 
> resolved somehow it's only a matter of time until a new problem arises. The 
> site provides a low entry hurdles place to ask questions that can be solved 
> by simple answers. I'd hate so see it gone.
> 
> I'm neither a programmer who could help out on the technical side nor am I 
> involved in OSM organization and politics to have an idea on how this could 
> be sorted out. Question around: Can we find someone to take care of the 
> technical side? Can we involve any of the OSM organizations to find, maybe 
> pay, someone? Does the community even find it worthwhile keeping the site?
> 
> cheers,
> 
> Tobias
> 
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] Import of addresses for San Francisco, CA

[Michal Migurski]

One building can definitely have more than a single address.

Addresses provide postal delivery information and don't necessarily correspond 
1:1 with other concepts like physical buildings or legal parcels.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Jun 18, 2020, at 11:08 AM, Joseph Eisenberg  
> wrote:
> 
> Legally in San Francisco does the address refer to the property, the 
> building, or the entrance? 
> 
> While I'm from California originally, I admit that I don't know the 
> definition of an address there. 
> 
> If one building can have more than one address (based on separate entrances), 
> then it would be best to use nodes.
> 
> - Joseph Eisenberg
> 
> On Thu, Jun 18, 2020 at 9:36 AM Yury Yatsynovich  <mailto:yury.yatsynov...@gmail.com>> wrote:
> I saw addresses in SF mapped both ways -- some are mapped as nodes inside the 
> buildings or on contours of buildings (as entrances); others are added 
> directly on the ways/relations of buildings.
> 
> On Thu, Jun 18, 2020 at 12:20 PM Joseph Eisenberg  <mailto:joseph.eisenb...@gmail.com>> wrote:
> >  matching buildings to address points
> 
> I support the idea of adding missing addresses. However, is it best practice 
> to match the address with the building area? 
> 
> Currently in SF are almost all addresses matched with buildings, or are some 
> mapped as nodes or separate area features?
> 
> -- Joseph Eisenberg
> 
> On Thu, Jun 18, 2020 at 8:30 AM Yury Yatsynovich  <mailto:yury.yatsynov...@gmail.com>> wrote:
> Greetings!
> 
> I've been recently thinking about importing addresses for San Francisco, CA.
> It looks like there has been interest in this kind of import (the page 
> devoted to it was created in 2010, 
> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import 
> <https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import>).
> 
> So, please, consider this message as my "community buy-in": does anyone have 
> any objections related to this possible import?
> By now I've obtained a permit from the data owner 
> (https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p
>  
> <https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p>)
>  and almost finished writing my code for matching buildings to address points.
> 
> If there are no objections, I'll go on with organising all documentation and 
> sharing the code/resulting .osm-files for review by OSM community.
> 
> Looking forward to receiving your feedback!
> 
> p.s. I have some experience in importing addresses (e.g., see 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses 
> <https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses>)
> 
> 
> 
> 
> -- 
> Yury Yatsynovich
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org <mailto:Talk-us@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-us 
> <https://lists.openstreetmap.org/listinfo/talk-us>
> 
> 
> -- 
> Yury Yatsynovich
> ___
> 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] Import of addresses for San Francisco, CA

[Michal Migurski]

I support this import.

I would also support the import of addresses for neighboring Oakland, CA.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Jun 18, 2020, at 8:23 AM, Yury Yatsynovich  
> wrote:
> 
> Greetings!
> 
> I've been recently thinking about importing addresses for San Francisco, CA.
> It looks like there has been interest in this kind of import (the page 
> devoted to it was created in 2010, 
> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import 
> <https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import>).
> 
> So, please, consider this message as my "community buy-in": does anyone have 
> any objections related to this possible import?
> By now I've obtained a permit from the data owner 
> (https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p
>  
> <https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p>)
>  and almost finished writing my code for matching buildings to address points.
> 
> If there are no objections, I'll go on with organising all documentation and 
> sharing the code/resulting .osm-files for review by OSM community.
> 
> Looking forward to receiving your feedback!
> 
> p.s. I have some experience in importing addresses (e.g., see 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses 
> <https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses>)
> 
> 
> 
> 
> -- 
> Yury Yatsynovich
> ___
> 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: [OSM-talk] Announcing Daylight Map Distribution

[Michal Migurski]

Thanks Mikel for your followup!

In response to your recommendation that we publish what *didn't* make it 
through the filter process, we released an OSC diff file:


https://daylight-map-distribution.s3.amazonaws.com/pbf/planet-2020-03-06_v0.1.osc.bz2
 
<https://daylight-map-distribution.s3.amazonaws.com/pbf/planet-2020-03-06_v0.1.osc.bz2>

At this early stage of trying to determine what’s useful for the community, 
it’s pretty raw. The OSC does not yet differentiate between things we filtered 
out categorically because we don't show them on our maps, vs. things we 
filtered out individually because we found a problem with them. Individual tree 
nodes are an example of the former: they don't get shown or labeled so they’re 
not in Daylight.

I appreciate everyone’s questions about this data release. The FB team behind 
Daylight and our other mapping efforts is well aware that OSM is a tough and 
curious community!

-mike.

----
michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Mar 10, 2020, at 1:20 PM, Mikel Maron  wrote:
> 
> Thanks Mike and Facebook for doing this. I commented on your diary post, but 
> also adding to the coversation here. It's great to have this insight out and 
> available. There's a good tradition of downstream data processing and 
> redistribution in the community (you could call them packages I supposed) -- 
> from GeoFabrik's regional and country downloads, to OSMQATiles, etc.
> 
> 
> In this case (and I focused on this when we spoke), I'm not sure that the 
> most valuable thing to distribute is what made it through Facebook filters, 
> but rather what didn't make it through and why. That insight is valuable to 
> identify problems that need fixing on a faster basis, notify local 
> communities and other editors, and to build up a corpus of understanding of 
> what problematic edits in OSM look like.
> 
> 
> The most actionable way to do this distribution will be through OSMCha. 
> Through the OSMCha API, you can flag changesets/features with reasons, and 
> can be set up so that any reason tag by Facebook has a "Facebook:" prefix.
> 
> 
> This is what Mapbox has set up. The Mapbox Streets Review team looks at edits 
> every day, and problems are flagged and surfaced in OSMCha. You can see all 
> of this [with this OSMCha 
> filter](https://osmcha.org/?aoi=083b147b-a72c-4026-9db5-b70761a6795c). You'll 
> see the most recent flag as about 3 days ago -- that's the typical time 
> between OSM edit and review / publishing in Mapbox Streets.
> 
> 
> Adding in Facebook flagged problems to OSMCha would provide even stronger 
> signal of problems, and hope to explore implementing it with you all.
> 
> -Mikel
> 
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
> 
> 
> 
> 
> 
> 
> On Monday, March 9, 2020, 08:10:29 PM EDT, Michal Migurski  
> wrote: 
> 
> 
> 
> 
> 
> Hi everyone,
> 
> I’m writing to let you know about a new OpenStreetMap project Facebook just 
> released. It’s called Daylight Map Distribution. Daylight is a complete, 
> downloadable preview of OpenStreetMap data we plan to start using in a number 
> of our public maps:
> 
> https://www.openstreetmap.org/user/migurski/diary/392416
> 
> Facebook uses maps to let our users find friends, businesses, groups and 
> more. OpenStreetMap (OSM) has a substantial global footprint of map data 
> built and maintained by a dedicated community of global mappers and it’s a 
> natural choice for us. Every day, OSM receives millions of contributions from 
> the community. Some of these contributions may have intentional and 
> unintentional edits that are incompatible with our needs. Our mapping teams 
> work to scrub these contributions for consistency and quality. 
> 
> What’s Included in the Daylight Map Distribution:
> 
> • A PBF planet file composed of 100% OSM data, released under the terms 
> of the Open Database License.
> • Only those edits which have been validated to contain no malicious 
> vandalism or unintentional errors so we can show them in our display maps
> 
> This is just an initial first release, and we’re looking for feedback from 
> the community to decide what would be useful to release in the future and how 
> frequently. I’d be interested to hear any response you might have about it!
> 
> -mike.
> 
> 
> michal migurski- contact info and pgp key:
> sf/cahttp://mike.teczno.com/contact.html
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 

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

Re: [OSM-talk] Announcing Daylight Map Distribution

[Michal Migurski]

Thanks for your feedback, Christoph.

The “100%” is accurate because there’s no data released in Daylight that hasn't 
previously passed through the OSM.org <http://osm.org/> database. When we 
observe errors and fix them manually, we make our edits to OpenStreetMap like 
any other editor.

I’m not sure I fully understand your second question, hopefully you can 
elaborate!

-mike.

----
michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Mar 10, 2020, at 3:44 AM, Christoph Hormann  wrote:
> 
> On Tuesday 10 March 2020, Michal Migurski wrote:
>> 
>>  • A PBF planet file composed of 100% OSM data, released under the
>> terms of the Open Database License. • Only those edits which have
>> been validated to contain no malicious vandalism or unintentional
>> errors so we can show them in our display maps
> 
> Could someone maybe do an analysis of the diff regarding numbers of 
> features removed/changed/added for various types of objects?
> 
> Regarding
> 
>>  • A PBF planet file composed of 100% OSM data
> 
> that is probably an incorrect characterization because any time you 
> modify OSM data without uploading the results to OSM what you get is no 
> more 100% OSM data.
> 
> Thinking this further - the real question is if there is other data used 
> in production of the maps using this that constitutes a derivative 
> database according to the ODbL or in other words:  Does Facebook claim 
> that this is the only derivative database they are using?
> 
> -- 
> Christoph Hormann
> http://www.imagico.de/
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] Announcing Daylight Map Distribution

[Michal Migurski]

Hi Joseph, thanks for your questions!

We are unsure yet about the public release schedule we want to commit to, 
because a lot of it depends on community feedback which we’re getting now. I 
hope we will do this again!

We do correct OSM upstream for the errors that we find. When our human review 
process catches a map error, we do two things:

1) Hold it back from release to our display maps 
2) Fix the error upstream in OSM.org

Ideally, the fix subsequently passes our process on the next round.

-mike.

> On Mar 9, 2020, at 5:47 PM, Joseph Eisenberg  
> wrote:
> 
> Interesting! That sounds like a huge amount of work, if you are
> validating every changeset in the globe, though so far there is no
> schedule to release this frequently.
> 
> Thank you for following the Open Database license by releasing this to
> the public.
> 
> Is facebook planning to create new planet files like this on a
> frequent basis, for internal use? If so, those should be released to
> the public on a regular schedule, if I understand the ODbL correctly.
> 
> Can I confirm that facebook is editing Openstreetmap data to fix the
> errors which are found? Or is this only happening in some cases?
> 
> The diary post gave links that explain how this was made (both from
> September 2019):
> - https://engineering.fb.com/ml-applications/mars/ "MaRS: How
> Facebook keeps maps current and accurate"
> 
> "We calculate the absolute diff between the two OSM versions (from
> option 1 above).
> We then split this diff into a set of LoChas that can be individually
> applied (from option 2)."
> ...
> "At a high level, a map change is vetted by a reviewer,"
> 
> - 
> https://2019.stateofthemap.us/program/sun/keepin-it-fresh-and-good-continuous-ingestion-of-osm-data-at-facebook.html
> "“Keepin’ it fresh (and good)!” - Continuous Ingestion of OSM Data at
> Facebook":
> 
> This is a video presentation, so I haven't seen it all, but the
> abstract says: "we have created an automated ingestion and integrity
> framework for OSM data that allows us to selectively update parts of
> the map instead of doing a full snapshot change all at once.
> 
> "Decomposing a large set of changes in this way gives us the
> flexibility to rapidly ingest our own additions to the map, focus on
> geographical areas of importance to downstream products, and allows us
> to quickly apply hotfixes whenever egregious problems do arise.
> 
> "With millions of tiny changes happening every week, we have created a
> system that is built on per-feature approval and preprocessing, that
> allows us to ingest changes at scale, while creating rules to
> automatically process logical changesets and enforce integrity
> constraints (e.g. anti-vandalism, anti-profanity etc.).
> 
> "Due to the contextual nature of some of the changes in OpenStreetMap,
> the system combines Human Approval, necessary for highly visible
> features such as names of large administrative areas, with Automated
> AI/ML-based approval: for example, using computer vision techniques to
> reconcile newly created features against satellite imagery ground
> truth, or applying NLP techniques to determine whether other
> user-visible string changes are sensible and valid. These components
> are combined to create a continuous ingest-validate-deploy cycle for
> OSM map data."
> 
> Lot's of buzz words there! But it sounds like it is a combination of
> computer algorithms and human checking for vandalism and errors.
> 
> - Joseph Eisenberg
> 
> On 3/10/20, Michal Migurski  wrote:
>> Hi everyone,
>> 
>> I’m writing to let you know about a new OpenStreetMap project Facebook just
>> released. It’s called Daylight Map Distribution. Daylight is a complete,
>> downloadable preview of OpenStreetMap data we plan to start using in a
>> number of our public maps:
>> 
>>  https://www.openstreetmap.org/user/migurski/diary/392416
>> 
>> Facebook uses maps to let our users find friends, businesses, groups and
>> more. OpenStreetMap (OSM) has a substantial global footprint of map data
>> built and maintained by a dedicated community of global mappers and it’s a
>> natural choice for us. Every day, OSM receives millions of contributions
>> from the community. Some of these contributions may have intentional and
>> unintentional edits that are incompatible with our needs. Our mapping teams
>> work to scrub these contributions for consistency and quality.
>> 
>> What’s Included in the Daylight Map Distribution:
>> 
>>  • A PBF planet file composed of 100% OSM data, released under the terms 
>> of
>> the Open Database License.
>>  • 

[OSM-talk] Announcing Daylight Map Distribution

[Michal Migurski]

Hi everyone,

I’m writing to let you know about a new OpenStreetMap project Facebook just 
released. It’s called Daylight Map Distribution. Daylight is a complete, 
downloadable preview of OpenStreetMap data we plan to start using in a number 
of our public maps:

https://www.openstreetmap.org/user/migurski/diary/392416

Facebook uses maps to let our users find friends, businesses, groups and more. 
OpenStreetMap (OSM) has a substantial global footprint of map data built and 
maintained by a dedicated community of global mappers and it’s a natural choice 
for us. Every day, OSM receives millions of contributions from the community. 
Some of these contributions may have intentional and unintentional edits that 
are incompatible with our needs. Our mapping teams work to scrub these 
contributions for consistency and quality. 

What’s Included in the Daylight Map Distribution:

• A PBF planet file composed of 100% OSM data, released under the terms 
of the Open Database License.
• Only those edits which have been validated to contain no malicious 
vandalism or unintentional errors so we can show them in our display maps

This is just an initial first release, and we’re looking for feedback from the 
community to decide what would be useful to release in the future and how 
frequently. I’d be interested to hear any response you might have about it!

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html


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

Re: [OSM-talk] Attribution guideline update

[Michal Migurski]

> On Feb 19, 2020, at 5:29 AM, Martin Koppenhoefer  
> wrote:
> 
> I am not sure what "device-independent pixels" means. Is this about points 
> (i.e. physical, hardware screen pixels divided by the scale)? IMHO we should 
> require actual, physical pixels, because it is them who determine whether the 
> attribution string will be readable --- and the requirement should be 
> tougher. We have seen many examples of easily readable, unobtrusive 
> attribution on much smaller maps. For example the osm.org  
> website on 467 pixels wide has room for a scale bar and this text: "© 
> OpenStreetMap contributors # Make a Donation. Website and API terms" in a 
> single line.
> 
> The actual requirement for "© OpenStreetMap contributors" is around 163 
> pixels. My suggestion would be to make this half: 250 pixels, maybe even less 
> like 200 (theoretical) pixels for retina screens (i.e. 400 actual pixels on 
> retina@2x and 600 actual pixels on retina@3x).
> Our goal is not to avoid attribution but to show it when it can reasonably be 
> done.

Device-independent pixels are a concept used in CSS in response to the 
high-resolution screens available for the past few years. Since actual, 
physical pixels are now very small, a new definition expresses them in terms of 
visual angle so that pixel-defined CSS layouts from the past few decades aren’t 
suddenly illegible: “By definition, this is the physical size of a single pixel 
at a pixel density of 96 DPI, located an arm's length away from the viewer's 
eyes.”

https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel

For our purposes, this is a better definition because it’s defined in terms of 
what a viewer can see rather than its implementation in hardware.

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

Re: [Diversity-talk] [Osmf-talk] First Meeting of Diversity and Inclusion Special Committee

[Michal Migurski]

Thanks for leading these two meetings, Mikel. I appreciate that you’re taking 
this on even as you clearly communicate that you’d like for some outside the 
board to lead!

I participated in the first time slot. A few observations:

1) It was 100% a white/tech participation list, and I’d like to think about 
ways to change this in future meetings. I hear that the group was a little 
broader for the second time, which is great!

2) Michael predicted a lengthy time for research and fact-gathering. One year 
is enormous! The fact-finding needs here are not publication-grade and we can 
get by with small initial metrics if we commit to tracking them over time. For 
example: we’ve already improved meeting participation diversity in just *four* 
hours. Go us.

3) Rory brought up the excellent point that some things in our community go 
undebated and brought up the example of self-evident support for open source 
technology. Placing a heavy burden of proof on diversity research sends the 
message that we’re not going to believe a problem exists until it’s spelled out 
in black-and-white, and nobody has patience for that. I was impressed by Ivan 
Gayton’s contribution to Heather Leson’s Diary post on this subject: “if you 
want to discover whether women (or people of color, or LGTBQ people, or people 
from low-income countries, or other folks less represented in global wealth and 
power) are experiencing hostility, a good way to do so is to ask them. As 
opposed to asking them to prove it.” 
https://www.openstreetmap.org/user/Heather%20Leson/diary/391598#comment46229 
<https://www.openstreetmap.org/user/Heather%20Leson/diary/391598#comment46229>

4) Some aspects of the diversity discussion foreground northern/western 
participation channels by (for example) wondering why other communities aren't 
participating in Talk@, SOTM, or other locations. I’m interested in trying to 
flip this question to ask why core board and community participants aren't 
showing up in forums like geographic Telegram groups or other locations called 
out at https://openstreetmap.community <https://openstreetmap.community/> ? In 
a recent post, Allan commented that he was often greeted with surprise by local 
communities who had no experience of an OSMF board member reaching out and 
saying hello.

-mike.

----
michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Feb 12, 2020, at 10:12 AM, Mikel Maron  wrote:
> 
> We just concluded second of two meetings today. Lots to digest, thanks to 
> those who were able to make it. Raw notes are at 
> https://hackmd.io/3cy5P9fhSvSVI8gkIHIX6w?view 
> <https://hackmd.io/3cy5P9fhSvSVI8gkIHIX6w?view>. My next action is to digest 
> a bit, and create a page on the OSMF wiki with some things that came out of 
> the meeting.
> 
> Other next steps. Maggie is going to start a OSM wiki page to gather previous 
> research, Rory is looking at tweaks to the Diversity Statement, and Jinal is 
> putting together a short form to gather details on interest from people who 
> didn't make this meeting.
> 
> -Mikel
> 
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
> 
> 
> On Thursday, February 6, 2020, 01:41:45 PM EST, Mikel Maron 
>  wrote:
> 
> 
> Last month, the OSMF adopted this Diversity Statement [1] and appointed a 
> committee [2] to compile research and undertake new research on our 
> diversity, identify root causes that contribute to any shortfalls, and make 
> recommendations to help resolve issues and improve. 
> 
> If you're interested to take part, join an upcoming initial meeting of the 
> committee. We're holding a first meeting on Wednesday February 12 at 1400 UTC 
> [3] on Mumble [4] (in the public OSMF Board of Directors room). Please join 
> if you'd like to contribute. If you're unavailable at that time, let us know 
> other times that might work, and we can schedule another kickoff meeting in 
> addition.
> 
> [1] https://wiki.osmfoundation.org/wiki/Diversity_Statement
> [2] https://hackmd.io/ZG8x44H4Skq0CPkcrMTB6A?view
> [3] Timezone converter: 
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=DISC+Meeting=20200212T14=1440
> [4] How to use Mumble: https://wiki.openstreetmap.org/wiki/Mumble
> 
> -Mikel
> 
> 
> ___
> osmf-talk mailing list
> osmf-t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk] OSMF candidate office hours, ask me anything

[Michal Migurski]

Hey Mateusz, thanks for this question and sorry that none of the times I 
offered fit your schedule!

I’ll start by suggesting that one of your assumptions is not accurate. Weak 
license enforcement is bad for large organizations like my employer, Facebook. 
We prefer clear rules and the legal team here is pleased to see that the LWG is 
moving forward with more explicit, assertive communication about the license 
and its requirements. It will allow us to act with confidence and clarity. I 
won't say more about this because people are actively working on the new 
attribution proposal.

To answer your direct question, I’ll handle a conflict of interest the same way 
as any other board member. UK law requires that I seek authorization from the 
other directors to participate in situations where I have a conflict, and 
recuse myself if not. Rory McCann is in a similar situation and points out in 
his message that explicit rules such as those governing conflicts make it 
easier for everyone to comply. 
(https://lists.openstreetmap.org/pipermail/osmf-talk/2019-December/006449.html)

I’ll also reference Mikel’s observation that the interests of OSMF (and 
therefore their possible conflicts with any individual board member's interest) 
are very much a question that this current election is seeking to answer. 
Starting tomorrow and over the next week, the voting membership of the OSMF 
will determine what the foundation’s interests *are*. Speaking for myself, I am 
running to promote a high quality free map with equal coverage around the 
world, the heart of my interest in OpenStreetMap since 2006.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Dec 6, 2019, at 2:56 AM, Mateusz Konieczny  wrote:
> 
> 
> 
> 
> 3 Dec 2019, 20:05 by m...@teczno.com:
> Hi everyone,
> 
> I’m one of the twelve candidates running for OSMF board. 
> It seems that none of video calls times matches my time, so hopefully it is 
> OK to ask here.
> 
> How you plan to handle an obvious conflict of interest due to your FB 
> employment?
> 
> For example in topic of enforcing ODBL licence? It is interest of FB to keep 
> all enforcement of
> OSM license extremely weak, so even recusing yourself from all FB-related 
> issues would not
> be sufficient.
> 
> Note that ODBL licence requires notice reasonably calculated to make any 
> Person that uses,
> views, or is otherwise exposed to the Produced Work aware that Content was 
> obtained from
> the Database and that it is available under this License.
> 
> IANAL, but it seems to me that current attribution hiding used by FB is not 
> enough to fulfill this
> requirement and that they are currently using OSM data illegally.
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

[OSM-talk] OSMF candidate office hours, ask me anything

[Michal Migurski]

Hi everyone,

I’m one of the twelve candidates running for OSMF board. When I was an OSM US 
board member in 2012, I had good luck starting a weekly “office hours” session 
for people to chat about OpenStreetMap (it ended up turning into Geobreakfast 
and still happens in SF and NYC 7 years later; find us on Twitter).

If you’ve read my candidacy manifesto, you might have noted that I’m running 
with the explicit encouragement and permission of my employer, Facebook: 

https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board/Answers_and_manifestos#Michal_Migurski

A candidate working in a company like FB and not specifically trying to 
disconnect OSM involvement from their day job is a potentially weird new thing 
in the community, so I thought it worth making myself available for questions, 
conversations, or whatever via conference call. I‘ve set up five hour-long 
blocks on my calendar accessible to a variety of time zones between now and 
when voting closes, and I’ll be hanging out ready to chat if you have anything 
you’d like to ask or share. Looking forward to chatting!

Times:

Hour 1, December 4 9:30am PST
Video call: https://bluejeans.com/791594022
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+1=20191204T0930=388=1

Hour 2, December 4 10pm PST
Video call: https://bluejeans.com/537172017
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+2=20191205T2200=388=1

Hour 3, December 6 9am PST
Video call: https://bluejeans.com/656483413
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+3=20191206T0900=388=1

Hour 4, December 8 4pm PST
Video call: https://bluejeans.com/565915593
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+4=20191208T1600=388=1

Hour 5, December 10 9am PST
Video call: https://bluejeans.com/925750882
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+5=20191210T0900=388=1

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html


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

Re: [OSM-talk] Sharing, Facebook, mapwithai_feedback

[Michal Migurski]

Hi,

I appreciate the invitation, but this is a complicated list for employees of a 
large company to have a discussion!

Instead, try posting on the diary post where Drishtie announced the project and 
FB staff are actively responding: 
https://www.openstreetmap.org/user/DrishT/diary/368711

The project is also on Github with open issues, if you’ve got something to 
report: https://github.com/facebookincubator/RapiD/issues

-mike.

> On Aug 2, 2019, at 2:47 PM, stevea  wrote:
> 
> Re-threading from the rather messy previous one.
> 
> Mike:  Thank you for telling us of the #mapwithai_feedback Slack channel, 
> truly.  It is true that some of us choose not to use Slack.
> 
> I ask Facebook to meet the OSM community about these issues "on our turf" by 
> participating here.  That would speak volumes, Facebook.  This is a quite an 
> "open" channel, talk.  Archives remain open for years (forever?) and we speak 
> candidly, earnestly and honestly here.  If you weren't watching this thread / 
> dialog before, you are now, Facebook.  Please consider yourself invited here. 
>  Matters do seem pressing with an urgency, although I understand that 
> crafting a thoughtful reply can take some time.
> 
> That seems fair, yes, Valor?  A neutral, even polite invitation to here?  
> We'll see.
> 
> There are hundreds, maybe thousands who participate here.  "Facebook" 
> (whomever that might be in the guise of an OSM volunteer who subscribes here) 
> could politely answer this phone call, even quite well.
> 
> SteveA
> 


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] Isn't it nice to share?  | Re: Facebook mapping highways using AI in collaborati =?utf-8?q?on_with_OpenStreetMap

[Michal Migurski]

Hi,

The OSM US Slack has a dedicated channel called #mapwithai_feedback where 
members of the FB team are generally available to answer questions: 
https://app.slack.com/client/T029HV94T/CK3BZ8FC0 
<https://app.slack.com/client/T029HV94T/CK3BZ8FC0>

-mike.

----
michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Aug 2, 2019, at 1:54 AM, Valor Naram  wrote:
> 
> The time is now to get into dialogues with Facebook's RaID team instead of 
> discussing further what Facebook did/does wrong, how they can improve their 
> AI, how they can improve their communication with the community and what 
> their intentions are.
> 
> Discussing with Facebook's RaID team is better and more helpful for both 
> sites instead of discussing about Facebook's practise without Facebook's 
> involvement.
> 
> We should be fair!
> 
> Cheers
> 
> Sören Reinecke alias Valor Naram
> 
> 
>  Original Message 
> Subject: Re: [OSM-talk] Isn't it nice to share?  |   Re: Facebook mapping 
> highways using AI in collaborati   =?utf-8?q?on_with_OpenStreetMap
> From: Joseph Eisenberg 
> To: Marc Gemis 
> CC: Rory McCann ,OSM Talk 
> 
> 
> Facebook probably shouldn't import all of their POIs directly into
> OSM. I understand that this could cause problems.
> 
> But they could make available all sorts of useful data, including a
> separate overlay or service that allowed us to see where facebook POIs
> are located, and manually import them into OSM if they are correct.
> 
> I believe that also record your GPS coordinates while using the app in
> many cases, such as when taking photos. They could make these GPS
> traces available, like Strava does - quite helpful for finding missing
> path connections, and also helps show when a street a closed.
> 
> They could allow their users to choose to automatically upload photos
> of businesses and street scenes under a suitable license to a
> Mapillary-like site that could be used for mapping.
> 
> They could share data that suggest that POIs no longer exist; such as
> a facebook user clicking a note that says "this place is permanently
> closed" or "doesn't exist" and we could use that like a note or fixme.
> I believe these sort of prompts are already automatically suggested
> when the app sees you are at a POI, as are things questions about
> additional features (free parking? free wifi, etc?) which could be
> useful information for us.
> 
> None of these options for share-alike would be clearly good for
> short-term shareholder value, but they would be quite helpful for
> mappers in OSM, and wouldn't require a massive import.
> 
> Joseph
> 
> On 8/2/19, Marc Gemis wrote:
> > This "self appointed police of OSM" will probably question
> >
> > - how did those companies receive the data, under which copyright?
> > - how did they geocode the POIs, using Google's geocoder ? (a big no-no)
> > - how up-to-date is this data ? Will you reimport POIs that have been
> > rightfully removed in OSM ?
> > - how will you avoid duplicates ?
> >
> > all legitimate question imho.
> >
> > p.s. people that keep blaming the mailing lists for bad behaviour,
> > really make me wonder why I keep contributing to OSM (mailing list).
> > Did you ever wonder that this type of constant nagging might turn off
> > well-meaning people as much as the people you point at turn off you?
> >
> > On Fri, Aug 2, 2019 at 9:00 AM Blake Girardot wrote:
> >>
> >>
> >>
> >> On Fri, Aug 2, 2019 at 8:00 AM Rory McCann wrote:
> >>>
> >>>
> >>> Oh yes, there's nothing wrong with Facebook (and Yelp, and TripAdvisor
> >>> and and) having their own PoI database. But, they _could_ help us,
> >>> massively, by sharing it. They way they talk about OSM, you'd swear they
> >>> were already doing all they could to help us.
> >>>
> >>> But it's naive to think they ever will. Nothing wrong with that,
> >>> shareholder value and all that.
> >>>
> >>
> >> Hi Rory,
> >>
> >> Respectfully, it is naive to think that even if they did offer their POI
> >> databases, the self appointed police of OSM would allow the POIs to be
> >> added to OSM.
> >>
> >> Truthfully, it is naive to think that any mapping or data that is not
> >> contributed just the way the few vocal folks who monopolize these OSM
> >> lists like, will be accepted.
> >>
> >> There really is no way to win wi

Re: [OSM-talk] presenting the case for open data to local government?

[Michal Migurski]

On Oct 15, 2013, at 10:20 AM, Michal Migurski wrote:

 I want to put together a succinct and well-documented argument that I can 
 send along to a city council member/ mayor/ city manager/ etc.
 
 Anything you're willing to pass along (comments, suggestions, something 
 you've written up, research, etc) would be much appreciated.
 
 The cities we work with at Code for America are already pretty much on-board 
 with open data, but the GIS departments and data owners often have 
 reservations. They worry about how the inevitable mistakes in the data will 
 be perceived, about liability, and about a wider community of data users 
 complaining to them.
 
 ...


Just to follow up on this, last night we got some newsworthy closure on open 
data policy in Oakland:


http://oaklandlocal.com/2013/10/oakland-city-council-approves-open-data-policy-community-voices/

Tonight, the Oakland City Council unanimously approved Councilmember Libby 
Schaaf’s Open Data Policy, requiring Oakland’s public data to be proactively 
made available in useable formats, which will empower the citizens of Oakland 
to better access information and work to improve government.

The pass by consent with no discussion or concern is part of a longer story. 
Last year, Oakland city council voted on a similar resolution, and ended up 
eviscerating it. All resolutions were replaced with a decision to kick the can 
down the road by studying costs (that's bad).

http://teczno.com/s/18l

What happened in the intervening year? The cost estimate for putting up a 
Socrata-run open data site came back low enough that no further city council 
approval was required. People inside city hall continued to push for open data. 
Developers and activists outside city hall (http://openoakland.org) met 
regularly and demonstrated the value and applications of open data. This 
success was not the result of any particularly documented argument, but the 
sustained push of a community group.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] presenting the case for open data to local government?

[Michal Migurski]

On Oct 10, 2013, at 6:27 PM, Daniel Joseph wrote:

 Hi everyone,
 
 I was wondering if anyone had experience conveying to local government all 
 the reasons for opening up data. The city where I grew up has a clunky GIS 
 web portal with which you can only view data. A neighboring city will 
 provide data but their data release form includes the following: The data is 
 provided solely for the use of the requesting party and may not be made 
 available to anyone else.
 
 I want to put together a succinct and well-documented argument that I can 
 send along to a city council member/ mayor/ city manager/ etc.
 
 Anything you're willing to pass along (comments, suggestions, something 
 you've written up, research, etc) would be much appreciated.

The cities we work with at Code for America are already pretty much on-board 
with open data, but the GIS departments and data owners often have 
reservations. They worry about how the inevitable mistakes in the data will be 
perceived, about liability, and about a wider community of data users 
complaining to them.

Do you have the bandwidth to hold hands a bit, and offer a chance for cities to 
accept data changes from the broader community? Many of the OSM-based change 
detection projects like OWL and Changewithin might help with this. I've been 
working on an update to Changewithin designed to address cities beyond New 
York, for example:
https://github.com/migurski/changewithin

Some chit-chat on the subject here:
https://github.com/osmlab/changewithin/pull/14

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] Burning Man old data, publicity opportunity

[Michal Migurski]

Black Rock City moves slightly each year, to minimize impact on any particular 
spot in the playa. The streets are also given new names, and the city expands 
to accommodate additional population growth. It's effectively a totally new 
geography each time.

Mikel has been involved in the project in the past, and been given advance 
private access to survey shapefiles.

-mike.

On Aug 5, 2013, at 11:36 AM, Kathleen Danielson wrote:

 I only know a little about Burning Man (seriously, just what I read in Cory 
 Doctorow's Homeland), but mapping BRC makes sense to me. 
 
 Is it on the exact same location every year? In that case it seems like it 
 would make sense to update the map annually. If they are on different parts 
 of the dessert each year, it would probably make sense to map each one, but 
 once the city is torn down, modify the tags to indicate a past structure. The 
 Historical OSM folks would probably have better guidance on the best way to 
 do this.
 
 Either way, it seems like this could be a really neat way to preserve Black 
 Rock City. 
 
 Are any OSM folks going to be at Burning Man this year?
 
 
 On Mon, Aug 5, 2013 at 2:25 PM, Clay Smalley claysmal...@gmail.com wrote:
 So Black Rock City is mapped on OpenStreetMap... twice. And both are old 
 versions (the city as it was in 2008 and 2009). Anyone know why this is? 
 Should the two old cities be deleted and replaced with the 2013 city?
 
 I have a feeling that this could be a fun publicity opportunity for OSM, if 
 we're the first ones to map out Black Rock City during Burning Man. Not to 
 mention that the kind of people who go to Burning Man would probably rather 
 support OSM over Google Maps, given someone tells them about OSM. It brings 
 in people from everywhere, so ideally they could go back to their respective 
 communities and possibly get more involved in local OSM mapping.
 
 Just ranting a pipe dream. Does this sound realistic?
 
 ___
 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


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] Burning Man old data, publicity opportunity

[Michal Migurski]

I'd love to help with this, but I'm not much of a burner (first  last: 2001) 
so I won't be able to follow up. Sorry!

-mike.

On Aug 5, 2013, at 11:54 AM, Jeffrey Johnson wrote:

 He was certainly involved back then, but like me, his interest in
 BM/BRC has dropped off a bit. I've connected Migurski with the people
 in the Bay Area that have all the data and hoping he can help get
 everything together so it can go into the map.
 
 Jeff
 
 On Mon, Aug 5, 2013 at 11:49 AM, Steven Johnson sejohns...@gmail.com wrote:
 I'm almost certain that Mikel was involved in one, or both of those '08/'09
 efforts to map Black Rock City. Worth contacting him about what it would
 take to re-do it for 2013.
 
 -- SEJ
 -- twitter: @geomantic
 -- skype: sejohnson8
 
 There are two types of people in the world. Those that can extrapolate from
 incomplete data.
 
 
 
 On Mon, Aug 5, 2013 at 2:25 PM, Clay Smalley claysmal...@gmail.com
 wrote:
 So Black Rock City is mapped on OpenStreetMap... twice. And both are old
 versions (the city as it was in 2008 and 2009). Anyone know why this is?
 Should the two old cities be deleted and replaced with the 2013 city?
 
 I have a feeling that this could be a fun publicity opportunity for OSM,
 if we're the first ones to map out Black Rock City during Burning Man. Not
 to mention that the kind of people who go to Burning Man would probably
 rather support OSM over Google Maps, given someone tells them about OSM. It
 brings in people from everywhere, so ideally they could go back to their
 respective communities and possibly get more involved in local OSM mapping.
 
 Just ranting a pipe dream. Does this sound realistic?
 
 ___
 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
 
 
 michal migurski- contact info and pgp key:
 sf/cahttp://mike.teczno.com/contact.html
 
 
 
 
 
 ___
 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
 


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] Gamification and OSM (Was: Upgraded map controls)

[Michal Migurski]

 about tagging a power station in some region,
 you could quickly find the power man of the region, and ask them. That way
 the badge comes with some responsibility and influence in decision making.
 The bigger the region, the more responsibility.
 
 
 Games can be... gamed.
 As a pipsqeak in the power pole mapping influence peddling ring, I could
 zoom to the top with a few evenings of shifting nodes that did not really
 need shifting.  If the game is important enough to be gamed... it will be
 gamed.
 
 Better to say that my edits are respected.  I make an edit and someone else
 says 'thanks, that looks great', or maybe 'could we talk about the inclusion
 of bird nests on power poles a bit?'.  Then you've got a system that has
 both games and social features.  For those who don't want either there can
 be achievement levels: perhaps certain capabilities, like bulk uploads,
 could require hitting certain contribution milestones.  It works great for
 stack exchange and other similar sites.
 
  -Bryce
 
 Note: the badge list above shows a gender-specific skew... trying giving the
 'power man' badge to a professional female lawyer.
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] comments on new map widget on main page

[Michal Migurski]

On Jul 29, 2013, at 12:13 AM, Richard Fairhurst wrote:

 Michal Migurski wrote:
 Provable evidence that the view tab is not sufficiently 
 informing visitors of its functionality? Having a button 
 that says “link” is a great clue that there is an option 
 to link vs. hunting around. 
 
 Perhaps, but this is definitely a pro feature. There _is_ a button that says
 link (or rather, an icon that indicates link).

How do we know that? Since we perform no systematic user testing in advance of 
these changes (http://teczno.com/s/92x), we're not really sure what a pro user 
is. I bet Google does user testing, though, and they've chosen a little 
chain-link icon for theirs and put it in a prominent place. An image search for 
link icon unscientifically supports their choice:

http://www.google.com/search?q=link+icontbm=isch

Ours is the mystery iOS swoosh-box which on my phone browser means share 
this page to another service (don't get me started on Flickr's adoption of 
this icon). Sharing is not totally unrelated, but the image is borrowed from a 
pocket device where my parasympathetic nervous system does most of the 
remembering.


 What a small number of
 existing OSM pro users are asking for is, additionally, a way of retaining
 the single-click behaviour rather than having to open the panel, and the
 View tab does that. Surfacing everything that pro users might want isn't a
 good way of building a design that appeals to potential newcomers.

This question came up once during the SF editathon as well, among a group of 
mixed Pro and not-Pro users, and when I explained that the view tab allows for 
linking to the view, the consensus I heard was that a tab is a weird place to 
put it (I've already chosen that tab, why would I click it again?).

I do want to underscore the point that we lack any systematic way of 
understanding who our users actually are, or a stated strategy for deciding who 
we want them to be. In my design experience, pro is often used as a 
short-hand for I don't know where to put that thing, let's call it a pro 
feature so we can hide it someplace so I'm pushing a little to make sure we 
know why we're using the word here.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] comments on new map widget on main page

[Michal Migurski]

On Jul 29, 2013, at 2:57 PM, Lester Caine wrote:

 John Firebaugh wrote:
 On Sun, Jul 28, 2013 at 4:26 PM, Greg Troxel g...@ir.bbn.com
 mailto:g...@ir.bbn.com wrote:
 
I'd like to see two things different; both of these are regressions from
the old way and I think easy to address
 
 I believe that persisting the location and zoom in the URL hash will address
 both of these concerns.
 
 Please try it out: http://hash.apis.dev.openstreetmap.org/
 
 That works reasonably well for me  I'm used to seeing that sort of info 
 from the hover over links on the bottom of the browser, so having it stable 
 is probably an improvement.


+1.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] comments on new map widget on main page

[Michal Migurski]

On Jul 28, 2013, at 4:47 PM, Richard Fairhurst rich...@systemed.net wrote:

 Greg Troxel wrote:
 add the shortlink link in the lower right, so you can more easily use
 it to get to a URL for the current view, so you can shift-reload to
 see what yfou just edited
 
 Click the View tab.
 
 /stuck_record

Provable evidence that the view tab is not sufficiently informing visitors of 
its functionality? Having a button that says “link” is a great clue that there 
is an option to link vs. hunting around. 

-mike. 



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Interesting website stuff in the works

[Michal Migurski]

I appreciate that these pulls and discussions are being surfaced to the talk 
list, thank you. 

-mike.

---
michal migurski http://mike.teczno.com

On Jul 25, 2013, at 10:48 PM, Paul Norman penor...@mac.com wrote:

 I'm trying something different in the hopes of getting more awareness about
 potential website changes with significant feature or UI impacts. The
 suggested place for comments is on the github issues or pull requests
 
 Reorganize export/share UI - the next set of changes to the share UI.
 Github page for change at
 https://github.com/openstreetmap/openstreetmap-website/pull/351
 Test deployment at http://mapui.apis.dev.openstreetmap.org/
 
 Add welcome page - Providing a better introductory page, filling a gap in
 existing materials. 
 Github page for change at
 https://github.com/openstreetmap/openstreetmap-website/pull/338
 
 Rationalize multiple locate me type functions - Discussion about confusion
 and duplication between Where am I?, home and the new geolocation button.
 Github page for change at
 https://github.com/openstreetmap/openstreetmap-website/issues/373

 Use a hash anchor for location/zoom persistence - using #zoom/lon/lat
 instead of ?lon=Alat=Bzoom=C
 Github page for change at
 https://github.com/openstreetmap/openstreetmap-website/pull/378
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Upgraded map controls

[Michal Migurski]

On Jul 22, 2013, at 7:21 AM, Simon Poole wrote:

 Am 21.07.2013 20:18, schrieb Michal Migurski:
 Supporting official venues for orderly change is what the board should
 be doing, but is not. I would support the creation and use of a
 proposal/vote/implementation process for the community, even if the
 first proposal is just be it resolved that Mapbox accepts
 responsibility for the visual design of OSM.org. 
 
 I would find it very very difficult to subject superficial design
 changes to a popular vote, these are matters of personal taste and work
 flow and it is very unlikely that we could reach any kind of consensus
 within a reasonable time frame, wit this thread. What would be nice if
 we could get to a state where changing the visual appearance of the main
 site would not be such a heavy weight task (at least not for the devs)
 and could happen substantially more often than once in a decade.

It's a heavyweight task because there's no higher-level process to guide it, 
other than the one brought by volunteers. No strategy or goals from the 
foundation that would provide some rationale for a change and no decisions that 
would delegate someone to follow through on those goals. Bikeshedding is rarely 
a failure on the part of the bike shedders, more often a failure of strategy 
and leadership. The workings of our front page are most definitely not a matter 
of personal taste!


 Now high level goals and to a certain point functionality is something
 that, IMHO, is worth discussing with a large group, and we have ongoing
 discussions that cover exactly such territory. Besides what has been
 written here, there is a larger one on the German list about the
 potential gamification of OSM which shows that such a step is not simply
 a design question and definitely needs more community consensus if it
 should be seriously considered for implementation.


No kidding! Any consensus from the Germans?

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Upgraded map controls

[Michal Migurski]

On Jul 21, 2013, at 5:42 AM, Pieren wrote:

 On Sun, Jul 21, 2013 at 12:55 AM, Dave F. dave...@madasafish.com wrote:
 On 20/07/2013 12:57, Paul Norman wrote:
 
 Rails port pull requests?!?! wtf.
 :
 I really think some developers are living in their own world.
 
 lol. They do !
 If you missed the discussion because you don't watch the non-localized
 35 mailing lists, 5 irc channels, 13 forums, 8 foundation working
 groups reports, all pull requests discussions in github/osm and the
 videos of the last SOTM, it's really your fault :-)


Supporting official venues for orderly change is what the board should be 
doing, but is not. I would support the creation and use of a 
proposal/vote/implementation process for the community, even if the first 
proposal is just be it resolved that Mapbox accepts responsibility for the 
visual design of OSM.org.

The new icons and map controls are good and I'm getting accustomed to them, but 
the process by which they made it onto the site worries me. Mostly, it's 
because Saman opened his SotM-US talk with a blow it all up slide and 
finished with gamification that I'm uneasy with how we're treating the visual 
presentation of OSM.org. Gamification is a sad, sorry sideshow and we shouldn't 
do it; it only became a meme because Zynga made a zillion dollars and look how 
that turned out. Do we plan to follow through on gamifying the OSM UI as Saman 
suggested in his talk? I don't know, and I don't want to have to subscribe to 
Github pull requests to find out.

Let's not lose sight of the fact that OSM.org has mapped the world in a decade.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Upgraded map controls

[Michal Migurski]

On Jul 21, 2013, at 11:47 AM, Richard Fairhurst wrote:

 Michal Migurski wrote:
 On Jul 21, 2013, at 5:42 AM, Pieren wrote:
 If you missed the discussion because you don't watch the 
 non-localized 35 mailing lists
 [...]
 I don't know, and I don't want to have to subscribe to Github 
 pull requests to find out.
 
 You only have to follow one mailing list: rails-dev@. Just as if you're
 interested in the development of JOSM you should follow josm-dev@, if you're
 interested in the development of Potlatch you should follow potlatch-dev@,
 if you're interested in the development of Merkaartor, OSRM, Nominatim, etc.
 etc.
 
 All site issues on github and site issues on trac are gatewayed to
 rails-dev, so you won't miss anything.
 
 (rails-dev is a daft, uninituitive name and really it should be called
 site-dev, but history.)

Thank you Richard, I am subscribed. I had not realized that the scope of 
rails-dev was larger than the technical development and maintenance of the 
Rails port. For me, this explains past flame-outs of the design@ list.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Upgraded map controls

[Michal Migurski]

On Jul 21, 2013, at 12:28 PM, Kai Krueger wrote:

 It begs the question, if this high level design decisions shouldn't live on
 the design@ list instead of rails-dev or in the git-hub bug tracker.
 
 rails-dev can sometimes have a reasonably high volume and most of it is
 boring technical detail, like e.g. if oauth needs relative or absolute URLs
 to produce valid signatures. This is something most people don't (and
 probably shouldn't) care about and won't read rails-dev. So putting high
 level design discussions that does effect everyone who uses osm.org and
 where because it is subjective, everyone can have a valid opinion on it, is
 perhaps a bad idea. After all there is a specific list just for this kind of
 purpose i.e. design@
 
 Of cause fragmenting mailing-lists further and further is probably a bad
 idea though as well.

I do like Richard's thought that rails-dev should be site-dev, if a 
renaming was accompanied with the merging of the design@ list. We'd come out 
with a less-fragmented and clearer selection of mailing lists!

It makes sense to me that the people making design suggestions and those who 
implement them participate in the same conversation space, even if the 
designers need to occasionally skip an OAuth thread or the developers get bored 
of hearing about hex colors and corner radii.

The key though is delegation and recordkeeping. If we should decide that Saman 
+ Mapbox own the visual design of the site for a period of time, we need to be 
clear that that includes credit, accountability, and a paper trail of 
deliberations that we can point to when someone asks if we really need plus and 
minus buttons on the map.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] tile.openstreetmap.us down tomorrow

[Michal Migurski]

I need to bring the configurations for the vector datasets up to date, now that 
the Postgres tables are all back.

http://openstreetmap.us/~migurski/vector-datasource/

-mike.

On Jul 20, 2013, at 4:28 PM, Ian Dees wrote:

 Hi all,
 
 After some confusion about getting our new memory working, we should be back 
 to normal now.
 
 Most of the tile.openstreetmap.us layers are working again (including the 
 USGS Large Scale and TIGER 2012 Roads layer).
 
 Let me know if you see otherwise.
 -Ian
 
 
 On Wed, Jul 17, 2013 at 3:43 PM, Ian Dees ian.d...@gmail.com wrote:
 Yep, there was a hiccup when the data center folks restored the 500GB 
 Postgres partition onto the 20GB root partition, so it's happening again.
 
 We should get it back up this evening.
 
 
 On Wed, Jul 17, 2013 at 3:35 PM, Ben Miller bborkmil...@gmail.com wrote:
 Is the hardware upgrade still in progress? I'm not seeing the TIGER or USGS 
 topo layers currently.
 
 Thanks for the upgrades, BTW, whatever they may be!
 
 
 On Mon, Jul 15, 2013 at 10:07 AM, Ian Dees ian.d...@gmail.com wrote:
 This downtime didn't happen last week. I expect that it will happen today and 
 hopefully be back up by some time tomorrow.
 
 
 On Thu, Jul 11, 2013 at 7:47 PM, Ian Dees ian.d...@gmail.com wrote:
 Hi folks,
 
 We're installing some hardware upgrades in the server running 
 tile.openstreetmap.us, so some of the tile layers in the editors will be 
 unavailable for the day.
 
 The layers that might not work:
 - TIGER 2012 Road Names
 - USGS Topo Maps
 - USGS Large Scale Aerials
 - some other layers that are used less frequently
 
 Please let me know if you have any questions,
 Ian
 
 
 ___
 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


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] Steady increase in the number of mappers in the US

[Michal Migurski]

On Jul 19, 2013, at 9:36 AM, Clifford Snow wrote:

 On Fri, Jul 19, 2013 at 9:03 AM, Alex Barth a...@mapbox.com wrote:
 The local dimension of OpenStreetMap was exactly why OSM US decided to do 
 #editathons. There's one happening this weekend, join us.
 
 http://openstreetmap.us/2013/07/july-summer-editathon/
 
 Our group is signed up.  (Seattle) 
 
 Well I've been promoting this event quite enough on this list so I'm sure 
 everyone of you already has this on the radar :) But share it in your 
 networks if you haven't yet. It's not too late.

We had excellent turnout yesterday in San Francisco with almost 20 people in 
Code for America's Ben Franklin room. We got a lot of newcomers who had 
attended the June SOTM and were interested in contributing, a near 50/50 gender 
balance (!!!), and a handful of traditional GIS  education people who were 
looking for connections to the OSM world. Attendees worked on a bunch of 
projects: cycling route relations in Kansas City, building import process for 
SF, highly-detailed parking lot models for San Ramon, addresses and business in 
San Jose, and automated detection of unmapped suburbs from Telenav probe data 
(not public).

Photo:
https://twitter.com/michalmigurski/status/358695759769632768/photo/1

Partial attendee list:
http://www.openstreetmap.org/user/Alan
http://www.openstreetmap.org/user/Allison%20Carpio
http://www.openstreetmap.org/user/bdiscoe
http://www.openstreetmap.org/user/chachasikes
http://www.openstreetmap.org/user/curiousscholar
http://www.openstreetmap.org/user/dirtysouth
http://www.openstreetmap.org/user/EmilyWask
http://www.openstreetmap.org/user/jfire
http://www.openstreetmap.org/user/matthieun
http://www.openstreetmap.org/user/mdrigo
http://www.openstreetmap.org/user/migurski
http://www.openstreetmap.org/user/MonoSim
http://www.openstreetmap.org/user/Ondrae
http://www.openstreetmap.org/user/rduecyg
http://www.openstreetmap.org/user/robertstack
http://www.openstreetmap.org/user/Thomas%20Hervey

Also, here is a JSON API to see the last 25 edits for the #editathon hashtag:
http://osm-tags.teczno.com/tag/editathon?callback=do_stuff

…and all the #editathon changesets as of two minutes ago:
http://mike.teczno.com/img/editathon-2013-07-21-17-43-00Z.csv

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] iD Editor live on OpenStreetMap

[Michal Migurski]

On May 7, 2013, at 10:16 AM, Grant Slater wrote:

 You forgot the most important blog ;-)
 
 http://blog.openstreetmap.org/2013/05/07/openstreetmap-launches-all-new-easy-map-editor-and-announces-funding-appeal/
 
 / Grant


Ha!

Congratulations, guys. It's a fantastic piece of work.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] RFC updated: OSM Attribution Mark (was: contributor mark)

[Michal Migurski]

What about “with OSM” instead of “by OSM”?

-mike.

---
michal migurski http://mike.teczno.com

On Apr 22, 2013, at 7:39 AM, Simon Poole si...@poole.ch wrote:

 
 The copyright page is now much better than before and IMHO contains the 
 necessary contents. There are a couple of wording issues that are already 
 present in the current version that we should address while we're at it (but 
 that is mainly CWG/OWG turf) but nothing major.
 
 I do have a couple of issues with the icon though. First while I'm sure we 
 would like to take credit for everything OSMish, doesn't by OSM imply the 
 wrong thing? What we want to say is I suspect Data by OSM, that naturally 
 would be rather unwiedly. Further there may be a potential (legal) issue with 
 using OSM in that way that I need to discuss with counsel.
 
 But all in all a nice step forward.
 
 Simon
 
 
 Am 22.04.2013 14:40, schrieb Alex Barth:
 Hello everyone -
 
 I'd love to start pushing again on the OSM attribution mark.
 
 This is an updated proposal based on an initial RFC from earlier this year 
 titled Contributor Mark [1, 2]. Sorry for the delay in following up with 
 adjustments based on feedback   on the original thread. 
 
 Again, the goal of this proposal is to draw more attention to OpenStreetMap 
 wherever it's used by introducing a visually compelling, linked symbol for 
 placement on OSM-based works and by explaining OpenStreetMap better at the 
 place where this symbol links to.
 
 Looking forward to your feedback. I'll also be reaching out to corresponding 
 working groups and OSMF to see how we can move this forward.
 
 Concretely, this RFC proposes
 
 1. Replace current credit © OpenStreetMap Contributors with a visual mark 
 where possible
 2. Update `openstreetmap.org/copyright` to explain better OSM, to invite 
 visitors to join and to allow creators of derivative work to link back to 
 their sites.
 
 The update to the original RFC brings 4 key changes:  
 
 1. Rename the proposal from 'Contributor Mark' to 'Attribution Mark'
 2. A completely redesigned mark, containing the letters OSM
 3. A completely redesigned `/copyright` page, the page the mark links to. It 
 is much closer to today's `/copyright`
 4. The mark is an alternative to © OpenStreetMap Contributors. Only where 
 the mark can't be used, © OpenStreetMap Contributors may be used.
 
 Please read up on all details on the newly created RFC page:
 
 http://wiki.openstreetmap.org/wiki/RFC_Attribution_Mark
 
 Also take a look at the repository containing artwork and code:
 
 https://github.com/osmlab/attribution-mark
 
 Alex
 
 --
 
 [1] Initial RFC 
 http://lists.openstreetmap.org/pipermail/talk/2013-January/065784.html  
 [2] Feedback summary 
 http://lists.openstreetmap.org/pipermail/talk/2013-January/065860.html
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] RFC updated: OSM Attribution Mark (was: contributor mark)

[Michal Migurski]

On Apr 22, 2013, at 9:40 AM, Phil! Gold wrote:

 3. A completely redesigned `/copyright` page, the page the mark links to.
 It is much closer to today's `/copyright`
 
 I think the new copyright page is very nice looking and presents its data
 well, but I, personally, still find it a little confusing in that there
 are very few visual cues that you can scroll down.

Agreed with this, and follow-up posts saying similar things. Gov.uk are the 
ones to emulate for quick answers and correct explanations, e.g.:

https://www.gov.uk/intellectual-property-an-overview
https://www.gov.uk/bank-holidays

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Turn restriction dispute

[Michal Migurski]

I don't agree. NE2’s edits, most of all the route relations, are enormously 
valuable to OSM in the US. I'm not aware of any precedent for banning a user 
like this, and I'm not eager to see one set. 

-mike.

---
michal migurski http://mike.teczno.com

On Feb 9, 2013, at 9:30 PM, stevea stevea...@softworkers.com wrote:

 Russ, I second your vote/motion, not that anybody called for a second, or 
 even that I am able to offer it.  What I AM able to do is be civil and use 
 the talk-us list, as it is our nationwide forum to discuss.  There are 
 plenty of other consensus understandings that might be loosely called 
 rules which make up the fabric of OSM as a community.  NE2 has again proven 
 that he is either unwilling or unable to abide by those.  Consequently, I 
 think we should inform him that serious discussion of permanently banning him 
 from OSM (this thread) is underway, and his behavior can either change for 
 the better, or he can count on eventually being permanently banned.  He has 
 had plenty of opportunities to do so, and so I am not optimistic he will be 
 around much longer.  But if the community wants him, that can emerge as a 
 consensus as well.
 
 His better (than nothing) edits are in a clear minority compared to the 
 usual messes he makes.  He DOES, for better or worse, stir controversy, which 
 is why we discuss, which is part of the community. If, for that reason alone 
 (that he is controversial), there are those who do not wish to ban him, speak 
 up now, as you may (may) be able to make the case that we need somebody like 
 him as an example of what to do with difficult contributors.  I think it is 
 unanimous that he is that, at least.
 
 I wouldn't miss him if he were gone, either.
 
 SteveA
 California
 
 
 He's banned from (at least) this list. Consequently, you cannot expect
 him to discuss this issue here.
 
 We had a discussion of whether to ban him from editing in the past,
 which never really got resolved. It just died out. Yes, he's done a
 lot of editing, and yes, some of his edits have been fruitful, but no,
 some of his edits have been less than helpful. I wouldn't miss him if
 he were gone.
 
 I vote, not that anybody called for a vote, to ask him to leave.
 -russ
 
 ___
 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] Turn restriction dispute

[Michal Migurski]

I'm familiar with his work and have run afoul of his views in the past, most 
recently when I performed a large scale edit to US route relation tags, some of 
which he did not agree with. I don't know if any were reverted. Nevertheless, I 
don't see the value in running him out on a rail without more actual evidence 
of malice, detailed precedents from other bans, and some expectation that the 
OSMF could help here. These days I'm happier with NE2 than I am with the 
foundation, believe it or not. 

-mike.

---
michal migurski http://mike.teczno.com

On Feb 10, 2013, at 8:53 AM, Serge Wroclawski emac...@gmail.com wrote:

 On Sun, Feb 10, 2013 at 8:56 AM, Michal Migurski m...@teczno.com wrote:
 I don't agree. NE2’s edits, most of all the route relations, are enormously 
 valuable to OSM in the US. I'm not aware of any precedent for banning a user 
 like this, and I'm not eager to see one set.
 
 Mike,
 
 Your information on NE2 is grossly inaccurate.
 
 NE2 makes very few positive edits, and many, many destructive ones, as
 well as previous threats to make more edits that conform with his (and
 only his) vision of the world.
 
 I realize that from a numerical standpoint, it may seem like he is a
 positive contributor, but this is due to our general acceptance of
 people even in the face of disagreement. But in NE2's case, he is a
 bully, and having a bully does not serve the community well.
 
 Regarding precedent, this would not be the first person that the OSMF
 has had to take action on. Others have been banned, but NE2's
 particular brand of edit has always ridden the line, as he's not
 explicitly doing anything illegal (ie not copyright violation). But
 OSM is not his personal playground, and his view that this project is
 his sandbox to impose his will on (reality and community consensus be
 damned) is just unacceptable.
 
 It's understandable that if you are not familiar with NE2's behavior
 first hand, that you would see this as a a misunderstanding, but NE2's
 behavior has been damaging to the project for so long that we simply
 have no choice but to take actions to protect the project's
 cohesiveness.
 
 - Serge
 
 ___
 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: [OSM-talk] Paweł's q: what can be done?

[Michal Migurski]

On Feb 4, 2013, at 11:53 PM, Peter Wendorff wrote:

 Am 05.02.2013 08:15, schrieb Clifford Snow:
 Third parties bring unique value to OSM. However, is it inconceivable that  
 we might be able to offer something more than just a database? 
 
 For example funded Software development has been done by companies like
 CloudMade, MapQuest on a company budget, or Mapbox that applied for external
 funding through the Knight foundation to develop OpenStreetMap software like
 e.g. the iD editor.
  
 This is great until these companies decide that they want us to map 
 according to their rules.  If they are building the tools then we have lost 
 the ability to set our directions. Now from what I've seen of the iD editor 
 it's great. The point I'm trying to stress is that we should set our own 
 path, not let others set it for us. We could still encourage others to build 
 tools, but with the understanding of where we are headed.
 But who is we here? Who should decide how to set our own path? All 
 registered mappers? The OSMF board? Registered users? Active Mappers? What 
 are active mappers? Coders? Active coders? Wiki editors? Every of any of the 
 mentioned groups who is able to read, speak AND write English language?
 Whatever you choose as a definition for we here, it's very likely that 
 it's not better than what we have now: Everybody who want's to decide AND DO.
 Sure: that may be companies, and yes, it may have a bad taste that companies 
 influence how stuff is done in the osm universe, but on the other hand you 
 could say the same about the JOSM or Potlatch maintainers, who influence 
 mapping practice a lot by deciding about tagging templates and the like.
 I think it's good that everyone, even a company, is able to use osm data as 
 well as to provide their users means to contribute back - by providing 
 open-in-osm-editor-links as well as by implementing their own editing 
 functionality (as long as it's done right).
 
 If you want us to set our own path, I have to ask, what differs a 
 better us from the people currently setting up our path - many volunteers 
 coding JOSM, Potlatch and iD (even sponsored by Mapbox/Knight Foundation as 
 far as I know the iD dev people talk to and receive contributions by non-paid 
 volunteers).

I'd like to formally request a moratorium on scare quotes for the remainder of 
this thread.

Looking at you, robin paulson.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Paweł's q: what can be done?

[Michal Migurski]

On Feb 3, 2013, at 3:37 AM, Robin Paulson wrote:

 On 2013-02-03 12:14, Michal Migurski wrote:
 Communication is hard, and there are ways to do it that make people
 feel like they're getting a complete story instead of a confused
 glimpse through an accidentally-open door. Simon's mail left out a lot
 of important things, most notably that he's a member of the OSMF Board
 and that it was an official statement.
 
 Michal, what do you mean by official?
 
 from wikipedia, i see:
 An official is someone who holds an office (function or mandate, regardless 
 whether it carries an actual working space with it) in an organization or 
 government and participates in the exercise of authority (either his own or 
 that of his superior and/or employer, public or legally private).
 
 which concerns me no end. what position of authority does simon hold? over 
 whom?

Simon is the elected chairman of the OSMF board, and can speak on its behalf. 
He holds a position of authority over the Geocode Inc. issue because apparently 
the foundation received a CD.


 what significance does the osmf board hold? they speak for themselves, not 
 anyone else.


That's exactly the question at hand in this particular argument.

We seem to have an OSMF that's not effective at communicating, and large parts 
of the community don't see the value they offer. Your takeaway is that the 
board is not representative of the project and should not exist at all. My 
feeling is that a project needs a political structure to survive. In either 
case, Geocode Inc. believes that the OSMF are the right people to receive a CD.

Ultimately, someone needs to own the domain name and the API and the servers it 
runs on. That's who the Geocodes of the world are going to target. It would be 
best if that someone was answerable to the larger community through a 
democratic process of some sort, so in my view the OSMF is a requirement.

I'm not frustrated that we *have* a board, I'm frustrated that the board we've 
got doesn't seem effective at communicating its purpose or much of anything 
else. They're bad at politics. If they were good at politics, you wouldn't be 
disagreeing with the idea of a board because you'd be thankful for the 
provision of a quality API and the decisive resolution of legal threats from 
trademark trolls.

For what it's worth, I was on the US OSMF board last year, and the most 
important thing I learned about myself is that I'm bad at politics, too, so I 
totally understand that this stuff is hard.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Paweł's q: what can be done?

[Michal Migurski]

For what it's worth, I agree with Jeff and Paweł on this.

If OSMF is going to be a big, beautiful mess it should own that and publish the 
CD for everyone to see. Anarchists gonna anarchate.

If on the other hand we want strong leadership that can handle a trademark 
dispute on its own, then we're missing a lot of what leadership is about: clear 
communication, visible power structure, authority figures who can speak on 
behalf of the organization, draw fire, and so on.

Does the board want to be a board?

-mike.

On Feb 2, 2013, at 10:41 AM, Jeff Meyer wrote:

 was: geocoding trademark thread
 
 I think Paweł has hit on a key question: does the OSMF have plans to operate 
 and lead OSM in a more efficient, organized manner or not? And, to an even 
 more relevant issue: how many people like Paweł show up on the doorstep and 
 don't bother engaging for the same reasons he mentions?
 
 There's a group working in parallel to put together a strategic plan, in the 
 absence of one, but doing this without leadership and support from the top 
 can be problematic. And, no, saying, That's great, go for it, isn't really 
 support.
 
 I hope Paweł doesn't leave, but I cannot blame him for feeling the way he 
 feels. His points are on target. Are there any plans in place for OSMF to 
 address these types of questions by SotM 2013?
 
 - Jeff
 
 -- Forwarded message --
 From: Paweł Paprota ppa...@fastmail.fm
 Date: Sat, Feb 2, 2013 at 4:25 AM
 Subject: Re: [OSM-talk] Recent edits in the wiki / Trademark issue
 To: talk@openstreetmap.org
 
 
 On 02/01/2013 08:54 PM, andrzej zaborowski wrote:
 I agree with what you're saying although I can't help thinking that
 if the OSMF can't take the risk of having some things in the wiki,
 the solution, for everyone's benefit, is to move the wiki to a server
 that's not paid for by the OSMF.  I'm positive finding such a server
 wouldn't be difficult (in fact the home page says it is hosted at UCL
  ByteMark -- so if the OSMF is neither hosting nor writing the
 content, should it accept the C+D?  The admins *are* OSMF members,
 but they're not OSMF). The OSMF has at some point started assuming
 responsibility for what is being published in the database and now on
 the wiki.  In the case of the database it makes sense for someone to
 give some level of warranty that the data in it in fact is legally
 usable, although the consequences of this step have had a terrible
 effect on the map and the community so far.
 
 +100
 
 Current situation is getting silly to the point that I'm seriously
 considering abandoning this project and leaving history tab, vector
 tiles and my other projects unfinished just to have peace of mind and
 work in a sane project with sane organization behind it like KDE.
 
 On one hand OSMF is telling us they don't want any strategic planning
 and involvement, on the other they are redacting and editing data and
 wiki. And this is possible mostly because what Andrzej said - that they
 host the servers (which I am personally grateful for - to the admins -
 no to people who use it for political bullshit like this).
 
 This is NOT how a project should work and you will only discourage
 people by doing such stunts.
 
 Either finally get your act together and prepare a proper organization
 like KDE e.v (http://ev.kde.org/) or get out of the project and
 leave it be. There is still plenty of energy that will fill the void
 after you (I'm talking to OSMF).
 
 Paweł
 
 -- Forwarded message --
 From: Paweł Paprota ppa...@fastmail.fm
 Date: Sat, Feb 2, 2013 at 5:55 AM
 Subject: Re: [OSM-talk] Recent edits in the wiki / Trademark issue
 To: Ed Loach e...@loach.me.uk
 Cc: talk@openstreetmap.org
 
 
 On 02/02/2013 02:38 PM, Ed Loach wrote:
 As far as I can see, OSMF Ltd is very like KDE ev; compare
 http://blog.osmfoundation.org/about/ and
 http://ev.kde.org/whatiskdeev.php
 
 Legal status is the least of what I meant. Compare what OSMF does with
 this quarterly report from the KDE foundation:
 
 http://ev.kde.org/reports/ev-quarterly-2012_Q3.pdf
 
 Not only is all this stuff happening but they also have people who
 prepare such a nice quarterly report.
 
 Also note fund raising efforts, expenses and donations, partners, new
 members etc.
 
 This is an organization that actually supports the community in their
 efforts. And they are not evil in doing that.
 
 What can be done to steer OSMF into that direction? Can it be even done
 at this point?
 
 
 Paweł
 
 
 -- 
 Jeff Meyer
 Global World History Atlas
 www.gwhat.org
 j...@gwhat.org
 206-676-2347
  osm: Historical OSM / my OSM user page
  t: @GWHAThistory
  f: GWHAThistory
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

Re: [OSM-talk] Paweł's q: what can be done?

[Michal Migurski]

On Feb 2, 2013, at 2:49 PM, Frederik Ramm wrote:

 And Jeff followed up:
 
 I think Paweł has hit on a key question: does the OSMF have plans to operate 
 and lead OSM in a more efficient, organized manner or not?
 
 In what way would an organisation with great strategic planning, one that is 
 efficient and organised, handle such a trademark issue differently? In 
 how far is the current trademark issue a sign of lack of planning? I really 
 don't get it. Is there a connection between these issues that goes beyond 
 both are issues where the OSMF is criticised by some?

Communication is hard, and there are ways to do it that make people feel like 
they're getting a complete story instead of a confused glimpse through an 
accidentally-open door. Simon's mail left out a lot of important things, most 
notably that he's a member of the OSMF Board and that it was an official 
statement.

Dear OSM Contributors,

We at the OSM Foundation have recently received a cease  desist letter from 
Geocode, Inc. of Alexandria, Virginia, USA regarding the use of links 
displaying the Google geocoding service on the wiki. We have consulted with our 
legal counsel, and they have advised us to remove these links from all 
OSMF-owned domains. While we believe that Geocode's claims are without merit, 
we have decided that the potential negative impact of Geocode's actions 
outweighs the benefits of keeping those links on the wiki. [detailed 
description of potential negative outcomes].

We will be watching all future edits to the wiki to ensure that new references 
to the Google geocoding service are not introduced to the site. Editors 
attempting to add these links will be automatically referred to this message 
explaining why their edits have been rejected. [link to this message on an 
OSMF-controlled blog or domain].

We will be responding to Geocode Inc. and contacting Google Inc. to [do 
whatever happens next].

We apologize for the drastic nature of this action, but we feel that the 
[detailed description of potential negative outcomes] is an unacceptable risk 
to the mission of OpenStreetMap, and outweighs the adverse impact of removing 
the problem links. As a representative of the board on this issue, I will be 
available to discuss it [on email, IRC, conference call, whatever].

-Sincerely, Joe Q. Boardmember
OpenStreetMap Foundation.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] More on TIGER: Where it's likely safe to import

[Michal Migurski]

Okay, so I didn't do the density thing yet, but I've made some other additions 
to the TIGER green map that I think are worth mentioning.

I squashed the greens and inverted the blacks so that the map is more legible, 
potentially easier to print, and less confusing in the difference between the 
no-editors and yes-editors areas. The URLs are all still the same and the map 
is here:
http://www.openstreetmap.us/~migurski/green-means-go/

If you see any black tiles, clear your cache. The old version is now here:
http://www.openstreetmap.us/~migurski/green-means-go-2013-01-03/

I'm starting to add SEO-friendly, single-geography views. I'm just getting 
started, using counties at first. Every county in the lower 48 will be 
accessible via a URL like one of these:

http://www.openstreetmap.us/~migurski/green-means-go/Iowa/O'Brien-County.html

http://www.openstreetmap.us/~migurski/green-means-go/California/Alameda-County.html

http://www.openstreetmap.us/~migurski/green-means-go/Illinois/Cook-County.html

http://www.openstreetmap.us/~migurski/green-means-go/California/San-Bernardino-County.html

http://www.openstreetmap.us/~migurski/green-means-go/California/Riverside-County.html

http://www.openstreetmap.us/~migurski/green-means-go/Arizona/Coconino-County.html

http://www.openstreetmap.us/~migurski/green-means-go/Louisiana/East-Baton-Rouge-Parish.html

http://www.openstreetmap.us/~migurski/green-means-go/New-York/New-York-County.html

http://www.openstreetmap.us/~migurski/green-means-go/Virginia/Falls-Church-city.html

The county views are open to suggestions, and quite low on detail for the 
moment. What should go on there?

-mike.

On Jan 6, 2013, at 5:51 PM, Michal Migurski wrote:

 Thanks Steve!
 
 I think that would be possible, yeah. I already use object density as one of 
 the inputs here, and could use it to tweak the greens somewhat. The colors 
 need a second pass.
 
 -mike.
 
 On Jan 4, 2013, at 3:00 PM, Steve Coast wrote:
 
 Mike
 
 Nice.
 
 Could you use relative object density per little square as a proxy for 
 population density?
 
 I ask because all the bright green areas near me are forests or old milk 
 farms. I don’t care. I want to see high density areas and attack those as a 
 priority since that’s where people are and where they go...
 
 Steve
 
 From: Michal Migurski m...@teczno.com
 Sent: January 3, 2013 7:03 PM
 To: OpenStreetMap US Talk talk-us@openstreetmap.org
 Subject: Re: [Talk-us] More on TIGER: Where it's likely safe to import
 
 On Dec 17, 2012, at 12:40 PM, Michal Migurski wrote:
 
 On Dec 16, 2012, at 8:32 PM, Martijn van Exel wrote:
 
 Have you looked into full history planet parsing to get a fuller
 picture of editing history? I took a stab at full history user metrics
 some time ago using osmjs;
 https://github.com/mvexel/OSMQualityMetrics/blob/master/UserStats.js -
 this produces one set of metrics for the entire .osh file you feed it
 but it may prove useful for future work. I haven't touched this in a
 while but it should still work :/
 
 I have downloaded a copy and given it a beginning look. I'm new to parsing 
 things of that magnitude; my first thought was to use the full history file 
 for creations/modifications/deletions on nodes and add that to what I'm 
 doing already for ways on the osm2pgsql tables. Does that sound reasonable?
 
 Over the holiday break, I've been grinding through the full history file. 
 I'll write more about the process and publish some raw data, but the short 
 version is that I've replaced the Green Means Go tiles with new versions 
 that incorporate edits to the underlying nodes, address some of the feedback 
 I've received, and show a slightly different map of the US.
 
 New map:
http://www.openstreetmap.us/~migurski/green-means-go/
 
 Old map:
http://www.openstreetmap.us/~migurski/green-means-go-2012-12-16/
 
 Charlotte Wolter and NE2 both pointed out that Florida should see a lot more 
 post-import editing that I had originally shown, and in fact that's what the 
 map now shows:

 http://www.openstreetmap.us/~migurski/green-means-go/#9/28.3213/-81.6257

 http://www.openstreetmap.us/~migurski/green-means-go-2012-12-16/#9/28.3213/-81.6257
 
 Urban fringe areas also show more edits, making them less attractive targets 
 for blind imports:

 http://www.openstreetmap.us/~migurski/green-means-go/#10/37.7707/-122.3451

 http://www.openstreetmap.us/~migurski/green-means-go-2012-12-16/#10/37.7707/-122.3451
 
 I've also stripped away the US coastal territory based on NLCD water 
 designation, per SteveC's suggestion.
 
 These massive edits to counties in Pennsylvania are interesting to me:
http://www.openstreetmap.us/~migurski/green-means-go/#8/40.918/-77.146
 
 -mike.
 
 
 michal migurski- contact info and pgp key:
 sf/cahttp

[Talk-us] US Shields Development Server (was: paying a debt and making connections)

[Michal Migurski]

On Jan 17, 2013, at 1:04 PM, Mike N wrote:

 On 1/17/2013 10:10 AM, Richard Weait wrote:
 I did ask, what it would take to get you to hold a local Mappy Hour in
 your town?  That was never answered.  So, I ask again, What would it
 take?
 
  More mappers.   I've tried everything I could think of to get others 
 interested, but have given up recently - it's all an uphill swim.
 
  But.one new mapper in my area was highly motivated to contribute by the 
 US Shields Development Server.   He seems to have lost interest in more 
 contributions while waiting for a possible real US Shields Server.


This sounds interesting, what is it?

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] RFC - OSM contributor mark

[Michal Migurski]

I like the spirit of this, and I think it's a necessary and welcome idea. When 
Stamen did the Nike Grid Run project a few years ago, the one place where it 
was not possible to display correct attribution was on the TV ads, so a 
significantly smaller but still compliant contribution marker would have been 
helpful. I think it should be textual though, and in my opinion a memorable 
link to more useful information. 

What about osm.org/c ? Small, obviously a URL, can be easily tucked away in a 
corner in the same way as the hammer mark, but when seen it can be acted-on 
regardless of medium. /c would redirect. 

-mike.

---
michal migurski http://mike.teczno.com

On Jan 11, 2013, at 10:30 AM, Mikel Maron mikel_ma...@yahoo.com wrote:

 I agree with the other comments. Some text is needed, though perhaps it can 
 be compressed to something like Made By OSM? I do like the symbol in 
 itself, but it's too subtle here and needs to somehow evoke the OSM brand.
  
 * Mikel Maron * +14152835207 @mikel s:mikelmaron
 From: Alex Barth a...@mapbox.com
 To: talk@openstreetmap.org Openstreetmap talk@openstreetmap.org 
 Sent: Friday, January 11, 2013 9:26 AM
 Subject: [OSM-talk] RFC - OSM contributor mark
 
 Over here at MapBox we see a need to better communicate the open and 
 contributory philosophy of OpenStreetMap on our maps. In striving to build a 
 true data commons for contributing and distributing geographic knowledge, 
 OpenStreetMap relies on map users being aware of the openness of its 
 underlying data. At the same time there is room for improvement how we all 
 (the OpenStreetMap community) attribute map data - the ever-expanding range 
 of OSM based maps in the world are an incredible communication channel to 
 talk to individuals who are potential contributors, and encourage them to 
 choose open data or support the OpenStreetMap project in other ways.
 
 ## Proposal
 
 Inspired by successful campaigns like Intel Inside and Fair Trade, this 
 RFC proposes an OpenStreetMap contributor mark for use on OpenStreetMap based 
 maps. The goal of the OSM contributor mark is to be adopted by as many OSM 
 data users as possible and on as many OSM based maps as possible, thus 
 creating more awareness of the value of free and open geographic data.
 
 With these goals in mind
 
 - the mark should be compelling and recognizable (i.e. not generic).
 - it should work off maps in cases where thumbnail maps need to be attributed 
 e.g. in mobile devices
 - the mark should be clearly distinct from common map user interface elements.
 - the mark should link to a page on openstreetmap.org that explains the 
 openness of OSM data and its local, community driven nature.
 
 Based on this thinking, we have developed a mark that links to a 
 corresponding page for OpenStreetMap.org. This work is captured in a pull 
 request to openstreetmap.org, but you can review it on the demo instance I 
 will walk through here.
 
 Pull request: https://github.com/openstreetmap/openstreetmap-website/pull/180
 
 ### Example usages
 
 Here are some example maps using the OSM contributor mark:
 
 http://yhahn.github.com/byosm/examples.html
 
 (none of the organizations or individuals used on these examples have 
 officially endorsed this proposal yet, including osm.org).
 
 ### Linking back to OSM
 
 The contributor mark on these maps link all back to the same page that should 
 be ultimately hosted on `openstreetmap.org/contributors`:
 
 http://yhahn.github.com/byosm/ (just a demo domain, this should live ideally 
 on `openstreetmap.org/contributors`)
 
 The osm.org/contributors communicates key OpenStreetMap features:
 
 - Powering map data in hundreds of applications
 - Local knowledge
 - Community driven
 - Open data
 
 A learn more button invites to explore more.
 
 The main purpose of this page is to feature OpenStreetMap as a community 
 powered project. Hence we worked with pictures of individuals where possible. 
 *We are currently reaching out to photographers and individuals on pictures 
 to get copyright permissions and model releases, if you're on one of these 
 pictures or if you're the photographer of one of these pictures, please get 
 in touch with me.*
 
 ### Configurable tiles and wording
 
 By modifying the URL to osm.org/contributors specific tile sets and map 
 providers can be featured, like in this example of a link from a Stamen map:
 
 http://yhahn.github.com/byosm/index.html?name=Stamenimage=tile.stamen.com/watercolor/10/164/396.jpgvendor=StamenvendorURL=maps.stamen.com
 
 ### Linking back to OSM based services
 
 Organizations who provide OSM based services can choose to set a discreet 
 link from the bottom of osm.org/contributors to their web sites:
 
 http://yhahn.github.com/byosm/index.html?name=skobblerimage=http://tiles2.skobbler.net/osm_tiles2/11/511/806.pngvendor=skobblervendorURL=skobbler.us
 
 http://yhahn.github.com/byosm/index.html?name=foursquareimage=https

Re: [OSM-talk] OpenStreetMap Future Look

[Michal Migurski]

On Jan 9, 2013, at 4:26 AM, Paweł Paprota wrote:

 On 01/09/2013 12:20 PM, Peter Wendorff wrote:
 
 Communication professionals IMHO most often sound like marketing.
 
 I did not mean communication professionals but giving more resources to
 the OSMF's Communication Working Group or similar initiatives. Posting a
 tweet or a blog post now and then really is not enough to communicate
 about the project that OSM has become. There needs to be more
 initiatives like switch2osm, campaigns need to be thought out and put
 together. This does not have anything to do with marketing, it's just
 how a project grows.

+1 to this.

OSM is amazing, but operationally it's a big problem that we don't have an 
identifiable power structure. We seem happy to rely on happy accidents and the 
occasional messiah (Cloudmade, Mapquest, more recently Knight/Mapbox) but it's 
not enough. We've mentioned a few successful projects like Apache on this 
thread, but outside the world of software there are also unsuccessful efforts 
that can serve as warning signs. To get unnecessarily political for a minute, 
it's been said of Occupy that failure to make organized demands was a mistake:

Nor does it require poststructuralism-leading-through-anarchism to 
understand how to reverse these developments. You do it by rebuilding a 
powerful and competent regulatory state. You do it by rebuilding the labor 
movement. You do it with bureaucracy. (http://teczno.com/s/x14)

As far as potential solutions or approaches, one that I can think of is to add 
some type of process-based items to the TTT’s, for example: double the number 
of sysadmins qualified and trusted to run the servers, appoint a VP Eng., 
increase the number of core application servers to satisfy higher API demand, 
and develop a database failover/recovery plan. I don't enough of the gory 
details to assert that these are the right ideas, but maybe Tom, Grant, Andy or 
Matt can help add vital information.

Lots of things are like that. They're not complicated. They don't require 
brilliant, innovative strategies, they're just hard. They require more work and 
more effort and than anyone might reasonably expect. The best managers create 
organisational room for that to happen. (http://teczno.com/s/zl9)

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

On Jan 6, 2013, at 4:30 AM, Alex Barth wrote:

 On Jan 4, 2013, at 3:33 PM, Richard Welty rwe...@averillpark.net wrote:
 
 On 1/4/13 1:31 PM, Michal Migurski wrote:
 Interesting—how would you characterize bad roads? One characteristic of 
 crappy TIGER data is road wiggliness, is that what you mean?
 
 the tiger 2010/11/12 data is much better for many of the bad tiger areas. 
 it'd be a bit of work to do
 a comparison of the data, but it might be able to yield the desired 
 information.
 
 This is exactly the direction I'm thinking. What would it take to create a 
 TIGER 07 vs 12 comparison map and use this as a basis for identifying the 
 areas that need most attention? I've been talking to Ian over here and we 
 were thinking of intersecting OSM highway data with TIGER 12. This could be 
 achieved e. g. by overlaying a light, opaque OSM highway layer with a 
 contrasting TIGER layer, only exposing TIGER 12 geometry where it differs 
 from OSM.
 
 Thoughts? 


This approach makes sense. You're thinking to come up with a metric for 
mismatched area between the two datasets? Would it be enough to total it up 
into 1x1 km buckets or would you want it to be substantially more detailed?

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] More on TIGER: Where it's likely safe to import

[Michal Migurski]

Thanks Steve!

I think that would be possible, yeah. I already use object density as one of 
the inputs here, and could use it to tweak the greens somewhat. The colors need 
a second pass.

-mike.

On Jan 4, 2013, at 3:00 PM, Steve Coast wrote:

 Mike
  
 Nice.
  
 Could you use relative object density per little square as a proxy for 
 population density?
  
 I ask because all the bright green areas near me are forests or old milk 
 farms. I don’t care. I want to see high density areas and attack those as a 
 priority since that’s where people are and where they go...
  
 Steve
  
 From: Michal Migurski m...@teczno.com
 Sent: January 3, 2013 7:03 PM
 To: OpenStreetMap US Talk talk-us@openstreetmap.org
 Subject: Re: [Talk-us] More on TIGER: Where it's likely safe to import
  
 On Dec 17, 2012, at 12:40 PM, Michal Migurski wrote:
 
  On Dec 16, 2012, at 8:32 PM, Martijn van Exel wrote:
 
  Have you looked into full history planet parsing to get a fuller
  picture of editing history? I took a stab at full history user metrics
  some time ago using osmjs;
  https://github.com/mvexel/OSMQualityMetrics/blob/master/UserStats.js -
  this produces one set of metrics for the entire .osh file you feed it
  but it may prove useful for future work. I haven't touched this in a
  while but it should still work :/
 
  I have downloaded a copy and given it a beginning look. I'm new to parsing 
  things of that magnitude; my first thought was to use the full history file 
  for creations/modifications/deletions on nodes and add that to what I'm 
  doing already for ways on the osm2pgsql tables. Does that sound reasonable?
 
 Over the holiday break, I've been grinding through the full history file. 
 I'll write more about the process and publish some raw data, but the short 
 version is that I've replaced the Green Means Go tiles with new versions that 
 incorporate edits to the underlying nodes, address some of the feedback I've 
 received, and show a slightly different map of the US.
 
 New map:
 http://www.openstreetmap.us/~migurski/green-means-go/
 
 Old map:
 http://www.openstreetmap.us/~migurski/green-means-go-2012-12-16/
 
 Charlotte Wolter and NE2 both pointed out that Florida should see a lot more 
 post-import editing that I had originally shown, and in fact that's what the 
 map now shows:
 
 http://www.openstreetmap.us/~migurski/green-means-go/#9/28.3213/-81.6257
 
 http://www.openstreetmap.us/~migurski/green-means-go-2012-12-16/#9/28.3213/-81.6257
 
 Urban fringe areas also show more edits, making them less attractive targets 
 for blind imports:
 
 http://www.openstreetmap.us/~migurski/green-means-go/#10/37.7707/-122.3451
 
 http://www.openstreetmap.us/~migurski/green-means-go-2012-12-16/#10/37.7707/-122.3451
 
 I've also stripped away the US coastal territory based on NLCD water 
 designation, per SteveC's suggestion.
 
 These massive edits to counties in Pennsylvania are interesting to me:
 http://www.openstreetmap.us/~migurski/green-means-go/#8/40.918/-77.146
 
 -mike.
 
 
 michal migurski- contact info and pgp key:
 sf/cahttp://mike.teczno.com/contact.html
 
 
 
 
 
 ___
 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


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

On Jan 4, 2013, at 1:33 AM, Alex Barth wrote:

 On Jan 3, 2013, at 7:06 PM, Michal Migurski m...@teczno.com wrote:
 
 Sounds great, I'm actually in the middle of publishing a followup to the 
 green-means-go map after ploughing through the full planet history dump.
 
 Great Tue 1/8, 5PM Eastern. My handle is lx_barth, I'll be on #osm-dev at the 
 same time (alexb). Anybody who's interested here in identifying TIGER deserts 
 is welcome to join.
 
 I just looked at your new green-means-go map. There is the gap that I'm 
 seeing between what you're doing and what Ruben, Ian and I'd like to do: 
 we're particularly interested in places where the TIGER geography is off. I. 
 e. where roads are not where they should be.
 
 After a first test here with Virginia [1] we saw that TIGER deserts do not 
 necessarily equal bad road geography. So we're right now particularly 
 interested in methods for identifying bad TIGER road geography.
 
 I'm thinking such a Bad TIGER Roads Map could be a valuable community 
 resource to see where stuff is worst and needs fixing that we could maintain 
 over time.


Interesting—how would you characterize bad roads? One characteristic of 
crappy TIGER data is road wiggliness, is that what you mean?

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] New History tab for openstreetmap.org (beta)

[Michal Migurski]

Neat!

I found what I think is spam on my first try:

http://owl.apis.dev.openstreetmap.org/?lat=37.8113lon=-122.2754zoom=14layers=M
Look no further than Apple Blossom Florist, the premier Oakland 
florist, for beautifully arranged flowers and gift baskets for any occasion…

Links to changeset #14155469, but that comes up blank here:
http://owl.apis.dev.openstreetmap.org/browse/changeset/14155469

Subsequently reverted but still in the index?

-mike.

On Jan 3, 2013, at 3:01 PM, Paweł Paprota wrote:

 Hi all,
 
 For some time now I've been working on the OpenStreetMap Watch List 
 project[1] and on integrating OWL into the main OSM website.
 
 At this point I've got something slowly approaching beta status and I would 
 appreciate early feedback from the community.
 
 You can see it in action here:
 
 http://owl.apis.dev.openstreetmap.org/
 
 Couple of things:
 
 * Zoom levels = 14 should be usable. On lower zoom levels it sometimes takes 
 a lot of time to show history. Also I don't have clear idea yet what to 
 really show on the lower zoom levels - what would be useful - so suggestions 
 are welcome.
 
 * I'm actively working on this instance so don't be surprised when something 
 breaks or there is no data at all etc. - it's a beta version :-)
 
 * You can click on nodes/ways in the map to get more details about changes :-)
 
 Any comments are welcome.
 
 [1] http://wiki.openstreetmap.org/wiki/OWL_(OpenStreetMap_Watch_List)
 
 Paweł
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] More on TIGER: Where it's likely safe to import

[Michal Migurski]

On Dec 17, 2012, at 12:40 PM, Michal Migurski wrote:

 On Dec 16, 2012, at 8:32 PM, Martijn van Exel wrote:
 
 Have you looked into full history planet parsing to get a fuller
 picture of editing history? I took a stab at full history user metrics
 some time ago using osmjs;
 https://github.com/mvexel/OSMQualityMetrics/blob/master/UserStats.js -
 this produces one set of metrics for the entire .osh file you feed it
 but it may prove useful for future work. I haven't touched this in a
 while but it should still work :/
 
 I have downloaded a copy and given it a beginning look. I'm new to parsing 
 things of that magnitude; my first thought was to use the full history file 
 for creations/modifications/deletions on nodes and add that to what I'm doing 
 already for ways on the osm2pgsql tables. Does that sound reasonable?

Over the holiday break, I've been grinding through the full history file. I'll 
write more about the process and publish some raw data, but the short version 
is that I've replaced the Green Means Go tiles with new versions that 
incorporate edits to the underlying nodes, address some of the feedback I've 
received, and show a slightly different map of the US.

New map:
http://www.openstreetmap.us/~migurski/green-means-go/

Old map:
http://www.openstreetmap.us/~migurski/green-means-go-2012-12-16/

Charlotte Wolter and NE2 both pointed out that Florida should see a lot more 
post-import editing that I had originally shown, and in fact that's what the 
map now shows:
http://www.openstreetmap.us/~migurski/green-means-go/#9/28.3213/-81.6257

http://www.openstreetmap.us/~migurski/green-means-go-2012-12-16/#9/28.3213/-81.6257

Urban fringe areas also show more edits, making them less attractive targets 
for blind imports:

http://www.openstreetmap.us/~migurski/green-means-go/#10/37.7707/-122.3451

http://www.openstreetmap.us/~migurski/green-means-go-2012-12-16/#10/37.7707/-122.3451

I've also stripped away the US coastal territory based on NLCD water 
designation, per SteveC's suggestion.

These massive edits to counties in Pennsylvania are interesting to me:
http://www.openstreetmap.us/~migurski/green-means-go/#8/40.918/-77.146

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] what to do cues

[Michal Migurski]

On Dec 30, 2012, at 9:54 PM, Jeff Meyer wrote:

 Are there any tools that can tip users to what they could do in a particular 
 map area?
 
 For example, for a given bb(zoomsome min) in a browser window, is there 
 anything that says:
 - Hey, relative to other (or selected best-practice examples) areas like the 
 one you're viewing, this area has:
 -- Fewer addresses - learn how to add
 -- Fewer buildings - learn how to add
 -- Fewer POIs - learn how to add
 -- POIs that would normally have buildings, but don't (e.g. schools)
 -- Zorro Ways - learn how to fix
 -- There's a park with no trails - learn how to add
 -- etc.
 
 In general, I'm thinking of something that will help new users answer the 
 question, How can I help?, particularly for their local 'hood without 
 sending them to too (too) many off-map web resources. Or even a suggestive 
 OSM Inspector?

Geofabrik has the Inspector tool, which is a bit inside-baseball but does a 
great job of surfacing a variety of common tagging and geometry problems:

http://tools.geofabrik.de/osmi/debug.html?view=geometrylon=-122.29381lat=37.80892zoom=11opacity=0.29

http://tools.geofabrik.de/osmi/debug.html?view=tagginglon=-122.33638lat=47.55957zoom=11opacity=0.29

It'd be interesting to develop code for some of the more wish-listey items you 
suggest, like parks with no trails or buildingless-POIs.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

On Dec 20, 2012, at 11:19 AM, Michal Migurski wrote:

 next steps
 
 A few obvious steps stand out, including rendering a national version of 
 these maps. I'd also love to figure out whether it makes sense to join 
 forces with Mike Migurski's Green Means Go map.
 
 It'd also be interesting to use a smarter Osmosis command (and the full 
 history file) to limit the input data to just those ways created by the 3 
 primary user accounts associated with the TIGER 
 import:https://github.com/MapQuest/TIGER-Edited-map/blob/master/inc/layer-tiger.xml.inc#L45
  (h/t Migurski)
 
 Joining forces would be fun!
 
 For the past two days, I've been processing the Full History file into a form 
 that's easier to cope with for a big categorization run. I want to look at 
 the individual nodes, using their associated changesets to pick up on 
 non-import edits that fell through the cracks when I looked only at OSM ways.
 
 Here's where I'm at now:
   http://www.openstreetmap.us/~migurski/TIGER-Raster/nodes/


I've updated the page above with a preliminary rendering showing non-TIGER node 
density, preview and full GeoTIFF here:


http://www.openstreetmap.us/~migurski/TIGER-Raster/nodes/non-tiger-uids.jpg

http://www.openstreetmap.us/~migurski/TIGER-Raster/nodes/out-full-history-uids-no.tif.bz2

I'm processing the full history planet file a second time now, paying attention 
to just the nodes that make up ways with highway tags, since I'm noticing a lot 
of large non-road imports in this dataset.

Also, what's the deal with the Massachusetts TIGER import? When did it happen? 
The state is conspicuously missing when I use the Mapquest TIGER edits case 
statement:

(case when osm_uid = '7168' -- DaveHansenTiger
and osm_timestamp::timestamp = 
'2007-08-03'::timestamp
and osm_timestamp::timestamp = 
'2008-05-04'::timestamp
  then 0
  when osm_uid = '15169' -- Milenko
and osm_timestamp::timestamp = 
'2007-10-29'::timestamp
and osm_timestamp::timestamp = 
'2007-12-12'::timestamp
  then 0
  when osm_uid = '20587' -- balrog-kun
and osm_timestamp::timestamp = 
'2010-03-21'::timestamp
and osm_timestamp::timestamp = 
'2010-04-08'::timestamp
and osm_version::int  3 -- maybe someone else 
edited between import and name expansion
  then 0
  else 1 end) as is_touched

(Github currently dead but it's from 
https://github.com/MapQuest/TIGER-Edited-map/blob/master/inc/layer-tiger.xml.inc)

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

On Dec 22, 2012, at 7:01 PM, Russ Nelson wrote:

 Michal Migurski writes:
 Also, what's the deal with the Massachusetts TIGER import?
 
 Massachusetts had already made an improved version of the TIGER data,
 so the decision was made to import that instead.


Ah, good to know. Any idea what the approximate date and importing account were?

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

On Dec 19, 2012, at 5:39 PM, Ruben Lopez Mendoza wrote:

 We've worked out some kinks of our first attempt to identify TIGER deserts, 
 and produced maps a couple maps along the way.
 
 …
 I've captured all of this work - the postgres functions, shapefiles, and 
 tilemill projects in the a repo here:https://github.com/Rub21/tiger-deserts

+1.


 next steps
 
 A few obvious steps stand out, including rendering a national version of 
 these maps. I'd also love to figure out whether it makes sense to join forces 
 with Mike Migurski's Green Means Go map.
 
 It'd also be interesting to use a smarter Osmosis command (and the full 
 history file) to limit the input data to just those ways created by the 3 
 primary user accounts associated with the TIGER 
 import:https://github.com/MapQuest/TIGER-Edited-map/blob/master/inc/layer-tiger.xml.inc#L45
  (h/t Migurski)

Joining forces would be fun!

For the past two days, I've been processing the Full History file into a form 
that's easier to cope with for a big categorization run. I want to look at the 
individual nodes, using their associated changesets to pick up on non-import 
edits that fell through the cracks when I looked only at OSM ways.

Here's where I'm at now:
http://www.openstreetmap.us/~migurski/TIGER-Raster/nodes/

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] More on TIGER: Where it's likely safe to import

[Michal Migurski]

On Dec 16, 2012, at 8:32 PM, Martijn van Exel wrote:

 OK this is plain awesome. Great work Mike.
 
 One note of caution though - the title may suggest that you can just
 go ahead and import away, but folks would still have to follow the
 import guidelines and contact the OSM community at large, come up with
 a solid proposal and discuss that, even if there is no local
 community. I know it says it on the tin, but it's kind of tucked away
 at the bottom.

You're right, I've emphasized that up near the top, thanks.


 Have you looked into full history planet parsing to get a fuller
 picture of editing history? I took a stab at full history user metrics
 some time ago using osmjs;
 https://github.com/mvexel/OSMQualityMetrics/blob/master/UserStats.js -
 this produces one set of metrics for the entire .osh file you feed it
 but it may prove useful for future work. I haven't touched this in a
 while but it should still work :/

I have downloaded a copy and given it a beginning look. I'm new to parsing 
things of that magnitude; my first thought was to use the full history file for 
creations/modifications/deletions on nodes and add that to what I'm doing 
already for ways on the osm2pgsql tables. Does that sound reasonable?

I'll check out your parser; what kinds of metrics does it produce?

-mike.

 On Sun, Dec 16, 2012 at 8:02 PM, Michal Migurski m...@teczno.com wrote:
 I pulled together some of the notes and imagery I've been posting here 
 recently:
 
http://www.openstreetmap.us/~migurski/green-means-go/
 
 It's a map of 1km×1km squares covering the continental United States. Green 
 squares show places where data imports are unlikely to interfere with 
 community mapping. Raw data is linked at the bottom.
 
 Three things that would make this better:
 
 - Regular updates with archived older versions.
 - Renders for specific counties, intended for local GIS communities.
 - Some awareness of full planet history.
 
 The OSM-US server has data for regular updates.
 
 -mike.
 
 
 michal migurski- contact info and pgp key:
 sf/cahttp://mike.teczno.com/contact.html
 
 
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 
 
 -- 
 Martijn van Exel
 http://oegeo.wordpress.com/
 http://openstreetmap.us/
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] More on TIGER: Where it's likely safe to import

[Michal Migurski]

On Dec 17, 2012, at 1:58 AM, Frederik Ramm wrote:

 Hi,
 
 On 12/17/12 04:02, Michal Migurski wrote:
 I pulled together some of the notes and imagery I've been posting here 
 recently:
 
  http://www.openstreetmap.us/~migurski/green-means-go/
 
 I take offense at your wording (on the page): Where in the United States 
 could government imports improve OpenStreetMap? - you might add data to OSM 
 but will you improve OSM? It's not the same, and equating the two is a 
 mistake that insiders should not make.
 
 The wording
 
 Green squares show places where data imports are unlikely to interfere with 
 community mapping.
 
 is also misleading; it has been shown that imports can very well interfere 
 with *future* community mapping of which you would, naturally, not find 
 traces in the data you analysed.
 
 The correct wording is:
 
 Green squares show places where little or no community mapping has taken 
 place in the past.


How about something like this?
Green squares show places where data imports are unlikely to conflict 
with past community mapping.

I think in the case of the US, the previous government data is so bad relative 
to what's currently out there that a fresh import will necessarily improve OSM, 
if I can make the green areas more reflective of the true state of edited 
places. Full history is a means to this; I've got some off-list responses from 
people who don't think that their own mapping efforts are accurately reflected 
in the green squares.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] More on TIGER: Where it's likely safe to import

[Michal Migurski]

Information density: maybe a different grid for lower zoom levels, e.g. 5km, 
10km, etc.? It would have the opposite effect of what's there now I think, 
which is look at all that green!

-mike.

On Dec 17, 2012, at 12:22 PM, Steve Coast wrote:

 Nice.
 
 Suggestions;
 
 - kill water somehow
 - Information density at low zoom levels implies that basically everywhere is 
 green. But you zoom to the bay area and see this isn't the case. So, change 
 the coloring? Modulate it by population density?
 
 Steve
 
 On Dec 16, 2012, at 8:32 PM, Martijn van Exel m...@rtijn.org wrote:
 
 OK this is plain awesome. Great work Mike.
 
 One note of caution though - the title may suggest that you can just
 go ahead and import away, but folks would still have to follow the
 import guidelines and contact the OSM community at large, come up with
 a solid proposal and discuss that, even if there is no local
 community. I know it says it on the tin, but it's kind of tucked away
 at the bottom.
 
 Have you looked into full history planet parsing to get a fuller
 picture of editing history? I took a stab at full history user metrics
 some time ago using osmjs;
 https://github.com/mvexel/OSMQualityMetrics/blob/master/UserStats.js -
 this produces one set of metrics for the entire .osh file you feed it
 but it may prove useful for future work. I haven't touched this in a
 while but it should still work :/
 
 On Sun, Dec 16, 2012 at 8:02 PM, Michal Migurski m...@teczno.com wrote:
 I pulled together some of the notes and imagery I've been posting here 
 recently:
 
   http://www.openstreetmap.us/~migurski/green-means-go/
 
 It's a map of 1km×1km squares covering the continental United States. Green 
 squares show places where data imports are unlikely to interfere with 
 community mapping. Raw data is linked at the bottom.
 
 Three things that would make this better:
 
 - Regular updates with archived older versions.
 - Renders for specific counties, intended for local GIS communities.
 - Some awareness of full planet history.
 
 The OSM-US server has data for regular updates.
 
 -mike.
 
 
 michal migurski- contact info and pgp key:
 sf/cahttp://mike.teczno.com/contact.html
 
 
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 
 
 -- 
 Martijn van Exel
 http://oegeo.wordpress.com/
 http://openstreetmap.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
 


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] More on TIGER: Where it's likely safe to import

[Michal Migurski]

Agreed. What I *really* want is a version of this map that's tailored to 
meaningful jurisdictions, Census places and counties. It's one thing to see an 
all-over view but if you're a city GIS guy and you have a file of data that you 
want to input, it'd be useful for you to see just your specific area with some 
guidance on how to proceed:

1. How much is green vs. not green, and the likelihood of improvement.
2. OSM users who are responsible for existing work in your area.
3. Non-highway data in the area, e.g. POIs and such.

Christine White from Esri, who attended SOTM-US in Portland, told me that at 
the annual user conference she gets a regular stream of these people 
approaching her with blobs of official data, a desire to donate it to OSM, and 
no knowledge about how to proceed or what effect it would have. We should help 
her and them!

-mike.

On Dec 17, 2012, at 12:39 PM, Charlotte Wolter wrote:

 
 While I like the idea of being able to identify and possibly do 
 imports for one-kilometer-square (why not miles?) chunks of the map, I think 
 it needs to be accompanied with lots of cautionary language about assessing 
 the area thoroughly before taking any such action. We could give people 
 examples of what to look for to see if the area really is a TIGER desert, 
 and what to check before making a move. 
 May be it would be better if a group of squares are identified using 
 criteria set up by the Data group or someone similarly experienced. Then, the 
 square kilometers could be presented in a Maproulette kind of format, but 
 with a chance to choose which one you take on. That way, you could choose 
 square kilometers that are near where you are working anyway or near areas 
 with which you are familiar.
 
 Best, 
 Charlotte
 
 
 At 12:22 PM 12/17/2012, you wrote:
 Nice.
 
 Suggestions;
 
 - kill water somehow
 - Information density at low zoom levels implies that basically everywhere 
 is green. But you zoom to the bay area and see this isn't the case. So, 
 change the coloring? Modulate it by population density?
 
 Steve
 
 On Dec 16, 2012, at 8:32 PM, Martijn van Exel m...@rtijn.org wrote:
 
  OK this is plain awesome. Great work Mike.
  
  One note of caution though - the title may suggest that you can just
  go ahead and import away, but folks would still have to follow the
  import guidelines and contact the OSM community at large, come up with
  a solid proposal and discuss that, even if there is no local
  community. I know it says it on the tin, but it's kind of tucked away
  at the bottom.
  
  Have you looked into full history planet parsing to get a fuller
  picture of editing history? I took a stab at full history user metrics
  some time ago using osmjs;
  https://github.com/mvexel/OSMQualityMetrics/blob/master/UserStats.js -
  this produces one set of metrics for the entire .osh file you feed it
  but it may prove useful for future work. I haven't touched this in a
  while but it should still work :/
  
  On Sun, Dec 16, 2012 at 8:02 PM, Michal Migurski m...@teczno.com wrote:
  I pulled together some of the notes and imagery I've been posting here 
  recently:
  
 http://www.openstreetmap.us/~migurski/green-means-go/
  
  It's a map of 1km×1km squares covering the continental United States. 
  Green squares show places where data imports are unlikely to interfere 
  with community mapping. Raw data is linked at the bottom.
  
  Three things that would make this better:
  
  - Regular updates with archived older versions.
  - Renders for specific counties, intended for local GIS communities.
  - Some awareness of full planet history.
  
  The OSM-US server has data for regular updates.
  
  -mike.
  
  
  michal migurski- contact info and pgp key:
  sf/cahttp://mike.teczno.com/contact.html
  
  
  
  
  
  ___
  Talk-us mailing list
  Talk-us@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-us
  
  
  
  -- 
  Martijn van Exel
  http://oegeo.wordpress.com/
  http://openstreetmap.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
 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

Re: [Talk-us] Fwd: Re: More on TIGER: Where it's likely safe to import

[Michal Migurski]

On Dec 17, 2012, at 1:01 PM, Charlotte Wolter wrote:

 Hi Mike,
 
 I was looking at the web page yu created. One problem is that I'm not 
 sure which green, light or dark or kinda light or kinda dark, means an 
 untouched kilometer. Also, what does black mean?
 Then I checked an area I edited extensively: Chinle, Arizona. Again, 
 I was puzzled because I have worked on most of the area, but some is dark 
 green, some light green and some black. 
 However, the basic idea seems great. It just needs a little more 
 interpretation, I think, and maybe different colors?

Green generally means untouched, based the user IDs attached to ways. I think 
I'm undercounting participation from people who edited nodes whose changes 
don't show up in the line table.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] More on TIGER: Where it's likely safe to import

[Michal Migurski]

On Dec 17, 2012, at 12:50 PM, Steve Coast wrote:

 On Dec 17, 2012, at 12:45 PM, Michal Migurski m...@teczno.com wrote:
 
 Information density: maybe a different grid for lower zoom levels, e.g. 5km, 
 10km, etc.? It would have the opposite effect of what's there now I think, 
 which is look at all that green!
 
 I prefer modulating by population, since a sea of green in Wyoming (with 
 apologies to those in Wyoming) really doesn't matter since nobody lives 
 there. The question is, where is the population / edits ration low, not the 
 absolute edits numbers.
 
 Maybe ask people from CloudMade what they did 3 years ago.
 
 Also, I wouldn't ask the question(s) in a vacuum. I suspect, but cannot 
 confirm, that if you did a similar analysis of NT or TA data in the US you'd 
 see exactly the same thing; a natural economic bias in the metrics to mapping 
 places with high population density.


I suspect the same, it makes sense given driving patterns and economic demand.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

[Talk-us] More on TIGER: Where it's likely safe to import

[Michal Migurski]

I pulled together some of the notes and imagery I've been posting here recently:

http://www.openstreetmap.us/~migurski/green-means-go/

It's a map of 1km×1km squares covering the continental United States. Green 
squares show places where data imports are unlikely to interfere with community 
mapping. Raw data is linked at the bottom.

Three things that would make this better:

- Regular updates with archived older versions.
- Renders for specific counties, intended for local GIS communities.
- Some awareness of full planet history.

The OSM-US server has data for regular updates.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

Are you guys using the way version number to determine TIGERness? This from 
Andy Allan might be more effective:

--
-- TIGER edits case statement from
-- 
https://github.com/MapQuest/TIGER-Edited-map/blob/master/inc/layer-tiger.xml.inc
--
(case when osm_uid = '7168' -- DaveHansenTiger
and osm_timestamp::timestamp = '2007-08-03'::timestamp
and osm_timestamp::timestamp = '2008-05-04'::timestamp
  then 0
  when osm_uid = '15169' -- Milenko
and osm_timestamp::timestamp = '2007-10-29'::timestamp
and osm_timestamp::timestamp = '2007-12-12'::timestamp
  then 0
  when osm_uid = '20587' -- balrog-kun
and osm_timestamp::timestamp = '2010-03-21'::timestamp
and osm_timestamp::timestamp = '2010-04-08'::timestamp
and osm_version::int  3 -- maybe someone else edited between 
import and name expansion
  then 0
  else 1 end) as is_touched

Number of distinct users who've edited in a given area would also be a useful 
metric, though incomplete without reference to the full history file.

-mike.

On Dec 14, 2012, at 7:45 PM, Alex Barth wrote:

 
 Before I log off for tonight, let me share this screenshot I just got from 
 Ruben (cc'ed) showing his progress on creating a slippy TIGER deserts map, 
 pretty much using Martijn's approach of binned average geometry versions. 
 These are first steps and there are still some math problems to iron out, 
 expect an update next week. 
 
 http://cl.ly/image/0x3h0s1H1v0k
 
 On Dec 7, 2012, at 1:00 PM, Ian Villeda vill...@mapbox.com wrote:
 
 
 Hey team, 
 
 Over here at MapBox we were inspired by Martjin's great post on identifying 
 TIGER deserts[1], so we're attempting to effectively identify TIGER deserts 
 for the rest of the continental U.S. (sorry Hawaii + Alaska, you're next). 
 The goal is to create a slippy map from zoom level 2 to 15(?) such that it's 
 easy to find the places in need of the most love.
 
 We have a osmium-genereated postigs database with all ways tagged as 
 highway=* and their version number. The plan to run the analysis against a 
 5x5 km grid, although we will probably play with the size of the gridcell. 
 Another option might be to conduct the analysis and varying levels of 
 granularity. 
 
 We're still consiering different methods of analysis - the goal being to 
 normalize way density to display better identify TIGER deserts. We'd would 
 love your thoughts / input / reactions. A few ideas we've tossed around / 
 are activley pursuing:
 
 - percent of version 1 and/or 2 ways in each gridcell
 - average number of version 1/2 ways per gridcell
 - using a threshold value(s) similiar to Martjin's approach
 - [your ideas here]
 
 Ultimately we'd like showcase the rendered results in site that would make 
 editing TIGER deserts easy. For now though this is just a heads up and an 
 invitation if you have any thoughts on how better to identify TIGER deserts. 
 
 thanks! 
 
 [1]: http://oegeo.wordpress.com/2012/10/21/binders-full-of-tiger-deserts/
 -- 
 ian villeda
 mapbox | developmentseed
 https://twitter.com/ian_villeda
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 Alex Barth
 http://twitter.com/lxbarth
 tel (+1) 202 250 3633
 
 
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

Some context for the query below:
https://gist.github.com/4291608

I've been using this projection for everything, a spherical Albers to make it 
possible to generate a slippy map in a conic projection:
+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 
+a=6378137 +b=6378137 +nadgrids=@null +units=m +no_defs

-mike.

On Dec 14, 2012, at 9:47 PM, Michal Migurski wrote:

 Are you guys using the way version number to determine TIGERness? This from 
 Andy Allan might be more effective:
 
--
-- TIGER edits case statement from
-- 
 https://github.com/MapQuest/TIGER-Edited-map/blob/master/inc/layer-tiger.xml.inc
--
(case when osm_uid = '7168' -- DaveHansenTiger
and osm_timestamp::timestamp = '2007-08-03'::timestamp
and osm_timestamp::timestamp = '2008-05-04'::timestamp
  then 0
  when osm_uid = '15169' -- Milenko
and osm_timestamp::timestamp = '2007-10-29'::timestamp
and osm_timestamp::timestamp = '2007-12-12'::timestamp
  then 0
  when osm_uid = '20587' -- balrog-kun
and osm_timestamp::timestamp = '2010-03-21'::timestamp
and osm_timestamp::timestamp = '2010-04-08'::timestamp
and osm_version::int  3 -- maybe someone else edited between 
 import and name expansion
  then 0
  else 1 end) as is_touched
 
 Number of distinct users who've edited in a given area would also be a useful 
 metric, though incomplete without reference to the full history file.
 
 -mike.
 
 On Dec 14, 2012, at 7:45 PM, Alex Barth wrote:
 
 
 Before I log off for tonight, let me share this screenshot I just got from 
 Ruben (cc'ed) showing his progress on creating a slippy TIGER deserts map, 
 pretty much using Martijn's approach of binned average geometry versions. 
 These are first steps and there are still some math problems to iron out, 
 expect an update next week. 
 
 http://cl.ly/image/0x3h0s1H1v0k
 
 On Dec 7, 2012, at 1:00 PM, Ian Villeda vill...@mapbox.com wrote:
 
 
 Hey team, 
 
 Over here at MapBox we were inspired by Martjin's great post on identifying 
 TIGER deserts[1], so we're attempting to effectively identify TIGER deserts 
 for the rest of the continental U.S. (sorry Hawaii + Alaska, you're next). 
 The goal is to create a slippy map from zoom level 2 to 15(?) such that 
 it's easy to find the places in need of the most love.
 
 We have a osmium-genereated postigs database with all ways tagged as 
 highway=* and their version number. The plan to run the analysis against a 
 5x5 km grid, although we will probably play with the size of the gridcell. 
 Another option might be to conduct the analysis and varying levels of 
 granularity. 
 
 We're still consiering different methods of analysis - the goal being to 
 normalize way density to display better identify TIGER deserts. We'd would 
 love your thoughts / input / reactions. A few ideas we've tossed around / 
 are activley pursuing:
 
 - percent of version 1 and/or 2 ways in each gridcell
 - average number of version 1/2 ways per gridcell
 - using a threshold value(s) similiar to Martjin's approach
 - [your ideas here]
 
 Ultimately we'd like showcase the rendered results in site that would make 
 editing TIGER deserts easy. For now though this is just a heads up and an 
 invitation if you have any thoughts on how better to identify TIGER 
 deserts. 
 
 thanks! 
 
 [1]: http://oegeo.wordpress.com/2012/10/21/binders-full-of-tiger-deserts/
 -- 
 ian villeda
 mapbox | developmentseed
 https://twitter.com/ian_villeda
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 Alex Barth
 http://twitter.com/lxbarth
 tel (+1) 202 250 3633
 
 
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 
 
 michal migurski- contact info and pgp key:
 sf/cahttp://mike.teczno.com/contact.html
 
 
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] MapQuest Open Maps now has proper state shields

[Michal Migurski]

On Dec 9, 2012, at 7:37 PM, James Mast wrote:

 I was just looking at their tiles tonight and they've updated them to include 
 state shields!!  Saw shields for PA, SC, MD, VA, WV, CA, and NY for starters. 
  Maybe now we should all agree to use the proper state abbreviation for the 
 ref tags on the ways instead of not having them at all (Florida), or just 
 SR.

Cool!

If anyone's curious, here's a shapefile with linework for all current (as of a 
few weeks ago) US route relations, generalized to appear at zoom 15.  Coverage 
is great for US:I, US:US and US State routes, starts getting patchy down at the 
county level:
http://benzene.openstreetmap.us/~migurski/US-Routes-2012-12-09.png

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] MapQuest Open Maps now has proper state shields

[Michal Migurski]

On Dec 9, 2012, at 8:12 PM, Michal Migurski wrote:

 I was just looking at their tiles tonight and they've updated them to 
 include state shields!!  Saw shields for PA, SC, MD, VA, WV, CA, and NY for 
 starters.  Maybe now we should all agree to use the proper state 
 abbreviation for the ref tags on the ways instead of not having them at 
 all (Florida), or just SR.
 
 Cool!
 
 If anyone's curious, here's a shapefile with linework for all current (as of 
 a few weeks ago) US route relations, generalized to appear at zoom 15.  
 Coverage is great for US:I, US:US and US State routes, starts getting patchy 
 down at the county level:
   http://benzene.openstreetmap.us/~migurski/US-Routes-2012-12-09.png


…aaand the actual data:
http://benzene.openstreetmap.us/~migurski/US-Routes-2012-12-09.zip

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] MapQuest Open Maps now has proper state shields

[Michal Migurski]

On Dec 9, 2012, at 9:21 PM, Toby Murray wrote:

 On Sun, Dec 9, 2012 at 9:37 PM, James Mast rickmastfa...@hotmail.com wrote:
 I was just looking at their tiles tonight and they've updated them to
 include state shields!!  Saw shields for PA, SC, MD, VA, WV, CA, and NY for
 starters.  Maybe now we should all agree to use the proper state
 abbreviation for the ref tags on the ways instead of not having them at
 all (Florida), or just SR.
 
 Interesting. Anyone know when this happened? Last time I looked I seem
 to recall generic square shields with any state abbreviations stripped
 out. I also don't see any change to their stylesheet on github. I'm
 mostly curious if they switched to route relations or if they are
 still going off of the ref tag on ways.


I would guess ref tags, based on the two mismatched 24’s here:

http://www.openstreetmap.org/?lat=37.82443lon=-122.26695zoom=15layers=Q

Likely due to inconsistent refs on ways like these:
http://www.openstreetmap.org/browse/way/28183735
http://www.openstreetmap.org/browse/way/6348404

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

That's great!

I've been thinking about some of the same things, inspired by Dennis Zielstra's 
talk at SOTM-US. I'm looking at road lengths for 1x1 kilometer squares, 
measuring OSM user count (post-import) vs. possibility for improvement between 
2007 and 2012 TIGER/Line data:

http://mike.teczno.com/img/osm-users-imports-2012-09.png
- Blue means 2012 data would be an improvement
- Red/Yellow means there are active OSM users there

I used an Albers equal-area projection to ensure correct length and density 
regardless of latitude, and my intent for this is to produce county-by-county 
views that GIS managers in different jurisdictions can use to understand 
whether their data is worth important, and what OSM users they'd need to 
contact in order to be successful.

I have a slippy map version of this but the projection registration is off by a 
few hundred meters; need to figure out why that is and fix it.

-mike.

On Dec 7, 2012, at 10:00 AM, Ian Villeda wrote:

 
 Hey team, 
 
 Over here at MapBox we were inspired by Martjin's great post on identifying 
 TIGER deserts[1], so we're attempting to effectively identify TIGER deserts 
 for the rest of the continental U.S. (sorry Hawaii + Alaska, you're next). 
 The goal is to create a slippy map from zoom level 2 to 15(?) such that it's 
 easy to find the places in need of the most love.
 
 We have a osmium-genereated postigs database with all ways tagged as 
 highway=* and their version number. The plan to run the analysis against a 
 5x5 km grid, although we will probably play with the size of the gridcell. 
 Another option might be to conduct the analysis and varying levels of 
 granularity. 
 
 We're still consiering different methods of analysis - the goal being to 
 normalize way density to display better identify TIGER deserts. We'd would 
 love your thoughts / input / reactions. A few ideas we've tossed around / are 
 activley pursuing:
 
 - percent of version 1 and/or 2 ways in each gridcell
 - average number of version 1/2 ways per gridcell
 - using a threshold value(s) similiar to Martjin's approach
 - [your ideas here]
 
 Ultimately we'd like showcase the rendered results in site that would make 
 editing TIGER deserts easy. For now though this is just a heads up and an 
 invitation if you have any thoughts on how better to identify TIGER deserts. 
 
 thanks! 
 
 [1]: http://oegeo.wordpress.com/2012/10/21/binders-full-of-tiger-deserts/
 -- 
 ian villeda
 mapbox | developmentseed
 https://twitter.com/ian_villeda
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

GeoTIFF version of that data:
http://mike.teczno.com/img/osm-users-imports-2012-09.tif

On Dec 7, 2012, at 10:32 AM, Michal Migurski wrote:

 That's great!
 
 I've been thinking about some of the same things, inspired by Dennis 
 Zielstra's talk at SOTM-US. I'm looking at road lengths for 1x1 kilometer 
 squares, measuring OSM user count (post-import) vs. possibility for 
 improvement between 2007 and 2012 TIGER/Line data:
 
   http://mike.teczno.com/img/osm-users-imports-2012-09.png
   - Blue means 2012 data would be an improvement
   - Red/Yellow means there are active OSM users there
 
 I used an Albers equal-area projection to ensure correct length and density 
 regardless of latitude, and my intent for this is to produce county-by-county 
 views that GIS managers in different jurisdictions can use to understand 
 whether their data is worth important, and what OSM users they'd need to 
 contact in order to be successful.
 
 I have a slippy map version of this but the projection registration is off by 
 a few hundred meters; need to figure out why that is and fix it.
 
 -mike.
 
 On Dec 7, 2012, at 10:00 AM, Ian Villeda wrote:
 
 
 Hey team, 
 
 Over here at MapBox we were inspired by Martjin's great post on identifying 
 TIGER deserts[1], so we're attempting to effectively identify TIGER deserts 
 for the rest of the continental U.S. (sorry Hawaii + Alaska, you're next). 
 The goal is to create a slippy map from zoom level 2 to 15(?) such that it's 
 easy to find the places in need of the most love.
 
 We have a osmium-genereated postigs database with all ways tagged as 
 highway=* and their version number. The plan to run the analysis against a 
 5x5 km grid, although we will probably play with the size of the gridcell. 
 Another option might be to conduct the analysis and varying levels of 
 granularity. 
 
 We're still consiering different methods of analysis - the goal being to 
 normalize way density to display better identify TIGER deserts. We'd would 
 love your thoughts / input / reactions. A few ideas we've tossed around / 
 are activley pursuing:
 
 - percent of version 1 and/or 2 ways in each gridcell
 - average number of version 1/2 ways per gridcell
 - using a threshold value(s) similiar to Martjin's approach
 - [your ideas here]
 
 Ultimately we'd like showcase the rendered results in site that would make 
 editing TIGER deserts easy. For now though this is just a heads up and an 
 invitation if you have any thoughts on how better to identify TIGER deserts. 
 
 thanks! 
 
 [1]: http://oegeo.wordpress.com/2012/10/21/binders-full-of-tiger-deserts/
 -- 
 ian villeda
 mapbox | developmentseed
 https://twitter.com/ian_villeda
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 
 michal migurski- contact info and pgp key:
 sf/cahttp://mike.teczno.com/contact.html
 
 
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

Absolutely, yeah.

I chose a raster approach to the data I was working with because I imagined it 
would be easiest to adapt to arbitrary jurisdictions, whether adopt-a-pixel or 
masked by a county boundary. Easy to track buckets of data over time that way, 
too.

-mike.

On Dec 7, 2012, at 10:38 AM, Martijn van Exel wrote:

 This would also fit in really well with the data steward notion. Part
 of the idea that we've been toying with for this is to have data
 dashboards for the stewarded areas to support targeted fixing /
 improving and to build a stronger local discussion and community
 around data  information  knowledge.
 
 On Fri, Dec 7, 2012 at 11:32 AM, Michal Migurski m...@teczno.com wrote:
 my intent for this is to produce county-by-county views that GIS managers in 
 different jurisdictions can use to understand whether their data is worth
 
 
 
 -- 
 Martijn van Exel
 http://oegeo.wordpress.com/
 http://openstreetmap.us/
 


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] identifying TIGER deserts

[Michal Migurski]

Thanks!

I agree about a regularly-updated map. For this one, I used the up-to-date 
osm2pgsql database that Ian Dees is maintaining on the OSM-US server we have 
living in Oregon, an awesome resource for USian OSM things. =)

I re-projected everything to spherical albers, and then iterated over every 
grid square in the raster and did a simple Postgres SUM(ST_Length) query for 
the roads in that area. The data was written out as a set of Float32 rasters, 
which I later combined with Numpy to make pretty pictures.

-mike.

On Dec 7, 2012, at 1:09 PM, Alex Barth wrote:

 Mike -
 
 AWESOME looking map and similar to what Ian and Ruben are working on. Would 
 you be open to share how you built that map? How hard (time consuming) is it 
 to regenerate?
 
 I'd love to get a regularly updated map out there showing TIGER deserts. We'd 
 use that ourselves to start fixing some of the worst areas in terms of 
 geographic accuracy. But obviously such a map would be a good thing to have 
 for the wider community.
 
 On Dec 7, 2012, at 1:32 PM, Michal Migurski m...@teczno.com wrote:
 
 That's great!
 
 I've been thinking about some of the same things, inspired by Dennis 
 Zielstra's talk at SOTM-US. I'm looking at road lengths for 1x1 kilometer 
 squares, measuring OSM user count (post-import) vs. possibility for 
 improvement between 2007 and 2012 TIGER/Line data:
 
  http://mike.teczno.com/img/osm-users-imports-2012-09.png
  - Blue means 2012 data would be an improvement
  - Red/Yellow means there are active OSM users there
 
 I used an Albers equal-area projection to ensure correct length and density 
 regardless of latitude, and my intent for this is to produce 
 county-by-county views that GIS managers in different jurisdictions can use 
 to understand whether their data is worth important, and what OSM users 
 they'd need to contact in order to be successful.
 
 I have a slippy map version of this but the projection registration is off 
 by a few hundred meters; need to figure out why that is and fix it.
 
 -mike.
 
 On Dec 7, 2012, at 10:00 AM, Ian Villeda wrote:
 
 
 Hey team, 
 
 Over here at MapBox we were inspired by Martjin's great post on identifying 
 TIGER deserts[1], so we're attempting to effectively identify TIGER deserts 
 for the rest of the continental U.S. (sorry Hawaii + Alaska, you're next). 
 The goal is to create a slippy map from zoom level 2 to 15(?) such that 
 it's easy to find the places in need of the most love.
 
 We have a osmium-genereated postigs database with all ways tagged as 
 highway=* and their version number. The plan to run the analysis against a 
 5x5 km grid, although we will probably play with the size of the gridcell. 
 Another option might be to conduct the analysis and varying levels of 
 granularity. 
 
 We're still consiering different methods of analysis - the goal being to 
 normalize way density to display better identify TIGER deserts. We'd would 
 love your thoughts / input / reactions. A few ideas we've tossed around / 
 are activley pursuing:
 
 - percent of version 1 and/or 2 ways in each gridcell
 - average number of version 1/2 ways per gridcell
 - using a threshold value(s) similiar to Martjin's approach
 - [your ideas here]
 
 Ultimately we'd like showcase the rendered results in site that would make 
 editing TIGER deserts easy. For now though this is just a heads up and an 
 invitation if you have any thoughts on how better to identify TIGER 
 deserts. 
 
 thanks! 
 
 [1]: http://oegeo.wordpress.com/2012/10/21/binders-full-of-tiger-deserts/
 -- 
 ian villeda
 mapbox | developmentseed
 https://twitter.com/ian_villeda
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 
 michal migurski- contact info and pgp key:
 sf/cahttp://mike.teczno.com/contact.html
 
 
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 Alex Barth
 http://twitter.com/lxbarth
 tel (+1) 202 250 3633
 
 
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] Walking papers down

[Michal Migurski]

Hi,

I gave the Walking Papers database a kick and it's back.

FYI, Field Papers was developed for a social science / crisis response client 
and is aimed at more general data collection needs vs. the Walking Papers focus 
on OSM exclusively. Both do multi-page atlases and both produce prints that are 
compatible with the other.

Walking Papers is still not processing uploaded images/scans correctly. Sorry 
about that - I've not been able to give it the attention it needs lately and 
Field Papers has been able to pick up some of the slack in the meantime. I'm 
embarrassed that this particular feature has been down, and I hope to nurse it 
back to health when I have finished up a stack of projects at the end of year.

-mike.

On Nov 19, 2012, at 7:34 AM, Jaakko Helleranta.com wrote:

 It's a bit different in a number of ways. I would summarize the difference 
 (based on checking both out some time ago, things may have changed) by saying 
 that:
 * Field Papers gives you space to write on
 * Walking Papers allows smoother printing of multi page prints (2x2, 4x4).
 Field papers seem to use the same system for scans, so those should work.
 
 I haven't checked Field Papers in detail, which might be why I like WP more. 
 I hope it comes back online.
 
 Btw. Also MapOSMatic has been down for a while. Anyone know how it might be 
 possible to help resurrect that?
 
 Cheers,
 -Jaakko
 
 On Nov 19, 2012 9:58 AM, Sébastien Pierrel sebastien.pier...@gmail.com 
 wrote:
 On 19 November 2012 16:41, hbogner hbog...@gmail.com wrote:
 On 19.11.2012. 15:31, Sébastien Pierrel wrote:
 Hi list,
 
 I've just noticed that the walking-papers website is down. Are the
 admins/maintainers aware of this? How to get in touch with them?
 
 
 Try http://fieldpapers.org/
 It's new wersion of walking papers.
 
  
 Thanks for the info.
 What's changed with the new version? Only a new name? Is it a completely new 
 instance where my accounts and prints from WP won't work?
 
 Cheers,
 Seb.
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] What to do with unnamed NHD streams

[Michal Migurski]

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.


 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?


 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!

-mike.


michal migurski- m...@stamen.com
 415.558.1610




___
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

[Michal Migurski]

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?

-mike.


michal migurski- m...@stamen.com
 415.558.1610




___
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

[Michal Migurski]

On Oct 29, 2012, at 12:49 AM, Paul Norman wrote:

 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.

This is a rough sketch for how the process could work on the NHD Areas file:
https://gist.github.com/3978487

It's fairly primitive, but the general idea is there. First I converted to an 
Albers projection, then snapped all the geometries to a 1-meter grid. Each 
polygon is looked at in turn, with all the joined streams used as a locations 
along the point path to create anchors for the simplification process. I'm not 
catching enough edge  corner cases for this to really work, yet, but the lines 
simplify down astonishingly well.

A likely better way to do this would be to more aggressively convert the NHD 
into a truly topological dataset, simplify *that*, and then reform all the 
polygons. 

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
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

[Michal Migurski]

On Oct 28, 2012, at 10:29 PM, Paul Norman wrote:

 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.

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.


 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.

Do you have any sample NHD extracts that might be usable for a test drive?

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations (attn: Richard Welty, etc.)

[Michal Migurski]

On Oct 24, 2012, at 5:01 PM, Chris Lawrence wrote:

 On Wed, Oct 24, 2012 at 12:28 PM, Michal Migurski m...@stamen.com wrote:
 
 
 NE2 asked me to revert the changes, because he's unhappy with me moving the 
 route variant information from the ref tags to the modifier tags, e.g. 
 turning ref=80 Business into ref=80 modifier=Business. According to the 
 supported tagging guidelines on Aperiodic, my interpretation should be 
 correct: The value of the ref tag on the relation must contain just the 
 route number, without any network information. 
 http://elrond.aperiodic.net/shields/supported.html
 
 ...
 
 As far as what to do from here... damned if I know.  I don't think
 anyone wants NE2 banned (he's a dedicated armchair mapper and
 contributes a lot to OSM, even if he's somewhat pigheaded in applying
 his own particular approaches in places where it's not as clear he has
 a lot of local knowledge), but at the same time he doesn't seem to be
 willing to concede on this point which IMO has become an obstacle to
 improving the map as-used by Skobbler, Mapbox, Stamen, Cloudmade,
 Mapquest etc downstream.  I guess my advice would be to proceed but be
 cautious of blowback.


That's what I've ultimately decided to do. I'm in semi-regular conversation 
with NE2 offlist, and while I'm happy with my own changes and stand by them, I 
also have no interest in an edit war or a situation where NE2's valuable 
contributions are put in jeopardy. If he feels strongly enough to revert them, 
I'd be okay with that.

I have no opinion on the network vs. modifier question, but I do believe that 
ref tags should be usable as-is in a renderer, so that's the direction my 
changes have taken. I'll let this all sit for a while, to see where it winds up 
in a few weeks.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] which boundaries are these?

[Michal Migurski]

On Oct 25, 2012, at 12:30 PM, Martijn van Exel wrote:

 Hi all,
 
 I want to do a more thorough look into TIGER ghost towns and am
 thinking about a town-by-town analysis. For that I need proper 'town'
 boundaries. I like the ones you get when you search for a place on
 Google Maps:
 
 https://maps.google.com/maps?q=princeton,+nj
 https://maps.google.com/maps?q=nederland,+co
 
 What are these boundaries? I am guessing it is some kind of Census division?


It's likely to be a Census place, non-continuous areas that can cross other 
boundaries are intended to represent logical towns and cities.

http://www2.census.gov/geo/tiger/TIGER2012/PLACE/

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [Talk-us] Scrubbing route relations (attn: Richard Welty, etc.)

[Michal Migurski]

On Oct 23, 2012, at 1:54 PM, Michal Migurski wrote:

 On Oct 21, 2012, at 8:54 PM, Michal Migurski wrote:
 
 I feel like this scrubbing process has revealed so much about the 
 intricacies of different road networks that I'm going to take a slightly 
 different approach, and focus my work on just the ref and modifier tags. I 
 can standardize the US:US and US:I networks along with US:CA where I live, 
 but I should hold off on attempting to overfit other states' network tags.
 
 
 Here's the newest:
   http://mike.teczno.com/img/OSM-Extracted-Routes-changes-2.csv.zip
 
 There are 5,828 changes now. I have left the network tags alone, generally. 
 Most changes are focused on the ref and modifier tags.

I'm looking for advice  feedback.

I applied these changes to OSM last night, in a series of five changesets:

http://www.openstreetmap.org/browse/changeset/13611326
http://www.openstreetmap.org/browse/changeset/13612265
http://www.openstreetmap.org/browse/changeset/13612825
http://www.openstreetmap.org/browse/changeset/13612736
http://www.openstreetmap.org/browse/changeset/13613023

Offlist, I've been talking to NE2 about the edits, and he pointed out this 
morning that they negatively affect shield rendering on Aperiodic:

http://elrond.aperiodic.net/shields/?zoom=15lat=38.7166lon=-77.79472layers=B

Whereas formerly relations with network=US:US and the modifier in the ref 
failed somewhat gracefully if a bit pigheadedly (by not displaying shields at 
all), they now show up incorrectly as mainline routes. - NE2

NE2 asked me to revert the changes, because he's unhappy with me moving the 
route variant information from the ref tags to the modifier tags, e.g. turning 
ref=80 Business into ref=80 modifier=Business. According to the supported 
tagging guidelines on Aperiodic, my interpretation should be correct: The 
value of the ref tag on the relation must contain just the route number, 
without any network information. 
http://elrond.aperiodic.net/shields/supported.html

I'm looking for guidance on this changeset, with the intent of making route 
relation information in the US internally consistent. I can simply revert it, 
but I wasn't happy with the state of relation tags before and I'll continue to 
look for ways to make them consistent nationally. I can apply a new changeset 
that moves or duplicates the variant information in the modifier tags to the 
ref tags, but this feels incorrect. I can apply an alternative changeset that 
moves or duplicates the variant information to the *network* tags (another 
recommendation from the Aperiodic tagging guideline), but previous 
conversations about this change led me to believe that messing with the network 
tags too much would be a Bad Idea.

For those of you with an interest in the route relations, what do you think is 
the correct next move here?

NE2, I've been talking to you offlist but I hope you jump in here.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations (attn: Richard Weait, etc.)

[Michal Migurski]

(Changing subject line to the Richard I originally meant)

That was my understanding as well, but I got feedback that boiled down to 
don't mess with the network tags (too much). What do others think about this?

-mike.

On Oct 24, 2012, at 12:16 PM, Dale Puch wrote:

 That is my understanding as well based on previous discussions.
 
 For For US Business route 80:
 network = US:US:Business
 ref = 80
 
 On Wed, Oct 24, 2012 at 2:13 PM, Alexander Jones happy5...@gmail.com wrote:
 Using your example, the network tag should say US:US:Business
 
 Alexander
 
 Michal Migurski wrote:
 
  On Oct 23, 2012, at 1:54 PM, Michal Migurski wrote:
 
  On Oct 21, 2012, at 8:54 PM, Michal Migurski wrote:
 
  I feel like this scrubbing process has revealed so much about the
  intricacies of different road networks that I'm going to take a slightly
  different approach, and focus my work on just the ref and modifier tags.
  I can standardize the US:US and US:I networks along with US:CA where I
  live, but I should hold off on attempting to overfit other states'
  network tags.
 
 
  Here's the newest:
  http://mike.teczno.com/img/OSM-Extracted-Routes-changes-2.csv.zip
 
  There are 5,828 changes now. I have left the network tags alone,
  generally. Most changes are focused on the ref and modifier tags.
 
  I'm looking for advice  feedback.
 
  I applied these changes to OSM last night, in a series of five changesets:
 
  http://www.openstreetmap.org/browse/changeset/13611326
  http://www.openstreetmap.org/browse/changeset/13612265
  http://www.openstreetmap.org/browse/changeset/13612825
  http://www.openstreetmap.org/browse/changeset/13612736
  http://www.openstreetmap.org/browse/changeset/13613023
 
  Offlist, I've been talking to NE2 about the edits, and he pointed out this
  morning that they negatively affect shield rendering on Aperiodic:
 
 http://elrond.aperiodic.net/shields/?zoom=15lat=38.7166lon=-77.79472layers=B
 
  Whereas formerly relations with network=US:US and the modifier in the ref
  failed somewhat gracefully if a bit pigheadedly (by not displaying shields
  at all), they now show up incorrectly as mainline routes. - NE2
 
  NE2 asked me to revert the changes, because he's unhappy with me moving
  the route variant information from the ref tags to the modifier tags, e.g.
  turning ref=80 Business into ref=80 modifier=Business. According to
  the supported tagging guidelines on Aperiodic, my interpretation should be
  correct: The value of the ref tag on the relation must contain just the
  route number, without any network information.
  http://elrond.aperiodic.net/shields/supported.html
 
  I'm looking for guidance on this changeset, with the intent of making
  route relation information in the US internally consistent. I can simply
  revert it, but I wasn't happy with the state of relation tags before and
  I'll continue to look for ways to make them consistent nationally. I can
  apply a new changeset that moves or duplicates the variant information in
  the modifier tags to the ref tags, but this feels incorrect. I can apply
  an alternative changeset that moves or duplicates the variant information
  to the *network* tags (another recommendation from the Aperiodic tagging
  guideline), but previous conversations about this change led me to believe
  that messing with the network tags too much would be a Bad Idea.
 
  For those of you with an interest in the route relations, what do you
  think is the correct next move here?
 
  NE2, I've been talking to you offlist but I hope you jump in here.
 
  -mike.
 
  
  michal migurski- m...@stamen.com
   415.558.1610
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 
 
 -- 
 Dale Puch
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations

[Michal Migurski]

On Oct 21, 2012, at 8:54 PM, Michal Migurski wrote:

 I feel like this scrubbing process has revealed so much about the intricacies 
 of different road networks that I'm going to take a slightly different 
 approach, and focus my work on just the ref and modifier tags. I can 
 standardize the US:US and US:I networks along with US:CA where I live, but I 
 should hold off on attempting to overfit other states' network tags.


Here's the newest:
http://mike.teczno.com/img/OSM-Extracted-Routes-changes-2.csv.zip

There are 5,828 changes now. I have left the network tags alone, generally. 
Most changes are focused on the ref and modifier tags.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations

[Michal Migurski]

On Oct 22, 2012, at 8:00 AM, Paul Johnson wrote:

 
 On Oct 22, 2012 9:57 AM, Alexander Jones happy5...@gmail.com wrote:
 
  Paul Johnson wrote:
 
   FM and RM are the same network...seems odd for them to show up twice
   here...
 
  I could've sworn that the general consensus from a previous argument was
  one network per shield type.
 
 They use the same shield, and even TXDOT signs Farm Road and Ranch Road 
 interchangeably.  They're definitely the same network.

Should they both be classified under the :FM network, if that's the case?

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] press from SOTM US

[Michal Migurski]

On Oct 22, 2012, at 1:12 PM, Alex Barth wrote:

 The data extracted by geocoding should just not lead to a substantial extract 
 of the database, hence not producing a derivative database in the sense of 
 the ODbL. I feel this would be within the spirit of why the ODbL was adopted 
 (to encourage contribution) while clarifying an important use of OSM data 
 that would create a huge incentive to improve data. Right now we largely 
 don't have functioning municipal boundaries in OSM. Obviously, any data that 
 is mixed into OSM data for _powering_ the geocoder would fall under share 
 alike stipulations.

MySociety is working on derived municipal boundaries from OSM data:
http://global.mapit.mysociety.org/

E.g.:
http://global.mapit.mysociety.org/area/168844.html

There's data in there, and code out there that you could build on. The MapIt 
service itself is non-commercial, but the code that drives it is 
freely-available.
http://code.mapit.mysociety.org/


 You bring up the important problem of properly bounding the geocoding case. 
 I'm thinking if all that can be extracted from OSM's database are names and 
 addresses for lat/lon pairs or lat/lon pairs for names or addresses, it would 
 be arguably impossible or at least impractically hard to recreate a 
 functioning street network from it and the extracted data would be a narrow 
 subset of OSM no matter how many locations are being geocoded. Thoughts?


This seems to match the spirit of the license as far as I understand it.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations

[Michal Migurski]

On Oct 21, 2012, at 5:28 AM, Minh Nguyen wrote:

 On 2012-10-20 4:00 PM, Michal Migurski wrote:
  - Normalizing network names for all county routes with the :CR infix
 
 I'm not enthusiastic about sticking `:CR` in all the county route relations. 
 I favor `US:[state]:[county]`, at least for the relations in Ohio, for the 
 same reason we have `US:[state]` rather than `US:SR:[state]`. It doesn't look 
 like you touched any Ohio county routes, but that's probably because you 
 didn't realize that's what they are. :-)
 
 Ohio county route relations' `network`s conform to a simple pattern: 
 `US:OH:[ABC]`, where [ABC] is the county's three-letter, all-caps ODOT code. 
 Obviously, the codes aren't used as commonly as USPS state abbreviations, but 
 many counties use them on signage, and they're quite handy for this purpose.

That's right, I didn't understand those and they didn't look like county names, 
so I left them alone. The nice thing about the :CR part is that it helps 
explain what the word is after, for example county names. There are only 50 
states so it seems easier to just say US:[state], but there are loads more 
counties and it's impractical to remember them all on sight.


 Having the extra `:CR` component might make sense in states like New Jersey 
 and California that have consistent, statewide county route standards. But in 
 Ohio, most counties that signpost their routes do it in different ways, in 
 violation of the state MUTCD. There are so many variations that entire 
 websites [1] are devoted to documenting them. (And as you'd imagine, some 
 townships have their own unique route shields, too.)

That's interesting and worth knowing, thanks.


 You mentioned that using `:CR` makes it possible to correctly interpret 
 county routes without knowing the county names. I guess that depends on what 
 we expect the relations to be used for. To a developer generating shields for 
 display on a map, `:CR` would suggest standardizing on, say, the blue and 
 gold pentagonal shield, when in fact that would be misleading in maybe 
 three-quarters of the state. And I'd say the shields are the /only/ 
 interesting thing about Ohio county routes.
 
 By the way, if anyone's interested in rendering these shields, I've started a 
 collection of SVG templates at Wikimedia Commons [2]. One thing I learned 
 while making these templates is that some counties include the township name 
 in their county route shields. Presumably, a route that crosses township 
 lines would have more than one shield variant. Should we have subrelations 
 with the township name in `modifier`?


The blue and gold shields are used in many places around the country, right? I 
think you're right, that using :CR where those are in place would make a lot 
of sense.

I feel like this scrubbing process has revealed so much about the intricacies 
of different road networks that I'm going to take a slightly different 
approach, and focus my work on just the ref and modifier tags. I can 
standardize the US:US and US:I networks along with US:CA where I live, but I 
should hold off on attempting to overfit other states' network tags.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] SOTM-US geocoding/share-alike discussion

[Michal Migurski]

I'm not on legal-talk, so this mail is going out only to Talk-US. I'm happy to 
have it forwarded.

We had a license BoF organized primarily by Mapbox (Eric Gunderson and Alex 
Barth) with participation from Foursquare (David Blackman), on the topic of the 
license and its effect on geocoding data. Steve C, Henk Hoff, Paul Norman, 
Richard Fairhurst and many others attended. My understanding of Mapbox's issue, 
paraphrased, is that they have potential clients with lawyers scared of the 
ODbL and license status of latitude and longitudes returned from addresses 
geocoded against OSM.

As I understood it, the end result of the discussion was that the ODbL may or 
may not apply in this case and that Mapbox should submit some specific uses 
cases to the board to illustrate their specific concern so we can all stop 
blathering about whether the license is good or bad and move on to useful 
particulars.

In other words, what the 20120522 LWG meeting notes say.

-mike.

On Oct 21, 2012, at 1:58 AM, Frederik Ramm wrote:

 Hi,
 
   on talk-us there was a mention of Carl Frantzen's recent three-part
 article with SOTM-US coverage, 
 http://idealab.talkingpointsmemo.com/2012/10/openstreetmap-part-1-new-cartographers.php,
 and his mention of OSM moving away from his open-source roots.
 
 Apparently, this refers to some unfortunate statements at SOTM-US about
 share-alike being bad for business or something, and Frantzen mentions
 that a couple of businesses have set up an informal group to discuss
 which bits of our license they don't understand or want clarification
 on. As far as I know, nobody who knows anything about OSM seriously
 suggested that we move away from open source, it was just a phrase
 unfortunately reported.
 
 I am still rather surprised to hear about this as a side note of SOTM-US
 coverage instead of here on this list where license discussions should
 be at home. I would urge anyone who is unclear about anything with ODbL
 and/or who believes that any community norms we have must be refined, to
 discuss that here on this mailing list - whether it's for business or
 personal use.
 
 Looking through past discussions in the archives of minutes of our
 Licensing Working Group, it seems clear to me that OSM data under ODbL
 is unlikely to ever be available for no strings attached geocoding; we
 won't ask for your customer database just because you geocode with OSM,
 but you will have to adhere to some rules nonetheless.
 
 LWG has never actually made a decision on geocoding, and all mentions in
 their minutes carry big disclaimers (This is a summary of our
 discussion and should NOT be construed as a formal statement of
 position). Under that disclaimer, the 20120515 minutes contain the
 following:
 
 To be able to claim that the remainder of the record, (often
 proprietary business information or personal information such as a
 patient record) is not virally touched by geocoding against OSM ODbL
 data needs a distinction to be demonstrated. This distinction needs
 to be a clear and logical general rule or principle. It also needs to
 be acceptable to the OSM community. At the moment, we feel this does
 not exist.
 
 In the same notes there's a discussion of a like with like principle
 which means that Whatever is used in the (reverse)geocoding look-up is
 virally touched, but nothing else.
 
 The 20120522 meeting notes contain a link to a concept paper
 
 https://docs.google.com/document/pub?id=1Ag81OlT1TtnhYwVE-bBtL018SNoU_V-anG4wLdwMT4c
 
 and explicitly say: To improve it, and test the rationality of the
 ideas expressed, we need and welcome real-world cases of geocoding and
 reverse-geocoding.
 
 So I guess anyone who wants to use OSM in a geocoding scenario should
 read that and submit their opinion, here or to LWG.
 
 Personally, I've gone on record as an advocate of a non-share-alike (PD) 
 license for OSM but the project as a whole has decided to have a share-alike 
 license and I accept that; I don't think that geocode as much as you want 
 without sharing any data is possible with the ODbL data set.
 
 Bye
 Frederik
 
 -- 
 Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations

[Michal Migurski]

I did not know about the Aperiodic site, very cool!

It sounds from the advice there that I should use a different strategy with the 
network tags, and duplicate the Loop, Business and other modifiers to that 
tag.

-mike.

On Oct 19, 2012, at 11:26 PM, Chris Lawrence wrote:

 My only concern with the scrubbing applies to bannered routes (routes
 with the modifier tag); we've been going back and forth on the
 proper tagging for seemingly years now, and while I think the proposed
 scrubbing conforms with the original intent under the tagging scheme,
 the generally agreed-upon (by everyone except NE2, at least) tagging
 seems to be as documented at:
 http://elrond.aperiodic.net/shields/supported.html
 
 The rendering expects data tagged according to the documentation on
 the wiki and further refined based on discussions on the talk-us
 mailing list. In particular, two things are worth knowing:
 
 * The value of the ref tag on the relation must contain just the
 route number, without any network information. The relation for
 Interstate 5 should be tagged with network=US:I, ref=5.
 * Variant routes (alternate, business, truck, etc.) must be tagged
 with the variant in the network tag, not the ref tag. (The variant
 text should also be in the modifier tag, but this rendering does not
 depend on its presence there.) Thus, US Alternate Route 1 would only
 be rendered if it were tagged network=US:US:Alternate, ref=1.
 
 Since this site (http://elrond.aperiodic.net/shields/) seems to be the
 only real consumer of route relations at the moment (we're not sure if
 Mapquest Open is or whether it's just running a bunch of ad-hoc data
 fixups to make its shields sensible), I think it makes sense to follow
 the guidance from that site at least as far as deprecating modifier
 in favor of making variants part of the network tag.
 
 However, the CR tagging changes suggested here seem fine to me.
 
 
 Chris
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations

[Michal Migurski]

Based on feedback from route relation mappers and people on this list, here's a 
list of 7,575 route relation changes I'd like to make:

http://mike.teczno.com/img/OSM-Extracted-Routes-changes.csv.zip

Some of the rules I've followed:
- Shortening ref tags to just what goes on a shield, with prefixes and 
suffixes moved to the network and modifier tags
- Treating Business as a special subnetwork, e.g. US:I:Business vs. 
US:I
- Normalizing network names for all county routes with the :CR infix
- Title-case and spaces for wordy networks

If there aren't any objections, I'd like to start applying these to the OSM 
database this upcoming week.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations

[Michal Migurski]

On Oct 20, 2012, at 4:43 PM, Paul Norman wrote:

 From: Michal Migurski [mailto:m...@stamen.com]
 Sent: Saturday, October 20, 2012 4:01 PM
 To: OpenStreetMap U.S.
 Subject: Re: [Talk-us] Scrubbing route relations
 
 Based on feedback from route relation mappers and people on this list,
 here's a list of 7,575 route relation changes I'd like to make:
 
  http://mike.teczno.com/img/OSM-Extracted-Routes-changes.csv.zip
 
 Some of the rules I've followed:
  - Shortening ref tags to just what goes on a shield, with prefixes
 and suffixes moved to the network and modifier tags
 
 Perhaps I'm misunderstanding, but some of the lines seem to indicate the
 reverse.
 
 Line 3030, id=301986 seems to describe a change from network=US:I:Business
 to network=US:I and ref=69 to ref=69 Business.

It's the opposite, looks like I misnamed the columns. I've posted a new version 
of the doc with the correct column names to the same address, thanks for 
noticing!


 Looking at id=172892 and id=1745481 is also confusing. They're both truck
 routes, but one gets Truck in the ref and the other doesn't?

They both get Truck removed (see above with the switched column names).

The change would be from these:
network=US:OH:Truck,ref=38, modifier=Truck
network=US:AL,  ref=47 Truck,   modifier=

…to these:
network=US:OH,  ref=38, modifier=Truck
network=US:AL,  ref=47, modifier=Truck


 You might want to seek out the top few editors of relations who aren't on
 the list and point them at
 http://lists.openstreetmap.org/pipermail/talk-us/2012-October/009253.html
 and invite them to join in.


I've been in touch with them via messages on the OSM.org site, not sure how 
many are subscribers here.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations

[Michal Migurski]

On Oct 18, 2012, at 10:08 PM, Toby Murray wrote:

 On Thu, Oct 18, 2012 at 6:26 PM, Michal Migurski m...@stamen.com wrote:
 Hi everyone,
 
 We're getting ready to do a major data update to the Stamen Terrain layer 
 and I've been working on scrubbing the route relations data from OSM. I've 
 linked to a before and after CSV, processed via Google Refine to normalize 
 networks, refs and modifiers.
 
 I'm curious to get some feedback on it:
http://mike.teczno.com/img/osm-scrubbed-routes-2012-09.zip
 
 The associated code:
https://gist.github.com/3915267
 
 Reviewing a diff, I see pretty much all of the relations I have
 created are unchanged soo... looks great! :)
 
 More seriously, I do like the idea of having the county name in there
 for county roads. But I haven't done any county routes myself yet so
 my opinions are not particularly strong.
 
 Looking at the diff visually I see a lot of either moving modifiers to
 their own tag or removing the duplicated modifier from the network
 tag. I guess the question there is, should the various loops,
 bypasses, truck routes, etc be considered as part of the same network
 as the unmodified highway. For example if I do a tag query for
 network=US:I and ref=376, should it return the business route as well
 as the base US 376 route?

My understanding of the modifier tag is that the ref should be the content of 
the main part of the shield, and the modifier goes above e.g. these shields:

http://en.wikipedia.org/wiki/List_of_business_routes_of_the_Interstate_Highway_System

I'm not well versed enough in these to really get what the ref should contain, 
but it seems logical to me that it would be short and sweet like an actual sign 
on the side of a road.

I've posted a new version of everything at the URL's above, with corrected 
county network names.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] Scrubbing route relations

[Michal Migurski]

Hi Richard, thanks!

The CR vs. County name thing is new to me. Another mapper suggested that I 
replace them with something like this so it's not necessary to know all the 
county names in order to correctly interpret something as a county route:

network=US:NY:CR:Rensselaer

Kosher?

-mike.

On Oct 18, 2012, at 5:16 PM, Richard Welty wrote:

 the scrubbing looks mostly ok, BUT...
 
 i am one of the folks who started out using US:state:CR for county route 
 networks, which i now believe was
 a mistake. we really should be using county names, not CR in the network tag, 
 e.g.
 
 network=US:NY:Rensselaer
 
 otherwise we can't really tell which county the route is in, and can't 
 distinguish CR 1 in Columbia County from CR 1 in
 Rensselaer County.
 
 richard
 
 On 10/18/12 7:26 PM, Michal Migurski wrote:
 Hi everyone,
 
 We're getting ready to do a major data update to the Stamen Terrain layer 
 and I've been working on scrubbing the route relations data from OSM. I've 
 linked to a before and after CSV, processed via Google Refine to normalize 
 networks, refs and modifiers.
 
 I'm curious to get some feedback on it:
  http://mike.teczno.com/img/osm-scrubbed-routes-2012-09.zip
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [OSM-talk] Osmosis heap space, tuning not working

[Michal Migurski]

On Oct 6, 2012, at 4:05 PM, Michal Migurski wrote:

 On Oct 6, 2012, at 3:44 PM, Frederik Ramm wrote:
 
 If you write it this way, the 2nd line cancels out the 1st. You need to write
 
 JAVACMD_OPTIONS=-server -Xmx16G
 
 - if your two lines had been the other way round then that would likely been 
 the cause of the problem, however since in your setting it is the -server 
 that is cancelled out, this likely won't help much ;(
 
 
 I get it, they replace instead of append. Thanks Frederick, I'll try it out!
 
 (settles in for a few-hour wait)


So, I'm still getting heap space failures right at the end of the read process 
when the relations have been parsed. I've switched to EC2 for the time being 
and tried a variety of settings for the -Xmx option, from 14G on a 16G system 
to just 2G.

My command as before looks like this:

osmosis \
--rb planet-121003.osm.pbf \
--log-progress \
--tf accept-ways 'highway=*' --tf accept-relations 'network=*' 
--used-node \
--tp user=osm da tabase=osm \
--wp user=osm database=osm

It takes about 3-5 hours each time to get it to fail. Is there a better way for 
me to be debugging this? My current ~/.osmosis file looks like this:

JAVACMD_OPTIONS='-server -Xmx8G -Djava.io.tmpdir=/mnt/planet/tmp'

What am I missing here?

-mike.


michal migurski- m...@stamen.com
 415.558.1610




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Osmosis heap space, tuning not working

[Michal Migurski]

I'm running Osmosis on a complete recent planet, and seeing memory errors.

My ~/.osmosis file looks like this:

JAVACMD_OPTIONS=-server
JAVACMD_OPTIONS=-Xmx16G

…based on advice from http://wiki.openstreetmap.org/wiki/Osmosis/Tuning. 16GB 
is half the RAM in this 64 bit machine.

Here's the error where it blows up:

SEVERE: Thread for task 1-rb failed
java.lang.OutOfMemoryError: Java heap space

This is the command I'm running:

osmosis --rb planet-120920.osm.pbf \
--log-progress --tf accept-ways 'highway=*' --tf 
accept-relations 'network=*' --used-node \
--tp user=osm database=planet_osm \
--wp user=osm database=planet_osm

According to the progress log I get all the way through the relations before it 
fails. There's not other giant processes running. What is going on?

-mike.


michal migurski- m...@stamen.com
 415.558.1610




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Osmosis heap space, tuning not working

[Michal Migurski]

On Oct 6, 2012, at 3:44 PM, Frederik Ramm wrote:

 Hi,
 
 On 06.10.2012 23:00, Michal Migurski wrote:
 I'm running Osmosis on a complete recent planet, and seeing memory errors.
 
 My ~/.osmosis file looks like this:
 
  JAVACMD_OPTIONS=-server
  JAVACMD_OPTIONS=-Xmx16G
 
 If you write it this way, the 2nd line cancels out the 1st. You need to write
 
 JAVACMD_OPTIONS=-server -Xmx16G
 
 - if your two lines had been the other way round then that would likely been 
 the cause of the problem, however since in your setting it is the -server 
 that is cancelled out, this likely won't help much ;(


I get it, they replace instead of append. Thanks Frederick, I'll try it out!

(settles in for a few-hour wait)

-mike.


michal migurski- m...@stamen.com
 415.558.1610




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSMCoastline / OpenStreetMapData.com

[Michal Migurski]

On May 23, 2012, at 2:28 AM, Jochen Topf wrote:

 Because not everybody has a planet file lying around and because the software
 with all its options is still not so easy to use, I have created a new
 service at OpenStreetMapData.com where you can download the files created
 by OSMCoastline. The data is updated daily.


Water polygons!

That's fantastic, thank you!

-mike.


michal migurski- m...@stamen.com
 415.558.1610




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Network tag Re: Highway Shield Rendering

[Michal Migurski]

On Apr 8, 2012, at 7:49 AM, Nathan Edgars II wrote:

 On 4/8/2012 10:27 AM, Craig Hinners wrote:
 Chris Lawrencelordsu...@gmail.com:
 modifier=* would represent MUTCD-type banners attached to the shield
 
 This is the first I've heard of this tag. I don't recall it being
 discussed when we were hashing ideas around on this last summer. (Not
 that that is reason to discount it.)
 
 But what came out of that discussion was the following guidance: ref
 will store the unique identifier within a particular classification,
 where particular classification is stored wholly in the network tag.
 
 So, network=US:US:Business/ref=13 and network=US:US:Truck/ref=70
 both conform to that definition.
 network=US:US/modifier=Business/ref=13 does not.
 
 On the other hand, network=US:US ref=13 Business does.


For what it's worth, as a renderer I preferred the modifier tag when doing 
the Terrain shields:
http://maps.stamen.com/terrain/#13/34.0510/-118.2146

Modifiers in the ref tag would be a close second; those typically need a lot of 
scrubbing and normalization anyway.

In the network tag would be the biggest hassle of all.

I'm working on a revision to the Terrain tiles, by the way, and I'm curious if 
I got anything obviously wrong with the highways that I should look at fixing. 
One thing I'll be attempting is to get the shields to behave a little less 
sloppily as they meander along routes, probably by staggering them more.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [OSM-talk] No Data overlay on OpenStreetmap.org

[Michal Migurski]

On Apr 1, 2012, at 3:56 PM, Richard Weait wrote:

 On Sun, Apr 1, 2012 at 4:46 PM, Toby Murray toby.mur...@gmail.com wrote:
 It moved to the Edit tab. Hover over the edit tab with your mouse
 (don't click) and a menu will pop up with the data layer option. IMO
 it should be moved back to the layer selection. Hovering over the edit
 tab is about as unintuitive as it gets.
 
 iirc from the commit logs, the edit tab is a temporary place for the
 data layer link as part of the ongoing site improvements.


I hope so, because that's a ridiculous place for the data overlay to go. The 
hover action on the edit tab is bad enough as it is.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Metro Extracts archived version (was: Geofabrik downloads post-licence-change)

[Michal Migurski]

On the subject of license change planning, I'm in the process of archiving a 
current version of http://metro.teczno.com to the Internet Archive, a 
non-profit whose mission explicitly calls for the preservation of cultural 
artifacts:

…without cultural artifacts, civilization has no memory and no 
mechanism to learn from its successes and failures. And paradoxically, with the 
explosion of the Internet, we live in what Danny Hillis has referred to as our 
digital dark age. The Internet Archive is working to prevent the Internet - a 
new medium with major historical significance - and other born-digital 
materials from disappearing into the past. (http://archive.org/about/about.php)

I expect the uploading to take another day or more, with the final archive 
appearing here:

http://archive.org/download/metro.teczno.com/
http://archive.org/details/metro.teczno.com

It's partially available now. I'm also including a complete copy of the OSM 
planet file as of March 14th, the version I used to generate the extracts above.

-mike.

On Mar 22, 2012, at 11:56 PM, Frederik Ramm wrote:

 Hi,
 
   this is a small heads-up to users of the Geofabrik downloads from 
 download.geofabrik.de.
 
 After the OSM license change is complete and the first ODbL planet is 
 published, it will take another day or so to generate the first round of 
 extracts and shape files, and daily production will then resume normally, 
 with all extracts published under ODbL.
 
 However, to avoid people downloading the new, differently-licensed extracts 
 without knowing, we will change the download URL (most likely from /osm/... 
 to /openstreetmap/...). The last version of the CC-BY-SA extracts will 
 remain, un-updated, under /osm for a while, and then we will make  /osm point 
 to a big url has changed page.
 
 There will be no automatic redirects.
 
 Bye
 Frederik
 
 -- 
 Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 


michal migurski- m...@stamen.com
 415.558.1610




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Lightning fast car routing built on OpenStreetMap data, with draggable routes

[Michal Migurski]

On Mar 16, 2012, at 4:33 PM, Jean-Marc Liotier wrote:

 Spotted in @openstreetmap's Twitter feed... I don't remember having ever
 used a routing service that fast. It is apparently tuned for car
 routing... And that's all I can say since the Karlsruher Institut für
 Technologie whose homepage is linked from the results panel doesn't seem
 to say anything about it. If anyone has further information about this
 exciting service...


Doesn't seem to work at all in the US - I'm getting routing failures between SF 
and LA when I drag the pins over, and the place search boxes modify my queries 
after I make them. San Francisco becomes Santa Rafaela María, Pedro Abad, Los 
Angeles Carretera Villaviciosa - Arganda, San Martín de la Vega.

-mike.


michal migurski- m...@stamen.com
 415.558.1610




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk