Google, Yahoo, don't match in a lot of cases. Google uses Tele
Atlas data which is obviously derived from same sources as Tiger and
often completely outdated, in wrong places
On 1 Feb 2009, at 13:36 , Ian Dees wrote:
On Sun, Feb 1, 2009 at 3:25 PM, rich...@weait.com wrote:
have started to play a bit with route relations as proposed in
http://wiki.openstreetmap.org/wiki/United_States_roads_tagging
relations are really great especially when using JOSM.
But without documentation what has been done already it may end in
multiple relations created fro the same
cool opportunity to differentiate this is pretty much empty in google maps.best
to organize a mapping party and carpooling. only one permit per car is
required.
who is interested in
1 day, Saturday
1 day, Sunday
camping Saturday
camping Friday, Saturday
On Fri, Feb 20, 2009 at 10:04 AM,
Hi,
found this data from OSP. Does anyone else plan to import it? Has
anyone checked with them if the data can be used for openstreetmap?
the shape files contain open accessible trails(hike, bike,
equestrian) and areas(open and closed access) managed by OSP
the kmz file contains the trails
this is nice, will add what I have done already.
some comments for discussion.
did you change the recommendation for a reason compared to the one here?
http://wiki.openstreetmap.org/wiki/United_States_roads_tagging
not that this is perfect but it has more information.
both definitions should be
On 12 Apr 2009, at 2:39 , Joseph Jon Booker wrote:
US routes can also become two separate one-ways when becoming
express ways or trunk ways, while being a regular two-way street the
rest of the way, so it probably doesn't make sense to have separate
directions. Perhaps a proposal can be made
this is great work, signs could be a bit smaller tough.
why not stick with the symbol tag? see
http://wiki.openstreetmap.org/wiki/United_States_roads_tagging
the symbols tagging should be transparent to the mappers not only to
some internal notation of a renderer.
and tags should be human
On 12 Apr 2009, at 9:01 , Adam Schreiber wrote:
Probably because the mapper can easily identify the type of road (i.e.
Interstate, US Hwy, etc.). I'm not sure that the mapper should be
specifying the URL of the sign since it requires extra work to find it
and any renderer should be able to
On 12 Apr 2009, at 11:58 , Richard Weait wrote:
On Sun, 2009-04-12 at 13:23 -0500, Joseph Jon Booker wrote:
On Sun, 12 Apr 2009 08:39:45 -0700
Apollinaris Schoell ascho...@gmail.com wrote:
2 relations are easier. adding role to thousands of members is a
pain. and we need to split relations
On 12 Apr 2009, at 17:00 , Paul Johnson wrote:
Apollinaris Schoell wrote:
this is nice, will add what I have done already.
some comments for discussion.
did you change the recommendation for a reason compared to the one
here?
http://wiki.openstreetmap.org/wiki
On 13 Apr 2009, at 5:36 , Adam Schreiber wrote:
What about:
addr:country=us
addr:state=ca
network=us
or
addr:country=us
addr:state=ca
network=i
network should be US, I,
all signs use uppercase, there can be so many uses for the data.
network should reflect the real usage
I'm in danger of spending more time flaming than fixing the map, but
have always been interested in the database schema aspect of OSM.
Evolving tags is messier than a designed scheme, but I see the
wisdom of
how it avoids the wrong design persisting. Still, I think it may make
sense to
The lower case has nothing to do with a renderer, just OSM convention
for key value pairs other than name.
network name is an officially documented and commonly used name. it
should be treated like the name tag or the ref tag.
how else could a renderer come up with the correct use if
Why make this more complicated than it has to be? Leave the names on
the underlying way, not the relations; leave the refs on the
relations,
not the underlying ways. Then it's a matter of fixing mapnik and
t...@h to
do the right thing, since relations are set up better to handle
On 13 Apr 2009, at 11:06 , Zeke Farwell wrote:
Joseph Jon Booker said:
My approach (and I don't know if you'll agree with this) is to
considerPacific Highway something independent of I-5 or Oregon 99.
Pacific Highway is more like its own designation for a highway, and
ways which
what is the benefit in doing this?
have done it earlier but it is a lot of work and I can't find any
reason in which use ore application it helps.
If you consider it a sign of completeness or accuracy then this is not
the way to go.
If you want to see if anyone worked on tiger data it is as
rid of it or hack
the josm source.
both isn't too difficult for an experienced josm user but why should
anyone need to?
On 23 Apr 2009, at 14:25 , Russ Nelson wrote:
On Apr 22, 2009, at 11:02 AM, Apollinaris Schoell wrote:
what is the benefit in doing this?
There is no other method
Perhaps there should just be a view option highlight unreviewed
objects, and those that like this can turn it on and those that don't
can not.
if it's an option I wouldn't wast a second to write about the pro/con.
why does anyone try to force users to do it?
I have patched josm already
On 24 Apr 2009, at 7:14 , Russ Nelson wrote:
On Apr 24, 2009, at 2:01 AM, Apollinaris Schoell wrote:
the tiger data is terrible wrong in some places.
And how do you know this?
1.
http://www.openstreetmap.org/?lat=37.379805lon=-122.166681zoom=18layers=B000FTF
compare wit Yahoo,
2
my java knowledge is 0. can't patch it to make it an option.
all I can is to remove the whole style and rebuild.
anyone is free to remove this tag and I have done it in the past too
but since then I realized it's just useless. why waste time if
there is so much to work on?
and I consider it
On 24 Apr 2009, at 9:40 , Alan Millar wrote:
can you give a single example where this info is helping?
It may not help you anywhere. It helps me everywhere, in my personal
mapping process.
good for you, osm is free and this a good thing that we can do things
the way we like it.
is that
On 24 Apr 2009, at 14:27 , Russ Nelson wrote:
On Apr 24, 2009, at 1:26 PM, Apollinaris Schoell wrote:
forcing every josm user to accept it is somewhere between ignorance
and dictatorship
Your argument, if true, is an argument against ANY change to JOSM.
improvements are always welcome
will like and others hate. If it can
be activated/deactivated it's a nice to have.
On 24 Apr 2009, at 21:38 , Dave Hansen wrote:
On Fri, 2009-04-24 at 10:26 -0700, Apollinaris Schoell wrote:
forcing every josm user to accept it is somewhere between ignorance
and dictatorship
Hi Apollinaris
. for now I will spend my time to fix the
basics first. and shouldn't spend so much time on these emails ;-)
On 25 Apr 2009, at 19:02 , Russ Nelson wrote:
On Apr 24, 2009, at 7:47 AM, Apollinaris Schoell wrote:
if it's an option I wouldn't wast a second to write about the pro/
con.
why does
http://keepright.ipax.at
Ugh. Those are all written in sql. :(
I've been using the JOSM validator plugin to fix this stuff on a small
scale. I've had dreams of using the same code to do fixing of TIGER
stuff outside of JOSM, but haven't ever gotten around to it.
JOSM validator is great
not a good idea to delete the relation. It will be incredible painful
to add all pieces agin and not missing a single bridge.
Josm is the best solution. Also Merkaator supports Yahoo images.
The nice thing in Josm is you can select all members of a realtion
easily. download all members,
a good reference are the USGS maps. their accuracy is way better compared to
tiger. they are pretty old and usually miss data from the last 10-30 years.
one download location is here http://libremap.org/
You can use any tool which supports geotiff and gpx or shape import to match
some of the
many parks are tagged with
leisure park
Is this really the recommended setting? according to the wiki park is
something more like golden gate park in SF or central park in NY
natural_reserve matches better the main purpose of national parks.
some places in national parks are as crowded as a
And yet Richard, Greg, and Dale all said that removing
tiger:reviewed=no implies pretty much two things: the name is right
(more or less) and the location is right (more or less). I think that
perhaps we can agree on that.
so it's (more or less) use(ful or less)
But I also think that we
but there should be something in
place similar to existing maps.
On 12 May 2009, at 4:54 , Greg Troxel wrote:
Apollinaris Schoell ascho...@gmail.com writes:
many parks are tagged with
leisure park
Is this really the recommended setting? according to the wiki park is
something more like
nobody is perfect.
terraserver has some major scanning errors in Yosemite and in other
places too.
so far havn't found any on yahoo images but others reported them
On 17 Jun 2009, at 12:36 , Dale Puch wrote:
Just a caution.
I was just checking this out and noticed that the highest zoom
not sure if I understand correct. by staggered do you mean they are on
different levels via bridges or underpass?
then there is no need to split. instead
1) unglue the node, you will have 2 nodes at exact same location. one
belongs to way one the other to way 2
2) if need to move: both are
boundary=national_park
ownership=national
operator=United States National Park Service
or
operator=United States National Forest Service
operator=United States Bureau of Land Management
etc.
makes sense to use just one boundary tag. easier to implement in the
renderer and good enough
to the
motorway (which
I fixed).
That's a valid concern (also voiced by Apollinaris Schoell) and I had
not thought about that.
I have now changed the script to identify dangling motorway_links,
and
leave them untouched even if they are connected to a lesser road on
the
other end. I don't actually
Yeah, you definitely have to be careful. It's OK for a motorway to
touch:
1. another motorway
2. a motorway_link
3. a non-mototorway, but only at its *END* node. Not at its beginning
node
Why? US 101 changes an estimated million times from motorway to trunk/
primary and back to
Yep. I've even got a JOSM validator plugin test to check motorway
intersections. It doesn't do the angles, but just ensures motorways
only touch other way types at their endpoints.
very useful, can you share?
Apollinaris
-- Dave
___
It's very slow today. Did an upload of 4k nodes and it took about 3h
if possible split the data, waiting 15h and then it stops because of a
conflict is a pain
On Jul 18, 2009, at 8:07 PM, Andrew Ayre wrote:
Thanks Tyler and Dave.
I tried bulk_upload.py and it gave me a 404 error.
I
I remove the tiger:reviewed tag, insert (or append to) a source
tag
with values:
yahoo_imagry [sic] (mis-spelled for consistency with current usage);
usgs_imagery;
image (for my own picture);
survey (I drove the area);
local_knowledge (from my own recollection);
local_government
Re: Bill Ricker's suggestion of flagging the dangling motorway_links,
that is certainly possible and easy for me to do if you want it (I'd
suggest something like FIXME=this motorway_link does not seem to be
connected to a motorway or so).
put bugs where they belong to.
Hi,
many state parks are in osm but no info about the source. Anyone knows
data sources for state parks?
thanks
Apollinaris
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
On Jul 25, 2009, at 9:10 AM, David Carmean wrote:
On Sat, Jul 25, 2009 at 07:25:21AM -0700, Apollinaris Schoell wrote:
[snip]
Which data do you have in mind? which data sources? is there anything
better available compared to http://atlas.ca.gov/download.html
That looks to be a new
no info in the wiki.
Is this documented somewhere?
On Aug 16, 2009, at 9:12 PM, Chris Hunter wrote:
Looks like the 2008 data for my area (TN) just got uploaded about 5
hours ago if I did the time conversion right.
On Fri, Aug 14, 2009 at 7:36 PM, Richard Shank deve...@zestic.com
wrote:
I
welcome in the world of osm cleanup ;-)
there are so many errors in osm data for routing and some are very difficult
to find.
most people don't care as long as the maps is rendered nice. and without
tools it's hard to make mappers aware of them.
America doesn't have an instance of keepright
sure, tiger import is not perfect as we all now
On Aug 20, 2009, at 3:07 PM, Nakor wrote:
Thanks. It does not show up. Could it be that they never existed
(they were not part of TIGER import)?
Apollinaris Schoell wrote:
In Potlatch shift U
red lines have been deleted, select
the wiki has them as proposal on boundary=adminstrative, admin level 1, but
this is definitely wrong. they should be either level 3 - 5. as far as I
know they have a pretty special legal status and level 3 seems to be a good
choice.an adminsitrative boundary should always render. For more details
to have it changed.
On 1 Sep 2009, at 20:55 , Paul Johnson wrote:
On Mon, 2009-08-31 at 14:10 -0700, Apollinaris Schoell wrote:
the wiki has them as proposal on boundary=adminstrative, admin level
1, but this is definitely wrong. they should be either level 3 - 5.
as
far as I know they have
exactly, performance of editors is very bad with a huge number of
relations.
On 4 Sep 2009, at 7:41 , Mike N. wrote:
While there may not be a hard limit on # of items in a relation, it
might be
more convenient to break up relations by state. That enables
downloading
all elements of
I have always used 2 for multiple reasons.
- they have different signs and if you add direction tag with same
info to the relation routing software can use it. commercial navis are
doing it too.
- putting the info on a role is lot of work and prone to errors. Josm
improved lately but it is
This sounds like an interesting experiment worth running on Amazon's EC2
cloud. Their x-large machines run at $1/hour, but sure would chomp on this
data quickly!
I would be willing to try (and pay for) it if Lars went through a did an
updated setup doc.
We could start our own distributed
you can run osmosis on the planet with a US boundary polygon. If you
don't mind some overlaps with Canada and Mexico it is easier to clip a
rectangle.
this is what I use to get all of washington, oregon, california in one
extract.
bzcat planet | osmosis --rx pipe --bb left=-126 right=-113
full support for all your arguments.
there are a few places where the wiki is different and I think we
should change these definitions.
1) National Forest Service, Bureau of Indian Affairs, Power
Administration, and Bureau of Land Management routes
.
highway (required) track or tertiary
+1
given the length of some interstates this is highly recommended.
On 7 Sep 2009, at 12:12 , Richard Welty wrote:
given that there is apparent concensus that Interstate relations be
done
on a state-by-state
basis, perhaps the language on the Interstate_Highways_Relations page
should be
the tiles from this site are not routable. It is stated on the website.
have done a test run and the lower states have been ~ 2.5G too much for
almost all Garmin models. still working on optimized tiling. some tiles are
still failing because of size.
On Tue, Sep 8, 2009 at 8:06 PM, Nakor
I think it's fine except this oneUrban Freeways and Expressways -
highway:trunk
If it's a signed freeway tag it as motorway not as trunk
freeways usually have a signed designation, access restrictions for
pedestrians. bikes(with some exceptions in CA,OR ...) this deserves the
motorway tag.
On
oneway and a single way can break routing.
On 9 Sep 2009, at 19:30 , Bill Ricker wrote:
On Tue, Sep 8, 2009 at 11:58 PM, Apollinaris Schoell ascho...@gmail.com
wrote:
the tiles from this site are not routable. It is stated on the
website.
thanks to Tiger and MassGIS issues, until we
definitely something which should be continued. but it's not trivial.
some considerations
- 2009 update for tiger date should come soon. and hopefully it has less
errors. makes sense to wait for it
- in areas where data hasn't been touched it's also very likely the areas
which are of bad tiger
I know user nmixter has started to to compile a list for california for free
county gis data. Can't connect to the wiki right now. But easy to find from
the California page.
On Thu, Sep 17, 2009 at 11:32 AM, Richard Shank deve...@zestic.com wrote:
Apollinaris Schoell wrote:
- more and more
I know this info was sent earlier to these lists. Did anyone already buy
these disks for use in OSM projects already?
since data itself is in public domain a single set of disks will be enough.
http://geodatapolicy.wordpress.com/2009/09/18/santa-clara-county-releases-data/
--
apollinaris
I suggest to subscribe to talk-ca and read what they are doing to
merge existing data with new and better imports
On 30 Sep 2009, at 6:49 , Christopher Covington wrote:
Hi All,
How can one import large datasets of information mostly already on the
map to Open Street Map? I believe that my
You'll be blown away when you see what our French cousins are doing.
Then you'll want to combine the ideas; I know I want to. ;-)
we are all waiting to see it. there is so much data with regular
updates and without a tools it's a job for the rest of you life.
On 2 Oct 2009, at 21:32 , Kevin wrote:
yes, we can import a subset of the tiger data and it's easy to
reproject
to wgs80. fyi, 2009 tiger is available. i can import the county
boundaries for hawaii right now since the it looks like the usgs
county
boundaries weren't imported.
the
have seen other small islets missing in yahoo, but they are seen in google
imagesmust be a yahoo problem
On Mon, Oct 5, 2009 at 2:31 PM, Scott Atwood scott.roy.atw...@gmail.comwrote:
Kaʻula Rock is a tiny islet a couple of dozen miles southeast of Niʻihau in
the Hawaiian Islands. The islet
On 5 Oct 2009, at 22:07 , Mark Dalton wrote:
I would like to bring together some newbies to experienced people to
help everyone
get things done.
I would be happy to find a venue, supply snacks, etc..
Here are some of the questions I have been asked to get a feel for
some
experience
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
some counties have detailed parcel data and even building outlines with
adress data.
someone imported a nice example in Mono county
http://www.openstreetmap.org/?lat=37.645611lon=-118.975286zoom=18layers=B000FTF
but some buildings have only dummy adress and are 0.
other counties offer data too
me too
also bay area
On 20 Oct 2009, at 21:00 , Dan Homerick wrote:
On Tue, Oct 20, 2009 at 8:23 PM, SteveC st...@asklater.com wrote:
Neither list has any real traffic, and what they do tend to just be
reposts of talk-us.
Splitting the community at this stage is retarded, we should wait for
On Wed, Nov 11, 2009 at 7:19 PM, Anthony o...@inbox.org wrote:
On the other hand, putting the information directly on the way would
be problematic for many reasons. Ranges might span multiple ways, and
right/left has to be reversed whenever the way is reversed being the
most troublesome.
On 12 Nov 2009, at 8:28 , Ian Dees wrote:
On Thu, Nov 12, 2009 at 10:20 AM, Apollinaris Schoell ascho...@gmail.com
wrote:
On 12 Nov 2009, at 6:14 , Andy Allan wrote:
I disagree there. It's much better to put the effort in during the
initial import, than to import things badly and try
On 12 Nov 2009, at 6:14 , Andy Allan wrote:
I disagree there. It's much better to put the effort in during the
initial import, than to import things badly and try to fix it up
later. We've been working on lots of post-import fixups in the last 6
months and it's much harder than everyone
On 12 Nov 2009, at 11:29 , Anthony wrote:
On Thu, Nov 12, 2009 at 9:14 AM, Andy Allan gravityst...@gmail.com
wrote:
It's a fairly well established convention that in OSM it's the
houses/plots, not the road centrelines, that are addressed.
But that doesn't always reflect reality. The
follow the OSM principle.
map what's on the ground no matter where you are
On 12 Nov 2009, at 11:56 , Dave Hansen wrote:
On Thu, 2009-11-12 at 11:40 -0800, Apollinaris Schoell wrote:
On 12 Nov 2009, at 11:29 , Anthony wrote:
On Thu, Nov 12, 2009 at 9:14 AM, Andy Allan gravityst...@gmail.com
Hi Dave,
can you provide SC (Santa Clara County) California?
btw any ideas how the break it into smaller pieces? I definitely don't
want to upload a whole county at once and deal with the big mess
afterwards.
As I understand it address ways don't connect to other ways so it
shouldn't be
TIGER is an incredibly huge data set. It comes from what may be the
most diverse set of primary sources of anything in the world short of
OSM itself.
It shouldn't be trusted explicitly (no single map should). Do you
have
some more constructive information about places where you've
I'm highly in favor of doing the import, regardless. I think the
inaccuracies will be far easier to fix than to put the addressing in
from scratch. I've done a lot of mapping in my area, but haven't
been willing to start doing addresses, even before I knew that the
TIGER import was
On 13 Nov 2009, at 23:56 , Dan Homerick wrote:
On Fri, Nov 13, 2009 at 10:50 PM, Apollinaris Schoell ascho...@gmail.com
wrote:
I'm highly in favor of doing the import, regardless. I think the
inaccuracies will be far easier to fix than to put the addressing in
from scratch. I've
What really needs to be done for TIGER addresses import is match the
streets from TIGER to those in OSM (which should be easy since they
all still have the TIGER id's) and generate the address geometry based
on these. Otherwise someone will need to do all of the geometry
corrections that
On 14 Nov 2009, at 10:22 , Dave Hansen wrote:
On Fri, 2009-11-13 at 23:56 -0800, Dan Homerick wrote:
i, Nov 13, 2009 at 10:50 PM, Apollinaris Schoell ascho...@gmail.com
wrote:
I'm highly in favor of doing the import, regardless. I
think the inaccuracies
On 14 Nov 2009, at 18:05 , andrzej zaborowski wrote:
2009/11/15 Apollinaris Schoell ascho...@gmail.com:
matching Tiger id's is a very bad idea. you need to compare
geometries.
during edits ways are split, merged copied moved, deleted nodes
added node,
Most of these operations
Alan Millar wrote:
no one is interested to cleanup crap after a bad import.
I am.
tiger import was great from technical
point of view but didn't allow to build a community from scratch.
I didn't want to build anything from scratch. I'm simply not
On 16 Nov 2009, at 7:14 , Anthony wrote:
On Mon, Nov 16, 2009 at 10:05 AM, Andy Allan gravityst...@gmail.com wrote:
I'd love to know which map has an
accurate pedestrian routing network that is collected as such and not
a derived interpretation of other base maps.
C'mon, this is the
On 16 Nov 2009, at 7:05 , Andy Allan wrote:
On Mon, Nov 16, 2009 at 2:34 PM, Russ Nelson nel...@crynwr.com wrote:
Andy Allan writes:
On Sat, Nov 14, 2009 at 6:22 PM, Dave Hansen d...@sr71.net wrote:
There are still quite a few squeaky wheels that
like to grumble about TIGER, but
On 16 Nov 2009, at 7:40 , Anthony wrote:
On Mon, Nov 16, 2009 at 9:41 AM, Lord-Castillo, Brett
blord-casti...@stlouisco.com wrote:
I'm still getting a handle on the schemas in use for OSM, and noticed that
concept of matching address nodes to ways when doing imports.
I'm not so sure this
SteveC wrote:
Thinking about this 'numbers on nodes' schema... let's say it's perfect and
we all agree, then who's going to do the import work for it?
It requires matching up past and present geometries to find the correct nodes
to update, and, er, that's the hard bit of coding with the
To make a gmapsupp.img for all of the US, I was going to get a US
extract of the planet, use splitter, and then use mkgmap with routing
enabled. I would then use gmapibuilder to put into RoadTrip so I can
load the parts I want together with the proprietary map (for when I
actually have
will check the setup on the dev server and see how difficult it is to run
things there.
having the planet via nfs will save a couple hours for download.
Will need a couple of days because I am moving and my time and internet
access is limited.
On Thu, Nov 19, 2009 at 10:00 AM, Dave Hansen
On 3 Dec 2009, at 9:08 , Ian Dees wrote:
On Thu, Dec 3, 2009 at 11:01 AM, Thea Clay t...@cloudmade.com wrote:
Hi guys,
I am so excited that more land use imports are in the works. They make such a
huge visual difference. Check out the border between a state with the import
complete and
On Thu, Dec 3, 2009 at 3:50 PM, Jeff Barlow j...@wb6csv.net wrote:
Hi,
I'm new here and a little unsure of how best to proceed. I'm
having some issues getting JOSM to run but I expect to get those
sorted out soon. Then I want to start working on TIGER fixup.
I'm located in central Oregon,
you can open the area in Potlatch and hit U
deleted objects will appear in red and after unlock they are restored for
normal edit.
works very well if there aren't hundreds of other deleted objects in the
same area
On Fri, Dec 4, 2009 at 1:38 PM, Christopher Covington c...@vt.edu wrote:
Hi all,
On Fri, Dec 4, 2009 at 2:40 PM, Richard Welty rwe...@averillpark.netwrote:
On 12/4/09 5:02 PM, Apollinaris Schoell wrote:
you can open the area in Potlatch and hit U
deleted objects will appear in red and after unlock they are restored for
normal edit.
works very well if there aren't
data from census isn't best quality and it will just repeat the errors
from tiger import. tiger roads have already zip codes. there is no
additional value.
in the long term full address data is the way to go.
imports for data from census should be done only locally where mapper
can verify the
Didn't find time to check this earlier. this is entirely wrong and the
changeset commetn tells it all 'more likely to be tertiary than residential, in
this area'
any objections to revert this changeset as a whole?
revert will skip all ways which have been touched in the meantime. It might
leave
there is a major disconnect between what people think is right and what
the wiki calls for. from
http://wiki.openstreetmap.org/wiki/Interstate_Highways_Relations
we see:
network=US:I, US:I:BUSINESS, US:I:DOWNTOWN, US:I:FUTURE Required.
Business, downtown and future routes have their
I'm happy to use either method, but one of the reasons why I prefer the
1-relation-per-direction method is that it lets me quickly find areas that
need to be split into dual carriageways.
same for me, Josm has good support for sorting and relations and checking
for gaps. also the relation
Have seen it too in California. It's not only the elevation also lat/lon is
wrong for many summits.
If there is any better source correct it. I verify it by gps and topo 24k and
yahoo. If there is any official and better data I am all for replacing GNIS
data.
On 9 Feb 2010, at 19:35 , Mike
have built contour line maps lately based on srtm data. If anyone is interested
in a specifc area let me know. I am not such a web guru like Lambertus and have
no host to provide them for convenient download. If someone can host them let
me know. most tiles are 1x1 degree except where it
overkill. with NED data it's a
different story
25m minor
100m medium
200m major
what did you use for medium and major contours?
Sam
On 2/17/10, Apollinaris Schoell ascho...@gmail.com wrote:
have built contour line maps lately based on srtm data. If anyone is
interested in a specifc area
/ is SRTM based with refined data.
Cheers,
Sam
Sam
On 2/17/10, Apollinaris Schoell ascho...@gmail.com wrote:
have built contour line maps lately based on srtm data. If anyone is
interested in a specifc area let me know. I am not such a web guru like
Lambertus and have no host
On 22 Feb 2010, at 23:39 , Stellan Lagerstrom wrote:
Apollinaris Schoell wrote:
did someone contact this user? any feedback?
he/she reverted the whole revert again.
Will try to revert some of the worst areas for now but can't spend to much
time on this.
We had a brief exchange
moving thread to talk-us where it belongs
Begin forwarded message:
From: Mike N nice...@att.net
Date: 28 February 2010 9:17:01 PST
To: t...@openstreetmap.org
Subject: Re: [OSM-talk] Help! Changeset reverted without explanation
I don't see that the Wiki is self-contradictory in this
On 28 Feb 2010, at 11:50 , Mike N wrote:
yes, but the wiki isn't free of errors and can't be used as absolute
reference. Who wrote it? was it based on wide agreement?
If it's in wide use for a long period of time with no objections, it is
closer to a standard than any other
1 - 100 of 163 matches
Mail list logo
