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
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
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 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
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
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
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
for osm the one of the best options is a PDA with OSMTracker
http://wiki.openstreetmap.org/wiki/Osmtracker
You can do voice recording, hot keys, pictures to enter POI. Can be
used while driving easily. JOSM supports the gpx with linked voice POI.
ideally used on a PDA with built in GPS.
pros:
you can try the splitter from mkmap project to split osm files in case
increasing the heap size is still not enough.
On Tue, Mar 24, 2009 at 1:21 PM, Sam Vekemans
acrosscanadatra...@gmail.comwrote:
Thanks,
for my purposes right now, extending the memory heap size on the
command line with:
below is some info from Garmin. Didn't help mine and Garmin exchanged
it. Was lucky enough it happend in the warranty. was already second
unit they changed for me.
Thank you for contacting Garmin International.
I will be happy to assist. The eTrex has a Boot-Block function that
will
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,
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
301 - 330 of 330 matches
Mail list logo
