Re: [Talk-us] Salt Fork Lake rendering issue

[David ``Smith'']

On Tue, Oct 13, 2009 at 12:05 PM, Apollinaris Schoell
 wrote:
>>> On Mon, Oct 12, 2009 at 4:56 PM, Apollinaris Schoell 
>>> wrote:

 Just a guess. landuse=reservoir overrules natural water.
>>
>> I don't think that's the issue.  For one thing, Quabbin renders fine
>> in Mapnik, but poorly in Osmarender.  For Salt Fork Lake, the opposite
>> is true.  So they are two unrelated problems.  For another thing, all
>> of the relevant wiki pages seem to indicate that landuse=reservoir is
>> just as valid as natural=water for this type of feature.  (What kind
>> of "protected area" was tagged as landuse=reservoir in the MassGIS
>> import?  Unless those areas protect water, that tagging is wrong.)
>> Besides, I've done numerous smaller bodies of water which are both
>> landuse=reservoir and natural=water, as multipolygons and as single
>> ways, and this is the only one causing problems.
>>
>
> why don't you try it instead of wild guess?
> the rendering doesn't care what's in the wiki. the wiki can be completely
> wrong. check the rendering style and you will know for sure.
> for the tags itself landuse on a lake? doesn't make any sense to me.

Who's guessing here? I'll quote you again, "> Just a guess.
landuse=reservoir overrules natural water."  My hypothesis is based on
the experience of tagging several reservoirs exactly like this without
any problems.  The only difference is that this one involves a greater
number of nodes and took several minutes to upload.

Anyway, the tags are correct.  It's a lake, so it's tagged
natural=water.  It's a reservoir -- an area of land (territory) used
to store water -- so it's tagged landuse=reservoir.  The wiki page for
each tag indicates that the tag is correct for the situation, and I
don't see a problem with redundant tagging.  If the renderer gets it
wrong because of the way it's tagged, then the renderer needs to be
fixed, not the tags.  But I'm confident that that's not even the
problem here.

-- 
David "Smith"
a.k.a. Vid the Kid
a.k.a. Bír'd'in

Does this font make me look fat?

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

Re: [Talk-us] [OSM-talk] TIGER Addressing Import

[Apollinaris Schoell]

On 13 Oct 2009, at 9:20 , SteveC wrote:

> Dave - super awesome.
>
> As I said on IRC the other week, but I'll repeat here for all - I
> think dumping the addressing for all 3,000 counties and then letting
> people import them one by one will be the best way to do it.
>

yes this is the best way to get as many mappers as possible involved.  
check for errors ...

> Another random thought - should the addressing ways be one long way
> with two nodes per block, or lots of two node ways? My immediate
> preference is for the former...?
>
> Also - the ways will be deplaced 90 degress to the road centerline to
> push them to the edge of the road I assume - but you also need to
> 'pull in' the end nodes too so they are not laying on top of the cross
> streets at each end, if you see what I mean?
>
> Yours &c.
>
> Steve
>
>
> On 3 Oct 2009, at 09:13, Dave Hansen wrote:
>> Is this the most up to date way of keeping addresses?
>>
>>  
>> http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema
>>
>> Well, I have some perl code that will parse the 2007/2008 TIGER data
>> files.  My goal is to get the addresses imported into OSM this time
>> around.  Here's some ugly sample output of what I have now.
>>
>>  http://sr71.net/~dave/osm/tiger/sherman.osm
>>
>> I don't need any suggestions on it, I just wanted to show people
>> what I
>> have so far.
>>
>> Issues:
>> * I currently have the way combination code turned off.  This means
>> that
>> OSM ways are represented 1:1 with the TIGER TLIDs.
>> * Some multi-segment TIGER roads have only a single address range.
>> Do we create segments for each road segment and evenly divide the
>> addresses?  Or, do we draw a single address segment going from the
>> first to last node?
>>
>> And, yes, I saw the 2009 data come out.  I'll make sure my code works
>> with it.
>>
>> -- Dave
>>
>>
>> ___
>> talk mailing list
>> t...@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk
>>
>
>
> ___
> 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] [OSM-talk] TIGER Addressing Import

[SteveC]

On 13 Oct 2009, at 09:26, Simone Cortesi wrote:

> On Tue, Oct 13, 2009 at 18:20, SteveC  wrote:
>> As I said on IRC the other week, but I'll repeat here for all - I
>> think dumping the addressing for all 3,000 counties and then letting
>> people import them one by one will be the best way to do it.
>
> dont you think we need a simple way to check-in & check-out files from
> such a big effort?

maybe... but right now the blocker is dave having enough time... I  
suggest we guilt trip him by buying him things off his amazon wishlist  
or something :-)

> something that will enable people to interact with the files.
>
> something visual as this http://osm.m0nty.de/ used in bayern for the
> aerial images?
>
> or am am I too old to be able to think about complex wiki pages?

yeah I get the point, but I'd prefer to cross the first hurdle, which  
is having some files to look at

Yours &c.

Steve


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

Re: [Talk-us] [OSM-talk] TIGER Addressing Import

[SteveC]

Dave - super awesome.

As I said on IRC the other week, but I'll repeat here for all - I  
think dumping the addressing for all 3,000 counties and then letting  
people import them one by one will be the best way to do it.

Another random thought - should the addressing ways be one long way  
with two nodes per block, or lots of two node ways? My immediate  
preference is for the former...?

Also - the ways will be deplaced 90 degress to the road centerline to  
push them to the edge of the road I assume - but you also need to  
'pull in' the end nodes too so they are not laying on top of the cross  
streets at each end, if you see what I mean?

Yours &c.

Steve


On 3 Oct 2009, at 09:13, Dave Hansen wrote:
> Is this the most up to date way of keeping addresses?
>
>   
> http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema
>
> Well, I have some perl code that will parse the 2007/2008 TIGER data
> files.  My goal is to get the addresses imported into OSM this time
> around.  Here's some ugly sample output of what I have now.
>
>   http://sr71.net/~dave/osm/tiger/sherman.osm
>
> I don't need any suggestions on it, I just wanted to show people  
> what I
> have so far.
>
> Issues:
> * I currently have the way combination code turned off.  This means  
> that
>  OSM ways are represented 1:1 with the TIGER TLIDs.
> * Some multi-segment TIGER roads have only a single address range.
>  Do we create segments for each road segment and evenly divide the
>  addresses?  Or, do we draw a single address segment going from the
>  first to last node?
>
> And, yes, I saw the 2009 data come out.  I'll make sure my code works
> with it.
>
> -- Dave
>
>
> ___
> talk mailing list
> t...@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>


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

Re: [Talk-us] Salt Fork Lake rendering issue

[Apollinaris Schoell]

On 13 Oct 2009, at 2:03 , David ``Smith'' wrote:

> On Mon, Oct 12, 2009 at 8:24 PM, Seth Fitzsimmons   
> wrote:
>> That looks likely.  Quabbin Reservoir (Western MA) is also rendering
>> similarly: 
>> http://www.openstreetmap.org/?lat=42.3749&lon=-72.2847&zoom=12&layers=0B00FTF
>>
>> Last I checked, landuse=reservoir is being rendered like  
>> natural=water
>> even though it shouldn't be.  With the MassGIS OpenSpace import, lots
>> of landuse=reservoir polys were imported and represent "protected
>> areas", not water.
>>
>> seth
>>
>> On Mon, Oct 12, 2009 at 4:56 PM, Apollinaris Schoell > > wrote:
>>> Just a guess. landuse=reservoir overrules natural water.
>
> I don't think that's the issue.  For one thing, Quabbin renders fine
> in Mapnik, but poorly in Osmarender.  For Salt Fork Lake, the opposite
> is true.  So they are two unrelated problems.  For another thing, all
> of the relevant wiki pages seem to indicate that landuse=reservoir is
> just as valid as natural=water for this type of feature.  (What kind
> of "protected area" was tagged as landuse=reservoir in the MassGIS
> import?  Unless those areas protect water, that tagging is wrong.)
> Besides, I've done numerous smaller bodies of water which are both
> landuse=reservoir and natural=water, as multipolygons and as single
> ways, and this is the only one causing problems.
>

why don't you try it instead of wild guess?
the rendering doesn't care what's in the wiki. the wiki can be  
completely wrong. check the rendering style and you will know for sure.
for the tags itself landuse on a lake? doesn't make any sense to me.


> -- 
> David "Smith"
> a.k.a. Vid the Kid
> a.k.a. Bír'd'in
>
> Does this font make me look fat?
>
> ___
> 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] CDPs and admin_level

[Anthony]

On Tue, Oct 13, 2009 at 5:31 AM, David ``Smith''  wrote:
> On Mon, Oct 12, 2009 at 8:14 PM, Anthony  wrote:
>> You're still acting like the tags are put on regions, when the tags
>> are actually put on borders.
>
> It's both.  The relation (specifically, boundary and multipolygon
> relations) is meant to describe not just some borders of a region, but
> all of its borders, in a way to make it clear whether a given point is
> in that region or not.  Therefore, the relation defines a region.  You
> put tags on the relation, so you are effectively tagging the region,
> not just its borders.

I was talking specifically about the "admin_level" tag though, since
that's the one you were saying shouldn't cross.  Obviously the
boundary relation should be defined to reflect reality - if a city
region intersects multiple county regions, then that's the way it has
to be tagged.

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

Re: [Talk-us] Reply-to?

[Sam Vekemans]

try, replying ALL, cc's the talk-us list.
There is a setting to make it so that you dont get this message twice, for
example.

Cheers,
Sam

On Tue, Oct 13, 2009 at 3:06 AM, David ``Smith'' wrote:

> Why is it, when I receive messages from this list, they don't come
> with a reply-to header so replies automatically go back to the list
> and not individual sender(s)?  That would be helpful.  The newbies
> list has such headers.  I looked on the list subscription site and I
> didn't see any settings that appear to relate to this.
>
> --
> David "Smith"
> a.k.a. Vid the Kid
> a.k.a. Bír'd'in
>
> Does this font make me look fat?
>
> ___
> 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] Reply-to?

[David ``Smith'']

Why is it, when I receive messages from this list, they don't come
with a reply-to header so replies automatically go back to the list
and not individual sender(s)?  That would be helpful.  The newbies
list has such headers.  I looked on the list subscription site and I
didn't see any settings that appear to relate to this.

-- 
David "Smith"
a.k.a. Vid the Kid
a.k.a. Bír'd'in

Does this font make me look fat?

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

Re: [Talk-us] Salt Fork Lake rendering issue

[David ``Smith'']

On Mon, Oct 12, 2009 at 8:24 PM, Seth Fitzsimmons  wrote:
> That looks likely.  Quabbin Reservoir (Western MA) is also rendering
> similarly: 
> http://www.openstreetmap.org/?lat=42.3749&lon=-72.2847&zoom=12&layers=0B00FTF
>
> Last I checked, landuse=reservoir is being rendered like natural=water
> even though it shouldn't be.  With the MassGIS OpenSpace import, lots
> of landuse=reservoir polys were imported and represent "protected
> areas", not water.
>
> seth
>
> On Mon, Oct 12, 2009 at 4:56 PM, Apollinaris Schoell  
> wrote:
>> Just a guess. landuse=reservoir overrules natural water.

I don't think that's the issue.  For one thing, Quabbin renders fine
in Mapnik, but poorly in Osmarender.  For Salt Fork Lake, the opposite
is true.  So they are two unrelated problems.  For another thing, all
of the relevant wiki pages seem to indicate that landuse=reservoir is
just as valid as natural=water for this type of feature.  (What kind
of "protected area" was tagged as landuse=reservoir in the MassGIS
import?  Unless those areas protect water, that tagging is wrong.)
Besides, I've done numerous smaller bodies of water which are both
landuse=reservoir and natural=water, as multipolygons and as single
ways, and this is the only one causing problems.

-- 
David "Smith"
a.k.a. Vid the Kid
a.k.a. Bír'd'in

Does this font make me look fat?

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

Re: [Talk-us] CDPs and admin_level

[David ``Smith'']

On Mon, Oct 12, 2009 at 8:14 PM, Anthony  wrote:
> You're still acting like the tags are put on regions, when the tags
> are actually put on borders.

It's both.  The relation (specifically, boundary and multipolygon
relations) is meant to describe not just some borders of a region, but
all of its borders, in a way to make it clear whether a given point is
in that region or not.  Therefore, the relation defines a region.  You
put tags on the relation, so you are effectively tagging the region,
not just its borders.  (Note specifically the name tag.  If a boundary
relation is done right, that name will usually be rendered in the
center of the region, instead of or in addition to around its edges.)

-- 
David "Smith"
a.k.a. Vid the Kid
a.k.a. Bír'd'in

Does this font make me look fat?

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

Re: [Talk-us] Fwd: Lake Winnepesaki rendering issue

[David ``Smith'']

On Mon, Oct 12, 2009 at 7:29 PM, Andrew Sawyer  wrote:
> Thanks for taking a look.  On the Information Freeway site it still shows a
> rendering issue. I notice that the Mapnik layer was getting changes faster.
> I tried manually forcing a rerender via the site, but nothing substantial
> has changed. Should the islands not have natural:land? Does t...@h not like
> that tag?
>
> I am glad it doesn't appear that I made an editing error.  I posted my
> original e-mail to the t...@h list. Hopefully someone over there can lend 
> their
> expertise. Is there a lot of data behinds the scene that affects the
> rendering, but the typical user cant see?

I notice that the parts of the map that don't render the lake right
happen to be specific map tiles at zoom 12.  A t...@h client will
download a chunk of OSM data that's supposed to be enough information
to correctly draw a zoom-12 tile and all of the closer zoom levels for
the same area.  This looks to me like, for a couple of tiles, the
chunk of data that gets downloaded is not sufficient to correctly
describe the lake.  This is due to the large size of the lake and the
way t...@h selects the data to be downloaded.

Here's a wild guess: what if those tiles are ordered re-rendered as
"ocean" tiles?  That might work, or it might require the outer ways of
the lake to be tagged natural=coastline.  I have a knack for guessing
how things work, but I'm still just guessing.

-- 
David "Smith"
a.k.a. Vid the Kid
a.k.a. Bír'd'in

Does this font make me look fat?

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

Re: [Talk-us] CDPs and admin_level

[Minh Nguyen]

On 10/12/09 10:28 AM, Bill Ricker wrote:
> I sympathize with Greg, and if the surveyors and computational mappers
> ruled the world, the real world we seek to model will be simpler.
>
> On Mon, Oct 12, 2009 at 12:44 PM, David Lynch  wrote:
>> where city limits cross county lines,
>
> WTF? Where does that happen? down where a county is called a parish
> and is region within sound of a steeple?
>
>   NYC inverts normal, iirc NYC is effectively a federation of
> city-counties called boroughs, but no county line crosses NYC
> boundary, right?
>
> When Boston adsorbed towns in adjacent counties, Suffolk county gained
> land too -- and likewise Boston and Suffolk released towns in the
> harbor to a non-adjacent (on land) coastal county. (as a result,
> Norfolk Co Mass is reputedly the only tripartite noncontiguous county
> separated by towns in other counties not by water )
>
> If State and National electoral districts are included, the
> gerrymander boundary will assuredly cross, not follow, admin
> boundaries higher than Ward&  Precinct, which may be redrawn to
> convenience the gerrymander.

The Wikipedia list below links both to cities that exist separately in 
different counties (as in New York) and to cities that exist as one unit 
in multiple counties (as in Ohio):



Coincidentally, Louisiana doesn't have any cities listed there. I once 
lived in a Louisiana parish, but not really within sound of a steeple. 
There's an exception to every rule. :)

-- 
Minh Nguyen 
[[en:User:Mxn]] [[vi:User:Mxn]] [[m:User:Mxn]]
AIM: trycom2000; Jabber: m...@1ec5.org; Blog: http://notes.1ec5.org/


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