[OSM-dev] status/prognosis of Merkaator?

[Greg Troxel]

I help maintain geo things in pkgsrc, a multi-OS multi-cpu portable
packaging system.  We are struggling with programs still using qt4, and
we currently have an old (0.17) version of merkaator.

Looking at the http://www.merkaartor.be/, I see a release in 2016, and
the last mailinglist message was in November of 2017.

So I am contemplating whether merkaator should be updated in pkgsrc, or
dropped.  Questions:

  Is 0.18.3 really the most recent release?

  Is there any reason to think a new release will be forthcoming?

  Is Merkaator a reasonable choice for OSM editing, it terms of working
  with current APIs and preset notions?

  Is there any reason why someone would choose to use merkaator rather
  than josm (other than wanting to use it on a platform where Java is
  unavailable)?
  
  Anything else I should be asking?


Thanks,
Greg (OSM user gdt)

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

Re: [OSM-dev] OSRM on osm.org not working

[Greg Troxel]

Greg Troxel  writes:

> Separate issue I think, but I notice that routing does not recover after
> using ORSM.

Sorry, this was already in the tracker:

https://github.com/openstreetmap/openstreetmap-website/issues/1519


signature.asc
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSRM on osm.org not working

[Greg Troxel]

Separate issue I think, but I notice that routing does not recover after
using ORSM.

To reproduce

  at www.openstreetmap.org

  drop start/end pings with right click

  click on selection and go down the list looking at each route

  at ORSM, notice the error message "Couldn't find a route between those
  two places."

  click to "Foot (GraphHopper)" and notice the message is still there.
  Click "go" and see a route.

  click to "Foot (Mapzen)" and notice the you get (very slightly)
  different foot directions, without having to click Go.


This actually confused me quite a while ago when either one engine
couldn't find a route or was down, and I didn't realize that a
newly-selected engine didn't work without the go button.

If somebody tells me I'm not confused about this and it would be
helpful, I'm happy to file this at
https://github.com/openstreetmap/openstreetmap-website/issues



signature.asc
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Earth radius

[Greg Troxel]

"Stadin, Benjamin"  writes:

> I indeed need to express distances in meters. This is a sinusoidal
> grid with Varying cell resolutions, matching the length of web
> mercator tiles at the equator.  I could use any value greater or equal
> to the defined sphere radius, but not smaller.  To be consistent, it
> should be equal.

Things to keep in mind:

  WGS84 is an ellipsoid, not a sphere.  There is a radius and
  flattening, or alternatively different equatorial and polar radii.

  "Web Mercator" or "Spherical Mercator" is not actually Mercator, and
  is not conformal.   It projects by assuming a sphere, which isn't
  true.  So trying to use one radius to get distances on the surface
  from projected coordinates is not going to work well.

So if you want the right answers, use proj.4, use real WGS84
coordinates, and use the geodesic functions.

If you need fast math within a local region, I would suggest computing a
few correct values (a point, offset in easting, offest in northing) by
going from projected back to geodetic and then calculate geodesics,
finding out the ratio of distance to projected coords, and then building
a local approximation function.  But if you aren't having CPU pain from
doing it right, I would just use proj.4.


signature.asc
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Using native social SDK for signing in to OSM on mobile

[Greg Troxel]

Simon Poole  writes:

> If I understand Ilya correctly what he wants to avoid is (the hassle of)
> the authorisation step when using OAuth. During this process you need to
> login to openstreetmap.org with your credentials and then confirm that
> the app is allowed to access the API on your behalf.
>
> To see what is involved in practical terms you can try to use the HOT
> task manager, maproulette etc (or on a mobile device Vespucci, I assume
> Go Map! uses OAuth too, as any current third party app for OSM should).

Thanks; I am begininng to understand.  I dimly remember that Vespucci
used to store username/paassword, but recently I tried to upload some
changes and had to go through the oauth process.  Other than having to
know my osm password it was quite trivial, requiring typing 'gdt' and
the password and then changing a few checkboxes.   This seems like a
very nice solution and I particularly appreciate the fine-grained
permissions.

> The authorisation is a one time process (per app) and as such I'm not
> quite convinced that the whole discussion isn't a solution looking for a
> problem, but Ilya is correct in that it does involve the hassle of
> people remembering their google/FB/whatever password. Naturally on a
> mobile device you want to minimize typing in any case so I'm mildly in
> support of at least investigating what this would entail (it is unlikely
> that we would use a proprietary solution in Vepsucci though, on other
> devices and with other apps the trade-offs might be different).

The word "social" (that you didn't use :-) seems confounding in this
discussion.

So is the notion:

  One could link some third-party openid/openauth provider to one's OSM
  account, either manually, or because it was used to sign up.

  On a device, one might already be authorized for this third-party
  openauth/openid provider.

  A program that does OSM stuff (Vespucci, OsmAnd, firefox) might then
  authorize to osm.org via this third-party provider, requiring only a
  yes click to an "authorize to osm via foo" popup?


That seems harmless enough as long as it doesn't lead to proprietary
software showing up in Free programs,  doesn't result in any data
flowing to those third-party sites for users that don't already have a
relationship with them, and doesn't lead to apps suggesting that people
sign up with these other places.


> The above is a separate but related issue to making the signup process
> "mobile friendly"  see
> https://github.com/openstreetmap/openstreetmap-website/issues/894 for a
> longish discussion.

Thanks for the link.  That mostly makes sense, except for the notion
that Android is unusable without a Google account.  I will agree with
"base Android with google stuff (vs CM) is hostile to those without a
google account" though.


signature.asc
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Using native social SDK for signing in to OSM on mobile

[Greg Troxel]

Ilya Zverev  writes:

> This can be made a part of a policy for allowing apps to use OSM
> official social accounts.

Can you explain what you mean by "OSM official social accounts"?
Perhaps it is just me that doesn't get it, but I am not following what
you really mean.


signature.asc
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Using native social SDK for signing in to OSM on mobile

[Greg Troxel]

Ilya Zverev  writes:

> I would like osm.org to support authentication via native social
> SDKs. It would benefit current and future mobile editing apps, and
> would drastically increase the number of OSM editors (that is,
> users). I'm writing all this, so authors of other editing apps could
> show their support.

I am having a little trouble understanding this.  Do you mean using iD
on openstreetmap.org?   Getting a new osm account based on some other
account?

By "native SDK", do you mean to include proprietary software?
Non-published interfaces?


signature.asc
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [Routing] Question about routing between OSM and private data

[Greg Troxel]

Arlindo Pereira  writes:

> 1) creating a table listing each street on his road list to an array of OSM
> Way IDs, and somehow indicating to the algorithm that those ways are
> preferred. But this would require constant maintenance as people
> edit/split/merge/erase ways.
>
> 2) considering the street names, and somehow making the routing algorithm
> prefer those ways.

The basic issue is keeping two databases in somewhat sync.   If there is
KML, I would be inclined to have a combining step where the preferred
roads are matched up with OSM data by geometry and then the OSM ways
marked with the special tag (locally).   Here, any of id, name, or
shape/location could work.  shape/location is probably pretty stable.

> 3) mapping those characteristics that made he chose those particular
> streets in first place (maxspeed=, incline=, lanes=, highway= itself, etc
> etc) and tuning the routing algorithm to prefer those streets. But nothing
> would garanteed that the router wouldn't pick a particular tertiary or even
> highway=residential that is not "calm" in oppositon to a "calm road".

This would be interesting in the long run, but seems very hard.


Is this other dataset also under OdbL and the merged dataset being
released under the same terms?


signature.asc
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Osm2pgsql build system changes and testing

[Greg Troxel]

Paul Norman  writes:

> We are planning to switch the osm2pgsql build system from autotools to
> cmake and could use help testing on different distributions, operating
> systems, and other less common configurations.
>
> More info is at https://github.com/openstreetmap/osm2pgsql/pull/460
> and you will need to use the cmake branch at
> https://github.com/alex85k/osm2pgsql.git. Build instructions are at
> https://github.com/alex85k/osm2pgsql/blob/cmake/README.md#building
>
> Before reporting problems, try running git clean -xfd to remove any
> traces of Autotools build files. If there are problems, please report
> them at https://github.com/openstreetmap/osm2pgsql/pull/460 including
> OS, distribution, CMake and make command line, and where any files not
> found are installed.

(I look after the postgis, geos and viking packages in pkgsrc.)

On a NetBSD 6 i386 system, I did a fresh clone.  Then I built osm2pgsql
0.88.1 from pkgsrc, so I'd have the dependencies (all --prefix=/usr/pkg).

The README.md says it uses autotools.  But after reading on, I found the
cmake instructions.

I then got a failure about -std=c++11 (system compiler 4.5, my fault for
not reading) and added /usr/pkg/gcc48/bin to my PATH, reran cmake, and
reran make.  That still failed, which seems like a bug, but not that
important to fix and arguably a bug in cmake not osm2pgsql.

I have gcc48 and gcc48-libs (has libstdc++) installed.  I would expect
gcc48 to steer programs to the 4.8 include files, but I put the
directory in -I anyway.

I iterated with nuking/restarting and ended up with a script:

  rm -rf CMakeCache.txt CMakeFiles Makefile cmake_install.cmake config.h

  export CPPFLAGS="-I/usr/pkg/gcc48/include -I/usr/pkg/include"
  export LDFLAGS="-L/usr/pkg/lib -R/usr/pkg/lib"

  cmake ..

  make

which resulted in a lot of warnings about printf specifiers and a
std::to_string error that I don't understand.

The instructions did not say how to use clang; I have

  clang version 3.6.2 (tags/RELEASE_362/final)
  Target: i386--netbsdelf
  Thread model: posix

installed, but I don't have a faux-gcc dir for it to stick in PATH.


-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/pkg/gcc48/bin/cc
-- Check for working C compiler: /usr/pkg/gcc48/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/pkg/gcc48/bin/c++
-- Check for working CXX compiler: /usr/pkg/gcc48/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building osm2pgsql 0.89.0-dev
-- Looking for include file termios.h
-- Looking for include file termios.h - found
-- Looking for include file libgen.h
-- Looking for include file libgen.h - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - found
-- Looking for include file sys/wait.h
-- Looking for include file sys/wait.h - found
-- Looking for include file sys/time.h
-- Looking for include file sys/time.h - found
-- Looking for include file sys/mman.h
-- Looking for include file sys/mman.h - found
-- Looking for lseek64
-- Looking for lseek64 - not found
-- Looking for posix_fallocate
-- Looking for posix_fallocate - not found
-- Looking for posix_fadvise
-- Looking for posix_fadvise - found
-- Looking for sync_file_range
-- Looking for sync_file_range - not found
-- Looking for fork
-- Looking for fork - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of off_t
-- Check size of off_t - done
-- Found ZLIB: /lib/libz.so (found version "1.2.3") 
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found EXPAT: /usr/lib/libexpat.so (found version "2.0.1") 
-- Found BZip2: /usr/lib/libbz2.so (found version "1.0.5") 
-- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.so
-- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.so - found
-- Found Osmium: /home/gdt/SOFTWARE/GEO/osm2pgsql/contrib/libosmium  
-- Found Lua: /usr/pkg/lib/liblua5.2.so;/lib/libm.so (found version "5.2.4") 
-- Boost version: 1.59.0
-- Found the following Boost libraries:
--   system
--   filesystem
--   thread
-- Found PostgreSQL: /usr/pkg/lib/libpq.so (found version "9.3.9") 
Libraries used to build: 
/usr/pkg/lib/libboost_system.so/usr/pkg/lib/libboost_filesystem.so/usr/pkg/lib/libboost_thread.s

Re: [OSM-dev] OSM software repositories -- git and svn

[Greg Troxel]

 this is a discussion/brainstorming about if and how to get rid of
  what remains of the OSM project SVN.

I think your points about what's nice about the openstreetmap svn are
valid.  A few thoughts

1) git != github

osm could host a git repo  and allow the same set of people who can
write to svn to push to it.

2) the github model is not universal

github works by everyone having their own repository, and only
permission to write to it, while anyone can read anything.  This is good
because it enables people you don't even know exist to easily publish
changes, but it sort of forces one collaboration style.  There can be
organizational repos, but those seem geared to having a small set of
people accept changes rather than mirroring how svn or cvs works.

3) in-tool changes by unauthorized people

I think the most important thing about git for free software is that
people who haven't been given write permission can make changes in a
form that is entirely suitable for merging.   A change is more than a
patch; it's also the commit message.

4) discovery is a human organization issue more than a tool issue

I see your point about running ls in the svn checkout.  But the other
side of the coin is that the svn tree is a mess with respect to
tag/trunk/branches so that you can't reasonably check it out.

It seems usueful to have something, which could be a wiki page or a
short file, that has pointers to a curated set git repositories or
tools.

5) place for little scripts

It may make sense to have an official osm-misc git repo, in which many
people can put random little bits that are insufficient to merit a
top-level project.  I don't see how svn vs git really matters here,
except that increasingly people have learned git first and don't want to
deal with svn.


I have been using git on a project at work for about 4 years, and we
have a central repository (the git term is "official repository").
Everyone fetches and pushes from this official repository, and it
contains by definition the authoritative version.   So it's not really
so different than svn, except that the branching model doesn't cause
pain, and people can do things offline.   So really I'm suggesting
moving to git without giving up on shared-write official repos.





pgp7RPfPX7SGU.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Renderer issue: highway=service and service=driveway?

[Greg Troxel]

Pierre Béland  writes:

> In this particular case, if there was a hierarchy of roads, it would
> be less a problem if the rule that I proposed was followed. See
> https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa

I think the notion of having primary/secondary be about importance makes
sense.  It may be better to try to tag with a characteristic distance to
avoid quantization and arguing.

First, set motorway aside.  We know what the motorway rules are, and all
motorways are important (to first order).  Then, in a non-motorway
world, you can ask "what is the shortest typical distance for which many
routes will use this road".  Essentially, I'd argue that (if one decides
to not use motorways), primary highways are likely to be the roads
chosen for distances of 200km or more.   Secondary for perhaps 50 km,
and many of the roads that feel like they should be tertiary are used to
get to the next town, or next next town, but not 10 towns (except as
local feeders, not a through route).  So that's more like 20 km.

However, this breaks down in the city (calling only those roads
tertiary); consensus is to have far more tertiaries.  My sense is that a
road is properly tertiary if it takes you from one place of 5000 people
to another place of 5000 people.

However, this population-based argument is a) not really important in
the areas we are talking about and b) not related to showing roads at
low zoom.

So maybe roads should be tagged with a typical_distance tag, inferred
From class, and that can be used to render.

I realize this needs a lot more thought.


> An automatic rendering rule will not take care of these particular
> contexts. Distance could be one rule, or absence of roads.

I don't follow the "will not take care of".  We are basically talking
about automating the judgement of the cartographer.


pgp4yc3XYiH0Q.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Renderer issue: highway=service and service=driveway?

[Greg Troxel]

Martin Koppenhoefer  writes:

> service roads are there, it is only the driveways which are
> (deliberately I guess) rendered only in high zooms.

I think the real issue is that what should be rendered at highish zoom
is complicated.  For a footway that only goes 20m, having it disappear
fairly soon makes sense.  But a 3 km footway through a forest is far
more important.  Same for driveway, which is not really that inferior to
"service road", but is more important than "parking_aisle".

So to really do this right, I think some notion of characteristic
distance of the way needs to be calculated, and that used in the
suppression decision.


pgpYwiMqxtSQ7.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM 2 Oracle

[Greg Troxel]

Amir Pourabdollah  writes:

> I need help in converting OSM data into Oracle Spatial (direct, no 
> stop-overs!)
> As far as I found so far, the
> ogr2ogr converts to Postgres but
> does not have Oracle output format. Can this be used or adopted for
> Oracle? Any experience?
> Also FME and GoLoader seems to do the conversion straight into Oracle,
> but I have not tried. Any idea?
> Again, this Java tool also exists:
> http://www.ciss.de/openstreetmap-oracle-konverter.html has anybody
> tried this?
> Any idea will be a great help.

(It isn't surprising that there would be far worse support for
proprietary databases, as few people are in a position to use them.)

I would guess that the interfaces to Oracle Spatial are not so different
From the postgis interfaces, and that you would be able to extend the
various tools that load into postgis (in support of mapnik rendering)
without extreme effort.

  http://imposm.org/docs/imposm/latest/

  http://wiki.openstreetmap.org/wiki/Osmosis


Are you trying to store the entire dataset in the schema used by the
rails port, or the schema used by mapnik, or a reduced set for your
analysis, or ?


pgpQvoF3rAj1b.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM on BlackBerry

[Greg Troxel]

  http://wiki.openstreetmap.org/wiki/Tile_usage_policy

I have always found it odd that it seems acceptable for
non-Free/Open_Source software to use tiles from osm servers.   Am I
really reading that correctly?



pgpc3pHlzddAQ.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Rendering of "surface"

[Greg Troxel]

Besides the "show everything you can" vs "clean" approaches, I think
there is a "topo map" vs "web map" difference in approach.  I'm not sure
if it's a coincidence or due to cooperation, but Ordnance Survey topos
and USGS topos look fairly similar.  I've long looked at the USGS topos
as really nice maps worthy of emulation.  On those, dirt roads are shown
in a thinner line.  Making the casing dashed sounds quite sensible.

In my town, there are only a few dirt roads, but knowing if a road is
dirt of paved is important to normal people looking at maps.   So I think
the default rendering should show roads
(highway=primary/secondary/tertiary/unclassified/residential/service)
that are marked unpaved.  Probably more can be done, but just making the
casings dashed on those would be a large fraction of the benefit without
much downside.



pgprzQYz4p0jH.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.

[Greg Troxel]

Frederik Ramm  writes:

> OSM already has a git repository but this is currently only used for
> the rails port - where I have to admit it makes some sense, as the
> rails port software happens to be more controlled than other stuff in
> that the admins must closely watch what gets deployed on our main
> servers.

But having a separate SVN repo, or a separate acl on part of the svn
namespace would do this too.  Once you're setting up new, though, I too
would choose git over svn because a DVCS has a lot of advantages.

>> The key question, as with svn or anything else, is who is allowed to
>> make changes to the official repo.  With git, integrating work done
>> by those not on the list is easier, which may tend to have people
>> chooes to make the authorized committer set smaller.
>
> ... as I explained in another mail to Stefan, it always seemed to me
> that the git world is more control-freakish which probably stems from
> what you say above; if you can tell every would-be commiter to use his
> private repo then you can afford to be.

True.  Ask "in a project, when do you decide to hand out commit bits?"
There's always a risk of people doing things you wish they wouldn't,
plus a cost of time to review/integrate and the cost of work that isn't
integrated or just doesn't happen.  So there's a tough judgement call.
Most projects with centralized repos tend to apply a "when it's more
work to review/apply their work than it would be to clean up from their
mistakes, and when we feel comfortable about their judgement" kind of
test.

git changes this calculus, because review/apply comes down to 

  # normal update procedure
  git branch master
  git pull

  # set up to take changes from johndoe
  git add remote johndoe http://blahblah
  # grab all feature branches from johndoe and everyone else
  git remote update -p

  # study change
  git log -p origin/master..johndoe/feature-foo
  # merge it
  git merge johndoe/feature-foo
  # test
  [do testing]

  # send the changes to the world
  git push

which after you've done it twice is almost entirely the real work of
reading the diffs and testing (and just believing people is less of a
leap than giving them commit access), with almost no effort in patching
-- plus the attribution/date of the original feature branch is preserved
without any real work.

Given this, the rational choice for when to give out commit bits shifts
slightly in the direction of waiting a little longer.

>> One of the things that I found on my project was that some people who
>> were used to git said "every person should have a public repo on the
>> server".  I said that I didn't want that, and no one was able to come up
>> with a good reason for per-person repos, because the real motivation to
>> have a personal one is that you aren't allowed to write the official
>> repo.
>
> So maybe there *is* a way to have the best of both worlds yet.

I think there is.  Basically (very broad brush here, without
justification), switch to git, but be thoughtful about the cultural
norms and access control model.  I'm surprised to find myself being such
a git advocate - I really didn't start out that way before my trade
study and use of it.

One thing that isn't obvious is that SVN is better about acls (because
you can use authz to give different people access to different parts of
an svn repo) but git is better at offline use and work by
non-committers.  The nature of DVCS where you get the entire repo state
is inconsistent with less-than-single-repo *read* access control, and
fine-grained write control appears to be messy and not done in practice.
So I think to get svn-style acls and a distributed system, you need 1
git repo per acl domain, and then a multi-repo setup to manage it.



pgpoAsTmFNBUq.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.

[Greg Troxel]

Scott Crosby  writes:

> On Sun, Oct 17, 2010 at 2:40 PM, Greg Troxel  wrote:
>
> I think what's going on now is that we have a svn repo that git weenies
>> don't particularly care for, and no git repo support on osm servers, and
>> that people are therefore basically setting up git repos elsewhere for
>> various pieces and perhaps not all that concerned about making the svn
>> repo be the authoritative source.  I believe that the git-svn tools ease
>> putting git commits back into svn, so it's probably just as well that
>> a git user with svn access use them.
>>
>
> I'm sorry. I didn't intend to trigger this whole event. The only reason I
> used git was for my own convenience and that I didn't feel comfortable
> asking for a SVN account when I started out.
>
> I feel the binary code belongs in OSM's authoratitive SVN repository and I
> think Stefan's code should merged in with my package.

No worries - this is a useful, civil discusion that I think will be
positive for OSM.  And I should apologize for being a bit overassuming
about what others have done - I meant to characterize general trends
rather than any particular person's motivation/action, and my words
didn't quite line up with that.


pgpWqbDuU3idA.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.

[Greg Troxel]

Frederik Ramm  writes:

I've been the chief SCM crank at work for close to 15 years.  We used
CVS exclusively for a long time, and I didn't allow people who said "foo
is shiny this week; we should switch" to change our world because none
of them could answer the challenge of "prove foo is stable and we'll be
comfortable getting bits back out of it for 10-20 years" until fairly
recently.  We started using svn in 2007 and in 2010 started a very large
project in git.

This is a bit lengthy, but I was a git skeptic for a long time mostly
because a lot of people seem to say/mean "I haven't listened enough to
understand your problem but the answer is that you should use git."
I've recently gone through a trade study to choose a VCS for a hairy
project, and ended up with git.  So I can understand a bit of where
those people are coming from.

> I don't like git, and I especially dislike github (not using
> sourceforge either); but that's a personal thing, so don't let that
> discourage you from continuing to use it for development. I'll just
> make sure every now and then that there is a working version in SVN.

I can certainly see the point of avoiding free-as-in-beer services with
non-free-as-in-speech toolsets and changeable procedures.  But I think
that's orthogonal to tool choice, and OSM seems to have resources to
host a VC server.

> (My dislike of git stems largely from ignorance and is likely to
> vanish over time. At the moment I have grown used to the one-stop-shop
> that is our SVN; with git I miss the option to say "check out all OSM
> projects", as well as the option to commit to trunk for all OSM
> projects without first signing up to external services and/or find out
> who the maintainer is and ask them for permission.)

You are conflating two separate things, which is the nature/capabilities
of the tool itself and the cultural norms that typically are associated
with the tools.  I've recently been through this and found that the
git-using community does have notions that are separable from tool
issues, and I think your objections boil down to "I don't like the way
people who like git tend to do things" much more than "git isn't a good
tool" (and I basically agree with you).

Git culture has a notion of every person having a public repository,
with very limited commit privileges on the official repository.  This is
just culture, and not forced by git.  On my project, we have a machine
with the official repository, and everyone on the project can both check
out that repository and push to it (over ssh).  So from an access
control point of view, it is exactly like SVN.  The norms of who can
change what bit of code with or without are handled just as in SVN, by
social pressure outside the tool.

I find the current osm SVN to be problematic, because there are a
collection of various things in it (which is fine) but there is not a
uniform structure for the trunk/tags/branches (TTB) levels.  In my svn
repos at work, we basically require that each module foo have TTB below
it, and thus all URLs look like /foo/trunk/README.foo.  We have a
CHECKOUT-ALL script which grabs foo/trunk/ to foo, so one sees the
logical structure in a checkout, and can svn switch to branches per
module.  svn lets you do this, but it doesn't make you, and it's easy to
make a mess if you don't follow a rule like mine.

So I don't understand how you can say "one stop checkout", because I
find that if I checkout the whole tree I get vast amounts of old
branches and tags that take up rather a lot of space and make a huge and
messy working copy.

In git, branching and access control can only be done on the whole repo,
so people (reasonably) put separate chunks of code in separate
repositories, rahter than using separate namespaces and perhaps authz in
svn.  git's weakness is that the ways to gie those separate repos
together are all not entirely satisfying (submodules, android's repo
script).

Consider if OSM used git, and for each logical thing in SVN there was a
git repo on git.openstreetmap.org, but that all users with a commit bit
could push to all repositories.  Then with osm-cm repository that has a
script CHECKOUT-ALL that clones/updates every single repository on the
list (sort of recreating android's repo script) you have basically
recreated the svn cultural norms with another tool.

git has two basic advantages over svn: offline use and dealing with
unprivileged users.  I have found the offline part useful, where I have
full history and can make commits that I later push.

Git also supports people who can't write to the official repository
cloning and making local commits anyway.  This is better than svn for
two reasons:

  people can keep their local changes in the tool, and keep merging
  upstream.

  people can publish their changes via format-patch or making a repo
  available, and then those than can write to official can grab their
  changes staying entirely within the tool - it's much easier than
  patches in email, an

Re: [OSM-dev] Map of Seattle

[Greg Troxel]

[This probably belongs on a user list, not dev.]

  I'm trying to get an OSM xml file for Seattle however whenever I try
  requesting it from OpenStreetMap.org's "Export" tab it says that the request
  is too big. I don't want to use planet.osm because that's far too large for
  the application I need. Any suggestions?

  The corner coordinates I'm looking are between:
  47.979, -122.686
  47.346, -121.522

Cloudmade has extracts by state, which are pretty manageable:

  http://downloads.cloudmade.com/north_america/united_states/washington

you can then use osmsosis to shrink it if it isn't small enough.





pgp4asPwFQVfN.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] How to support name:* in MapOSMatic?

[Greg Troxel]

  We would like to support multiple names for a given street: name:fr,
  name:ar, etc. As far as I have understood, we could configure
  osm2pgsql to create columns "name:fr", "name:ar", etc. and change our
  SQL requests to use those columns. That does not seems very scalable.

  The ideal configuration would be to have all names (name:fr, name:ar,
  ...) into a single "name" column and use it. Or have a kind of couple
  (name, country_code) that would store all different names for a
  street. But I don't know how to do this.

Not well thought out, but:

  add a name table

id(SERIAL), name(lang), name(text)

  for each such named object, get a new SERIAL in the name table, and
  add in all of the language/value pairs

  put the id in the main database



pgpDWLmvFNWAv.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Trouble with osm2pgsql and Postgres 8.4, Postgis 1.4

[Greg Troxel]

Despite what apple claimed, OS X 10.6 was a major change that flipped
the default toolchain to making 64-bit (amd64) binaries by default
instead of 32-bit (i386) binaries.  pkgsrc (www.pkgsrc.org) recently
added support to force 32-bit mode.  It may be that you are having a mix
of 32 and 64.



pgp5ZLILDUzi2.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] CloudMade OSM download problems

[Greg Troxel]

  Anyone else have issues with the latest .OSM extracts from CloudMade?

  I've tried importing Pakistan and California locally, and both files
  have references to nodes that aren't present.

  Fortunately GeoFabrik has a Pakistan extract that works. If anyone can
  help with a California extract, that would be super.

I have been trying to build garmin maps with the massachusetts extract,
and am having trouble.  There appear to be ways with same-coord points
in odd ways that mkgmap's --remove-short-arcs doesn't handle, and I
can't get the maps to load in Garmin RoadTrip (mac).  The .img works on
a vista hcx, but routing won't work (even though I used --route).  I
don't understand what is going on yet.


pgp5H6gVQer2G.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Minute Diffs Broken

[Greg Troxel]

Brett Henderson  writes:

>> Given the way the world is, it seems like the minute diffs really should
>> be looking for new transactions, not new changesets.  I can see
>> Frederik's point of only exporting closed changesets, but for that to
>> really make sense I think the main database has to isolate changesets
>> From each other until they are fully committed (meaning either
>> long-running transactions or an API change to have an API operation be
>> open/upload/close) -- trying to add transaction properties on a copy
>> when they aren't there in the original seems like it just won't work.

> Just to be clear, osmosis isn't looking for new changesets or
> transactions, it is just looking for entities that have been modified
> within a specific time period.  It doesn't know what an API changeset
> or database transaction is.  Perhaps it should be looking for
> transactions (although I don't see how that will solve anything yet)
> but that is not currently the case.

Given the use of pgsql transactions, osmosis won't see data from
uncommitted transactions.  So I really meant "changes in the database,
subject to the notion that uncommitted transactions won't be visible."

> I'm still against the idea of minute diffs being a "collection of
> changesets".  The "collection of uploads" is closer to the mark,
> although uploads are just an API convenience, they have no
> representation in the database and have no meaning to osmosis.  minute
> diffs are really a minimal diff to get from one point in time to
> another.

I agree.  Having looked at the schema, I don't see how osmosis can
extract a diff (meaning some data that can be replayed into a copy of
the database) without support for what is essentially a journal.  Just
looking at nodes, the nodes table doesn't seem to quite be a journal for
the current_nodes table.

> To complicate things slightly further, the full history files
> http://planet.openstreetmap.org/history/
> are similar but complete a full delta from one point in time to
> another and may contain several versions of a single entity.
>
> So perhaps the term "diffs" is the right one for the existing files
> and "deltas" is the right one for full history files.

I would hope that both have the property that if a copy of the DB that
was right at the earlier time, then applying delta or diff to that copy
gets one a copy of the database as of when the osmosis extract
transaction ran.  Perhaps then the delta has the intermediate steps and
the diff is permitted to collapse them?

> The reason I've tended to avoid the word "diffs" is because the planet
> directory also contains diffs between planet files.  These diffs are
> yet another way of describing changes/differences and are truly a
> difference between two planet files.

As in the output of the diff command on two text files which happen to
contain xml, it sounds like.

> If you're not familiar with it already, please check out the API
> schema.  If information isn't stored there, we can't query it.  For
> example, there is no concept of an upload in the database, the only
> grouping feature it has is changesets.
> http://gweb.bretth.com/apidb06-pgsql-latest.sql

Thanks - read and sort of understood - there's a lot in there.


pgp5KFPSNh2f2.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Minute Diffs Broken

[Greg Troxel]

  My aim all along has been to provide people with up to date data.  The 
  nice thing about the minute changesets is that they let you have an 
  offline database that exactly matches the API as of 6 minutes ago.  I'd 
  completely agree with you if the API only released data once the 
  changeset was closed but that's not the case.

I am a bit confused by some of the terms being used here.  The basic
issue for me is that we have API operations, which correspond to
database transacations.  Ignoring SERIALIZABLE vs READ COMMITTED, these
operations are quite safe.  These operations are not changesets.

Here are logs from squid, showing me querying data and upoading some changes.

1241488036.615   5688 172.16.32.240 TCP_MISS/200 38363 GET 
http://www.openstreetmap.org/api/0.6/map? - DIRECT/128.40.58.203 text/xml
1241488089.540276 172.16.32.240 TCP_MISS/200 661 GET 
http://www.openstreetmap.org/api/capabilities - DIRECT/128.40.58.203 text/xml
1241488099.552312 172.16.32.240 TCP_MISS/200 373 PUT 
http://www.openstreetmap.org/api/0.6/changeset/create - DIRECT/128.40.58.203 
text/plain
1241488102.378   2817 172.16.32.240 TCP_MISS/200 656 POST 
http://www.openstreetmap.org/api/0.6/changeset/1081606/upload - 
DIRECT/128.40.58.203 text/xml
1241488102.570163 172.16.32.240 TCP_MISS/200 366 PUT 
http://www.openstreetmap.org/api/0.6/changeset/1081606/close - 
DIRECT/128.40.58.203 text/html

So there are one read and then three write database transactions, and
one changeset.  The read is not hard and the writes all happens close in
time (JOSM), but it won't necessarily be so.

Given the way the world is, it seems like the minute diffs really should
be looking for new transactions, not new changesets.  I can see
Frederik's point of only exporting closed changesets, but for that to
really make sense I think the main database has to isolate changesets
From each other until they are fully committed (meaning either
long-running transactions or an API change to have an API operation be
open/upload/close) -- trying to add transaction properties on a copy
when they aren't there in the original seems like it just won't work.

This is also confusing in wording because in svn changeset is a
transaction, and it's not just SERIALIZABLE but actually SERIALIZED, so
the word changeset can have a wrong connotation.

I think we have

  uploads == db transactions (perhaps "microchangesets" of "changeset 
fragments"??)

  changesets == (some group of uploads, with a common id and comment)

  minute diffs == (some collection of uploads)

or maybe we will have

  minute diffs == (some collection of changesets)

but in that case the db created by the minute diff may refer to objects
which are not present, breaking the integrity guarantees that 0.6 got
us.

I don't have a clue about how the uploads are numbered and how easy it
is to extract all of them, but given that the main DB can have committed
transactions with uploads that are not part of a closed changeset, I
think the minute diff and replicated dbs should have that too.




pgpPigSmpDlzB.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Minute Diffs Broken

[Greg Troxel]

Sorry, I was assuming that a changeset and a database transaction were
the same thing.  If not, we need a sequence number on additions to the
history table, and use that for knowing what's fresh.



pgpgVUHBSeHce.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Minute Diffs Broken

[Greg Troxel]

Frederik Ramm  writes:

> Hi,
>
> Greg Troxel wrote:
>> So obviously we aren't running "SET TRANSACTION ISOLATION LEVEL
>> SERIALIZABLE", since that would kill performance and make things harder,
>> but it would solve this :-)
>
> How so? The problem seems to be too much transaction isolation, not
> too little.

With select by time, it would still be buggy.  But if the select was
"all changesets > X" where X was the highest changeset in the previous
select, it would work, because there would have to be a total ordering
of transactions (at least as far as anyone can tell).  So the select of
highest would have to be in between two others, and the changeset id is
perhaps an auto-sequence, or else read/increment/write which again would
force ordering.

> If we were operating on a "dirty read" basis then Brett's
> diffs would not miss any data (but they would contain changes that
> were part of a transaction that was later rolled back).

Sure, that would be worse :-)


pgpx79Po7aJlP.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Minute Diffs Broken

[Greg Troxel]

openstreetmap-...@scd.debian.net writes:

> Would this work?
>
> How about the situation:
>
> Changeset A creates a node
>
> Changeset B uses the node in a way
>
> Changeset B closes
>
> (Later) Changeset A closes

Transactions are intended to avoid this.  It may be that the changeset B
transaction shoudl be reading the node, in which case pgsql should
prevent the commit of changeset B until A is closed.  Or more likely B
could not see the node in changset A until A commits - this is the READ
COMMITTED property, or the avoidance of "dirty reads".

Have you seen this?


pgpxskewiGmrX.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Minute Diffs Broken

[Greg Troxel]

Frederik Ramm  writes:

> 3. Make a semantic change to the way we handle diffs: Let the diff for 
> interval X not be "all changes with timestamp within X" but instead "all 
> changes that happened in a changeset that was closed within X". 
> Changesets not being atomic should pose no problem for this (because 
> when it's closed, it's closed). This would adversely affect downstream 
> systems in that some changes are held back until the changeset is closed 
> (whereas they are passed on immediately now), but on the other hand you 
> could afford to generate the minutely diff at 5 seconds past the minute 
> because you do not have to wait for transactions to settle (the actual 
> changeset close never happens inside a transaction).

So obviously we aren't running "SET TRANSACTION ISOLATION LEVEL
SERIALIZABLE", since that would kill performance and make things harder,
but it would solve this :-)

It's possible for a transaction with effective time T to have a
commit time of T', and the minute scan for A-B for T < B < T' is not
seeing the changeset, and the B-C minute scan is considering it not in
bounds.

If the real requirement for minute diffs is that the union of them is
right, then having the minute diff generator keep track of all the
changeset IDs it has seen in the last hour, and do a query that is
basically:

  select all changesets from the last 30 minutes
  exclude all changesets in the previous 60 minute diffs

then the missing changeset would show up in the next diff, which would
be the minute it was committed in, not the minute it was started in.  If
it's known there are no holes then changeset > top_changeset could make
this faster.


pgpJICckdH4Xy.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [josm-dev] Combine and Merge

[Greg Troxel]

Russ Nelson  writes:

> Ævar Arnfjörð Bjarmason writes:
>  > If you're rewriting this perhaps you could also make it support
>  > merging two (or more) nodes two the location of a specific node,
>  > currently "merge" will merge to the oldest node, which isn't always
>  > what you want.
>
> I recall that the resultant node used to have the average location of
> both nodes, but now it seems to use the first node listed in the
> "Current Selection" box.
>
> Seems like if you don't like this behavior, 

I found it inconsistent, but what I want (for GNIS cleanup) is to be
able to do something like

  select node I want to keep (location wise)
  control-select node I want to merge into the previous node
  M

(With the GNIS import, there are a lot of existing nodes that are
already in the right place that have been manually edited, and the GNIS
nodes are not placed accurately, but I want the gnis ref tag.)

I don't actually care which node controls the resulting location, but it
seems obvious the first one added to the selection should be it.


pgp9jELk3aoqw.pgp
Description: PGP signature
___
josm-dev mailing list
josm-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [OSM-dev] SVN and individual tag/branch trees

[Greg Troxel]

Frederik Ramm  writes:

> I normally keep the whole SVN tree checked out on all computers I 
> use regularly. But with projects gradually introducing their own 
> branches/trunk/tag structure, this means that I am amassing a lot of 
> stuff. For example, the Osmosis trunk has roughly 1600 files, but
> if you simply check out the whole SVN then you have 8100 Osmosis files 
> due to various tags and branches; same, to a lesser degree, elsewhere.
>
> Is there a way I can tell SVN to "check out everything *except* tags and 
> branches"? Ideally in a way that SVN remembers, so that when I 
> absent-mindedly type "svn update" I'll not get the whole bunch again?

Basically the way our svn is set up is wrong.  There are two standard
svn setups.  One is to have trunk/tags/branches (called TTB) at the very
top level.  Then the granularity of tagging and branching is the whole
repository.  Once you have logically separate things, as we do, this
doesn't make sense.

The other way is to have a set of modules, with every module having a
TTB immediately below it.  A number of the things in the OSM repository
are like this, but it is far from uniform.

When you have the per-module TTB, you then can't simply svn co the whole
repository sanely.  I manage svn for a large group of projects at BBN,
with about 20 people and 40 modules (each with a TTB).  We have a foo-cm
module that only contains svn management scripts and files documenting
rules for the repository, one of which is CHECKOUT-ALL and that
basically has

  REPO=https://machine.domain/svn/foo

  svn co $REPO/module1/trunk module1
  svn co $REPO/extern/module2/trunk module2

Instead of doing update, people re-run CHECKOUT-ALL.  (CHECKOUT-ALL
actually does update instead of co if you are already checked out.)
This lets you stay on a branch if you have run svn switch.  Plus our
CHECKOUT-ALL has tons more complexity about access control and managing
things like linux source that can't be checked out on case-preserving
filesystems; my overall experience is that these situations just keep
getting more complicated, so you really need a script to encapsulate how
to deal.

One of our rules is that TTB points (which sort of define modules) have
to be in a regular structure.  In our case, top-level directories are
modules, except for extern and extern-dist, which are container
directories and otherwise empty, and all subdirs of extern and
extern-dist are modules.  We have a rule that from any file in the repo,
you pass exactly one TTB on the way to the root.

I did a checkout and just ignored the wasted disk space, but a possible
approach is

  define a osm-cm module

  create a repository-structure.txt as
osm-cm/trunk/repository-structure.txt
  that defines where TTB points ought to be

  svn mv various bits so that every module has a TTB.

  create a CHECKOUT-ALL (/bin/sh) script as
osm-cm/trunk/CHECKOUT-ALL
  that grabs everything

At least that's what I would do if it were a project at work that I
became responsible for - there may be reasons I don't understand yet
that this isn't appropriate for OSM, but I think it is.


  
  



pgp1NA47adQQg.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] webservice to collect traffic messages

[Greg Troxel]

 writes:

> I'd like to experiment with Google AppEngine for a bit and
> set up a hosted service to collect traffic messages
> (traffic jams, road obstructions, constructions sites, slow
> moving traffic,...)

I'm not sure how you're intending to use this, but I'm guessing peer
reports of issues from people running open source in-car navigation,
perhaps to the point that driving below expected speeds might trigger
automatic reports.  I would expect you are thinking cellphone data
service, but car-car 802.11 with Disruption Tolerant Networking is also
very interesting.  Perhaps you could describe your goals and use cases.

I realize only some of the people here fall into the paranoid category,
but such reports,sent more than very occasionally, and perhaps even at
all will cause the paranoid to worry.  (Of course we keep our phones off
too :-).  So it would be nice to give some thought to the privacy issues
of anonymous reports together with avoiding false reports.  This is
definitely hard.

Given the privacy worries, google is a bit scary - not sure what the
policy is on use of hosted apps data for targeting ads...

Have you looked at the format specs for TMC:

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

It's not the least bit clear that it's the right thing, but probably
worth glancing at.

> What could be a good data-format for such information, so that
> it is usefull to more then just my own navigator?
> I'm thinking about:
> * required: (enum) event-type
> * required: (string) event-description
> * required: (long) OSM WayID of primary location
> * required: (long) OSM NodeID of primary location

Not sure what you mean by long, but protocols should only use
fixed-width types, so perhaps uint32_t, or perhaps uint64_t to avoid
having to change the protocol when there are more than 4G nodes.  Or
perhaps this is xml so it's just a number.

> * required: (datatime) expiration date of the event

I don't follow this - I would expect a time of report, and perhaps an
expected time remaining.

> * optional: (long[]) additional affected nodeIDs
> * optional: (long[]) additional affected wayIDs

> * optional: (time) expected delay

Presumably this is the number of seconds that travel would take minus
the number it would take under normal time?

> * optional: (string[]) additionalData

for humans?

> Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-)
> applications
> or shall I add required lat + lon + ref/name -attributes?

With OSM ids, one can only generate and use data if one has OSM data
locally, and then only if it's the same version - what if there was an
edit to add/remove ways that didn't really change the map massively
semantically, but changed way ids?

This data could be useful to display without the detailed database.

It would be nice to have this data be useful over long time scales,
looking at the frequency of (reported) trouble.  So using way ids as the
primary key seems like it could be trouble.

I would expect that routing applications have to figure out from
position where one is anyway, so reporting by lat/lon makes sense.
Except in very messy areas with lots of stacked ramps.

So perhaps lat/lon, and an optional way id for disambiguation, but which
can be ignored if it doesn't make sense.


pgptTpNlEQ6rq.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [OSM-legal-talk] Bittorrent

[Greg Troxel]

Frederik Ramm  writes:

> Everything you say is true, but unless you have just joined the project 
> you must be aware that the new license being contemplated - the Open 
> Database License - rests heavily on the European idea of database 
> rights, and tries to supplant them by a contract for jurisdictions that 
> have no "sui generis" database protection.
>
> A contract of course requires agreement by those who are party to it 
> before it can be of legal relevance.
>
> (Maybe you're reading this on dev and are unaware of the 1000+ postings 
> in the previous year on legal-talk about the matter...?)

As a random data point, I read your note on talk but am not subscribed
to legal-t...@.  It would be nice to have a monthly summary of where the
licensing discussion is and a sense of what the debate is posted to
t...@.  It would particularly interesting to see the discussion around
expected impacts to free distribution of planet dumps.  Of course I
could join legal, but I think it's probably good for the health of the
project for everyone to see an abstract.




pgpjcDoM5ukJx.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [bug] direction of GPS traces

[Greg Troxel]

  Everybody can download GPS points for an area, which will include your 
  points, but when they do so they (a) have no idea which user uploaded 
  those points and (b) don't get any timestamp information for the points 
  at all. In addition your points will be mixed up with those of anybody 
  else that has uploaded traces in that area (whether public or not).

In sparsely-traveled areas the set of points has almost as much
information as the ordered trace.  I can see the value, though, so
perhaps private traces should just be labeled as semi-private or
semi-public.



pgp8p9wPJNhq6.pgp
Description: PGP signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev