[Talk-us] GNIS POI populations

[stevea]

What a fantastic set of discussions we now enjoy here.  Thank you 
Minh and all who contribute.

I essentially agree with every bit of good sense I see in this 
Digest's current era (circa Vol 86, Issue 23):

A way to bot-update (partly, part "smart manual," too) something as 
basic / sensible as cities, towns, suburbs and so on with population 
data (and font-sized renderings...) in our complex data fifty united 
states adds welcome "street cred" to our project.  We have CDPs (with 
and without centroids) we have population entries (thanks, Kristen 
and team!) where we didn't before, we have fresh public numbers every 
decade thanks to our Constitution.  We have moved to harmonize these 
in these talk pages, too, and this shows in histories of our project 
-- this is obvious from the great bridges and roadway we have built. 
Part of this includes documenting how a set of tags achieves a 
specific rendering with commonly used render engines.

I like Serge's idea of incorporating all of these ideas.  These are 
short-to-describe tasks (describing them WELL with AGREEMENT might be 
difficult) and then there is the "accept ownership" aspect (I or a 
team) then takes on.  No doubt, this is some of the hardest work we 
do:  good ideas achieving goal.  OSM being decennial puts us on track 
to being ready for our (the USA's) next decennial census, yes?

But:  good ideas that die because they don't match up with folks to 
do them (well)?  That would be a shame.

Who is for spinning up a skeletal WikiProject page ("US_Cities and 
Census" or somesuch)?  That makes it a wider community essentially 
automagically.  There is nothing like a WikiProject page to instruct, 
achieve and report status (I say from personal experience):  OSM has 
many successful examples.  (Minh was here, too!)

There are some aspects of editing OSM well where JOSM is a superior 
editor compared to iD or Potlatch.  Let's not kid ourselves about 
that.  iD (and Potlatch?) have their place, complex relation editing 
probably isn't a good overlap.  There are clever (and not-so-clever) 
upload scripts, too, but beware hair trigger paint buckets all over 
the map:  Serge is correct to apply quality with manual editing. 
Now, manual editing CAN enter truly high quality data.  However, it 
is manual, and takes time and effort.  This is a balance we juggle.

Shortly said:  keeping or tossing historical objects is a serious 
conversation about semantics and rendering rules.  That said, we see 
what we are doing, especially when spec'd well up front.  Let's spec 
well up front.  (Saying what we mean with semantics of syntax/tagging 
standards, rendering them in reasonable tile time spans, et cetera). 
This works, though takes time, as it is complex to build.  Sausage 
recipes, anybody?  We have those and they keep getting better, too. 
However, volunteer chefs to bake a great map?  Step right up!

(A bit of "want to help," a bit of "project leadership," a bit of 
"technical geekery where required..." we know how to do this).  I 
like the way our map grows; OSM is a great project.

OSM is a feedback loop that looks at itself and looks to improve.  On 
talk-us, we have fifty states, and (tens of, hundreds of?) thousands 
of people who look and care and volunteer.  In OSM, we have millions 
of people looking and caring.  I won't be surprised as that surpasses 
billions (though my measurements are fuzzy, I admit, so in some sense 
it may already be trillions, too).  Lots of people like and use our 
map.  Let's continue to make it as awesome as possible with 
continuing execution of sensible projects.

SteveA
California