Re: [Potlatch-dev] [OSM-newbies] Can't see my gps traces in the map or Potlatch2

2012-12-12 Thread Richard Fairhurst

On 11/12/2012 21:36, SomeoneElse wrote:

Sebastian Arcus wrote:

I have uploaded a bunch of gps traces as identifiable. They show up
under See your traces. However, when I click on map or edit I
can't see them on the map or in Potlatch2 editor. Am I doing something
wrong, or is there a temporary problem with the system?

Looking at the GPX file, I can't see anything unusual.

I've cc:ed the potlatch-dev list in case anyone there has any idea why
it may be not showing via Edit.


The XML namespace attribute in the GPX file appears to be... not what 
Potlatch 2 is expecting.


Potlatch 2 expects http://www.topografix.com/GPX/1/1
and the GPX file has http://www.topografix.com/GPX/1.1

Strictly speaking I think this is an error in the NavSys GPS logger 
software you appear to be using. It might be possible to make P2 a bit 
more tolerant, though.


cheers
Richard


___
Potlatch-dev mailing list
Potlatch-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/potlatch-dev


Re: [osmosis-dev] Invalid ways, now with code

2012-12-12 Thread Toby Murray
On Wed, Dec 12, 2012 at 5:22 AM, Paweł Paprota ppa...@fastmail.fm wrote:
 Hi Toby,



 Anyway, thoughts? My changes are on github in the invalid_geometry branch:
 https://github.com/ToeBee/osmosis

 And a diff of all my changes:
 https://github.com/ToeBee/osmosis/compare/master...invalid_geometry


 What about other situations where a way is invalid? For example, this
 results in 'f':

 SELECT ST_IsValid('LINESTRING(1 1, 1 1, 1 1, 1 1, 1 1)'::geometry)

This was touched on in the previous thread a little. The problem is
that there is no direct interaction with the database at this level.
When doing an import, no connection to the database even exists.
Everything goes to a dump file and is then loaded in via a COPY
command. So I can't just call ST_IsValid. Furthermore, I don't see a
way of checking for geometry validity in java. I could maybe do a few
basic checks based on node order and location but I suspect that if I
start touching  nodes at all, there is going to be a huge performance
hit on a planet import.

Also, out of the 3,455 ways with invalid geometries currently in my
database, 3,157 of them are single node ways. So just this simple node
count check eliminates over 90% of invalid geometries. Given the
challenges and costs of doing more exhaustive checking, this seems
like a decent compromise.

My personal goal here is actually to have a database *with* these
invalid ways in it which is currently not possible. Because objections
were raised about how these ways can affect some spatial queries, I am
trying to reduce the impact of them on people who do care about such
things. The new option on the replication task is a big step forward
in this case. I don't think it is currently possible to keep *all*
invalid ways out of the database during an import. If this is really a
requirement, it will need to be done with a query after the database
has been populated.

Toby

___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev


Re: [OSM-dev] Announcing openstreetmap-carto v1.0 (and v2.0!)

2012-12-12 Thread Tom Hughes

On 10/12/12 19:57, Dane Springmeyer wrote:


On Dec 6, 2012, at 7:54 AM, Tom Hughes wrote:


There is already a plan to do a major update on the tile server with an update 
of the OS, a reload of the database and a mapnik update and my suggestion was 
that we should aim to switch to the Carto generated style at the same time. We 
just need to work out the detailed plan and schedule the work.


Let me know how I can help here. On the Mapnik side, we've got a 2.1.x branch 
(which is a stable series) coming together nicely (current Mapnik master is 
targeting 2.2). A 2.1.1 release is planned within the next month  - the only 
real work remaining is carefully choosing which additional bugfixes to 
back-port from Mapnik master.


Well one thing that would be really nice (to follow up on Andy's enquiry 
on the mapnik list just now) would be to have a version with the 
harfbuzz work merged, which should allow us to close a load of tickets I 
think...


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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


[OSM-dev] osm2pgsql Windows build

2012-12-12 Thread Dominik Perpeet
Would anyone be interested in a current osm2pgsql Windows build (Win32 +
x64, both with 32 bit id space)?
In the near future I will link the zipped binary package on the wiki:
http://wiki.openstreetmap.org/wiki/Osm2pgsql

I recently needed a Windows version of the program and had to compile
it. Needless to say, it took me a rather large part of an evening to
accomplish. ;-)

Version: b31c660 (git, Oct 28, 2012)
Built using:
- geos 3.3.5
- libxml 2.9.0
- pgsql 9.2.1
- proj 4.8.0
- proto_buf 0.1.5
- zlib 1.2.7

NOT included:
- gazetteer
- shell prompt
- null output
- libgen
- pthread (obviously fork() doesn't work on windows and I didn't
want to get into making the code thread-safe)

In order to compile the C99 code, I used the Intel Compiler. I
successfully compiled Win32 and x64 versions and imported current osm
planet pbf's. Mapnik rendering (current version) appears to work fine
with the created databases.
The rather extensive changes and inclusion of dependencies into a
solution prevent me from committing the resulting source. If there is
serious interest, I can cobble together a brief description of what I
did and share my VS2010 solution.

Is anyone against switching to C++ (see osm2pgsql TODO)? In my opinion
it would result in cleaner code and make building on windows a lot
easier. Also, fork() could be replaced with omp if the effects are
sorted out carefully.

Dominik Perpeet



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


[OSM-dev] Carto-based Mapnik OSM Rendering

2012-12-12 Thread Ian Dees
Hi all,

With some help from the MapBox folks I set up a layer on the OSM US server
that renders from a recent version of the openstreetmap-carto stylesheet
[0] converted to Mapnik XML:

http://tile.osm.osuosl.org/tiles/osm_carto/preview.html#15/41.8813/-87.6299

You can compare this with a (semi-old) version that comes from the existing
Mapnik XML-based stylesheet the Carto one is based on:

http://tile.osm.osuosl.org/tiles/osmus/preview.html#15/41.8813/-87.6299

This server isn't the fastest thing in the world so please don't hammer it
to death. Feel free to use it to help improve the carto-based stylesheet
though! I'm happy to update the stylesheet at any time.

-Ian

[0] https://github.com/gravitystorm/openstreetmap-carto
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] Carto-based Mapnik OSM Rendering

2012-12-12 Thread Tom MacWright
Hey,

To make it a bit easier to compare, here's the two on a split screen:
http://bl.ocks.org/d/4271706/

From a cursory scan, there are some labelling and font changes (mostly for
the better, in my opinion) and a possible bug around the coloring of the
botanical garden.

Tom

On Wed, Dec 12, 2012 at 4:03 PM, Ian Dees ian.d...@gmail.com wrote:

 Hi all,

 With some help from the MapBox folks I set up a layer on the OSM US server
 that renders from a recent version of the openstreetmap-carto stylesheet
 [0] converted to Mapnik XML:

 http://tile.osm.osuosl.org/tiles/osm_carto/preview.html#15/41.8813/-87.6299

 You can compare this with a (semi-old) version that comes from the
 existing Mapnik XML-based stylesheet the Carto one is based on:

 http://tile.osm.osuosl.org/tiles/osmus/preview.html#15/41.8813/-87.6299

 This server isn't the fastest thing in the world so please don't hammer it
 to death. Feel free to use it to help improve the carto-based stylesheet
 though! I'm happy to update the stylesheet at any time.

 -Ian

 [0] https://github.com/gravitystorm/openstreetmap-carto

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


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


Re: [OSM-dev] Carto-based Mapnik OSM Rendering

2012-12-12 Thread Alex Barth
Again, this is awesome to have this up.

If you find issues, please file here 
https://github.com/gravitystorm/openstreetmap-carto/issues

Or fork, fix and issue a pull request :-)

And really, on a first glance there is very little difference. Just filed one 
for leisure=garden

https://github.com/gravitystorm/openstreetmap-carto/issues/6

On Dec 12, 2012, at 4:15 PM, Tom MacWright t...@macwright.org wrote:

 Hey,
 
 To make it a bit easier to compare, here's the two on a split screen: 
 http://bl.ocks.org/d/4271706/
 
 From a cursory scan, there are some labelling and font changes (mostly for 
 the better, in my opinion) and a possible bug around the coloring of the 
 botanical garden.
 
 Tom
 
 On Wed, Dec 12, 2012 at 4:03 PM, Ian Dees ian.d...@gmail.com wrote:
 Hi all,
 
 With some help from the MapBox folks I set up a layer on the OSM US server 
 that renders from a recent version of the openstreetmap-carto stylesheet [0] 
 converted to Mapnik XML:
 
 http://tile.osm.osuosl.org/tiles/osm_carto/preview.html#15/41.8813/-87.6299
 
 You can compare this with a (semi-old) version that comes from the existing 
 Mapnik XML-based stylesheet the Carto one is based on:
 
 http://tile.osm.osuosl.org/tiles/osmus/preview.html#15/41.8813/-87.6299
 
 This server isn't the fastest thing in the world so please don't hammer it to 
 death. Feel free to use it to help improve the carto-based stylesheet though! 
 I'm happy to update the stylesheet at any time.
 
 -Ian
 
 [0] https://github.com/gravitystorm/openstreetmap-carto
 
 ___
 dev mailing list
 dev@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev
 
 
 ___
 dev mailing list
 dev@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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


Re: [OSM-dev] osm2pgsql Windows build

2012-12-12 Thread Dane Springmeyer
Dominik,

Great work - thanks for sharing. Jhuntley (on #osm irc and 
https://github.com/onepremise) has also been working on getting a build going 
recently.

You two might want to share notes. He's tried both the cygwin and mingw routes.

I made a failed attempt at msvc 2010 a while back. Never thought about the 
intel compiler for C99 on windows. Clever.

Capturing your notes + adding a link to your project files would be great.

Also, we should coordinate getting relevant patches in for easy stuff. +1 to 
more C++ to work around C99 issues.

In the end I think the most critical thing is documentation of a process that 
works, no matter how messy.

Dane


On Dec 12, 2012, at 10:01 AM, Dominik Perpeet wrote:

 Would anyone be interested in a current osm2pgsql Windows build (Win32 +
 x64, both with 32 bit id space)?
 In the near future I will link the zipped binary package on the wiki:
 http://wiki.openstreetmap.org/wiki/Osm2pgsql
 
 I recently needed a Windows version of the program and had to compile
 it. Needless to say, it took me a rather large part of an evening to
 accomplish. ;-)
 
 Version: b31c660 (git, Oct 28, 2012)
 Built using:
- geos 3.3.5
- libxml 2.9.0
- pgsql 9.2.1
- proj 4.8.0
- proto_buf 0.1.5
- zlib 1.2.7
 
 NOT included:
- gazetteer
- shell prompt
- null output
- libgen
- pthread (obviously fork() doesn't work on windows and I didn't
 want to get into making the code thread-safe)
 
 In order to compile the C99 code, I used the Intel Compiler. I
 successfully compiled Win32 and x64 versions and imported current osm
 planet pbf's. Mapnik rendering (current version) appears to work fine
 with the created databases.
 The rather extensive changes and inclusion of dependencies into a
 solution prevent me from committing the resulting source. If there is
 serious interest, I can cobble together a brief description of what I
 did and share my VS2010 solution.
 
 Is anyone against switching to C++ (see osm2pgsql TODO)? In my opinion
 it would result in cleaner code and make building on windows a lot
 easier. Also, fork() could be replaced with omp if the effects are
 sorted out carefully.
 
 Dominik Perpeet
 
 
 
 ___
 dev mailing list
 dev@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev


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


Re: [OSM-dev] osm2pgsql Windows build

2012-12-12 Thread Dominik Perpeet
Thanks for your feedback. I'll see to getting the documentation up soon. Do
you know whether Jhuntley got a 64 bit build running? A 32 bit build wasn't
feasible for me, since the machines I run osm2pgsql on have plenty of RAM.

Once I post my project files, someone else can check if they want to merge
the stuff with trunk (I put all my changes inside #ifdef WIN32 wrappers).

Instead of doing that, I'd rather migrate the code to C++ with inheritance
of an abstract base class instead of function pointer structs. With those
removed, omp instead of fork, and some other minor changes, the code should
compile cleanly with msvc as well.

Dominik

2012/12/13 Dane Springmeyer d...@dbsgeo.com

 Dominik,

 Great work - thanks for sharing. Jhuntley (on #osm irc and
 https://github.com/onepremise) has also been working on getting a build
 going recently.

 You two might want to share notes. He's tried both the cygwin and mingw
 routes.

 I made a failed attempt at msvc 2010 a while back. Never thought about the
 intel compiler for C99 on windows. Clever.

 Capturing your notes + adding a link to your project files would be great.

 Also, we should coordinate getting relevant patches in for easy stuff. +1
 to more C++ to work around C99 issues.

 In the end I think the most critical thing is documentation of a process
 that works, no matter how messy.

 Dane

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