[osmosis-dev] bounding-box does not support data provided by default pipe

2010-06-11 Thread Oliver Schrenk
Hi,

I'm trying to extract some data from old planet.osms
ftp://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/planet-070613.osm.bz2

using
bzcat $(MAPS.OSM)/planet-080611.osm.bz2 | $(TOOLS.OSMOSIS) --read-xml 
enableDateParsing=no file=/dev/stdin --bounding-box top=$(TOP) left=$(LEFT) 
bottom=$(BOTTOM) right=$(RIGHT) --write-xml file=080611.osm

where $(TOOLS.OSMOSIS) is replaced with the path to 0.35.1

Task 2-bounding-box does not support data provided by default pipe stored at 
level 1 in the default pipe stack.
at 
org.openstreetmap.osmosis.core.pipeline.common.PipeTasks.retrieveTask(PipeTasks.java:157)
at 
org.openstreetmap.osmosis.core.pipeline.common.TaskManager.getInputTask(TaskManager.java:165)
at 
org.openstreetmap.osmosis.core.pipeline.v0_6.SinkSourceManager.connect(SinkSourceManager.java:51)
at 
org.openstreetmap.osmosis.core.pipeline.common.Pipeline.connectTasks(Pipeline.java:74)
at 
org.openstreetmap.osmosis.core.pipeline.common.Pipeline.prepare(Pipeline.java:116)
at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:79)
at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
at org.codehaus.classworlds.Launcher.main(Launcher.java:31)

I suspect this is because the planet-070613.osm.bz2 is 0.3 API.

Has 0.3 been deprecated/removed? Can I use an older version for extracting bb 
from 0.3 maps? What's the case for 0.4 maps?

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


Re: [OSM-dev] OSM diagram usage

2010-06-11 Thread Maarten Deen
On Fri, 11 Jun 2010 09:32:51 +0200, Rodolphe Quiedeville
rodol...@quiedeville.org wrote:
 Ævar Arnfjörð Bjarmason a écrit :
 On Thu, Jun 10, 2010 at 20:58, Rodolphe Quiedeville
 rodol...@quiedeville.org wrote:
 Jeffrey Warren a écrit :
 Hi all - i'm writing about OSM and was wondering if I could use the
 diagram at:

 http://wiki.openstreetmap.org/wiki/File:OSM_Components.png

 It's not marked as CC or anything. Would whoever owns it mind
releasing
 it or giving permission? Thanks much!
 Hi,

 At the page bottom you can read 'Content is available under Creative
 Commons Attribution-ShareAlike 2.0 license.' So the document is under
 CC.
 
 That's for content, but doesn't apply to images unless otherwise
 stated. At least that's the default MediaWiki convention.
 
 So we have to be more explicit, why images are not content ? I'm
 surprised by that :)

I'm a bit surprised we don't have the elaborate summary that wikipedia
images have. Like
http://en.wikipedia.org/wiki/File:Cambridge-Openstreetmap-08-06-13.svg

Maarten


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


[OSM-dev] osm2pgsql diff mechanics

2010-06-11 Thread Michael Kussmaul
Hi,

I plan to do osm2pgsql diffs on my PostgreSQL setup. For my use-case it is 
important that all geometry data is valid, so after the initial import I do a 
cleaning of all non-valid geometry data (self-intersection, ...). 
Now my question: If I cleaned a geometry (e.g. forest) and a diff specifies a 
change in this geometry, what will happen? 

1.) Will the geometry completely be replaced by the new geometry as specified 
in the diff.
2.) Will the geometry be messed up, because the diff expects a different 
original geometry and now just applies a patch.
3.) Diff will fail, because it expects something different in the original 
geometry.
4.) ...

For my use-case 1.) would be the best, because I could then do a re-cleaning 
after each diff-import.

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


Re: [OSM-dev] osm2pgsql diff mechanics

2010-06-11 Thread Lennard
 Now my question: If I cleaned a geometry (e.g. forest) and a diff
 specifies a change in this geometry, what will happen?

 1.) Will the geometry completely be replaced by the new geometry as
 specified in the diff.

As far as I expect it to work: The diff will be applied to the slim mode
tables (_nodes, _ways, _rels) and then a new geometry will be built and
added/updated in the applicable geometry tables (_point, _roads, _line,
_polygon).

-- 
Lennard


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


Re: [OSM-dev] osm2pgsql diff mechanics

2010-06-11 Thread Jukka Rahkonen
Michael wrote:

 Hi,

 I plan to do osm2pgsql diffs on my PostgreSQL setup. For my use-case it is
 important that all geometry data is valid, so after the initial import I
 do a cleaning of all non-valid geometry data (self-intersection, ...).
 Now my question: If I cleaned a geometry (e.g. forest) and a diff
 specifies a change in this geometry, what will happen?



I have a related question. What might be the best procedure to follow if I
just want to keep the Finnish excerpt up to date? I have been using the
Geofabrik country file and osm2pgsql, but now it takes about 40 minutes to
run and some 20 minutes more for some updates and extra indexes etc. which
I want to have. Is it possible to generate something like Finland.diff
files to be used with osm2pgsql for updating the PostGIS database?  I have
been thinking that all that I would really need would be osm_point,
osm_line and osm_polygon tables, and all those three would only need one
attribute field, tags as hstore datatype.  All the rest I could do with
SQL inside database.

-Jukka Rahkonen-



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


[osmosis-dev] Need Help

2010-06-11 Thread PARVEEN ARORA
Hello Every one,
I am Parveen Arora .An engineering student.
I am doing a project of setting osm -server   for Our state punjab in India
and to develop its and features of Main OpenStreetMap.
i have followed the instruction given at the following website.

http://weait.com/content/build-your-own-openstreetmap-server

But it has not wrked upto end.
The follwing command is not working.
cd ~/bin/osm2pgsql
./osm2pgsql -S default.style --slim -d gis -C 2048
~/planet/planet-100217.osm.bz2

Please help me and give suggesions that what should i do move forward.

-
Regards
Parveen Arora
www.osmpunjab.co.cc
___
osmosis-dev mailing list
osmosis-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev


Re: [OSM-dev] [OSM-server setup]

2010-06-11 Thread Mike N.
The follwing command is not working.
cd ~/bin/osm2pgsql
./osm2pgsql -S default.style --slim -d gis -C 2048 
~/planet/planet-100217.osm.bz2

   What kind of error message comes from this command?
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] osm2pgsql diff mechanics

2010-06-11 Thread Lennard
 I have a related question. What might be the best procedure to follow if I
 just want to keep the Finnish excerpt up to date? I have been using the
 Geofabrik country file and osm2pgsql, but now it takes about 40 minutes to
 run and some 20 minutes more for some updates and extra indexes etc. which
 I want to have. Is it possible to generate something like Finland.diff
 files to be used with osm2pgsql for updating the PostGIS database?  I have

You can update an extract with the global diffs. Use the bbox parameter
for osm2pgsql to limit the working area to the area of your extract.

You can also keep an extract.osm up to date using osmosis. Apply the diffs
in osmosis and then apply a bounding box/polygon filter before writing out
the updated osm file.

 been thinking that all that I would really need would be osm_point,
 osm_line and osm_polygon tables, and all those three would only need one
 attribute field, tags as hstore datatype.  All the rest I could do with
 SQL inside database.

You are required to have the slim mode tables (nodes,ways,rels) to be able
to apply diffs.

-- 
Lennard


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


Re: [OSM-dev] [OSM-server setup]

2010-06-11 Thread PARVEEN ARORA
On Fri, Jun 11, 2010 at 5:12 PM, Mike N. nice...@att.net wrote:

  The follwing command is not working.
 cd ~/bin/osm2pgsql
 ./osm2pgsql -S default.style --slim -d gis -C 2048
 ~/planet/planet-100217.osm.bz2
What kind of error message comes from this command?

osm2pgsql SVN version 0.69-21640

Connection to database failed: FATAL:  Ident authentication failed for user
user_name



 ___
 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 diff mechanics

2010-06-11 Thread Jukka Rahkonen
Lennard wrote:

 I have a related question. What might be the best procedure to follow if
 I
 just want to keep the Finnish excerpt up to date? I have been using the
 Geofabrik country file and osm2pgsql, but now it takes about 40 minutes
 to
 run and some 20 minutes more for some updates and extra indexes etc.
 which
 I want to have. Is it possible to generate something like Finland.diff
 files to be used with osm2pgsql for updating the PostGIS database?  I
 have

 You can update an extract with the global diffs. Use the bbox parameter
 for osm2pgsql to limit the working area to the area of your extract.

 You can also keep an extract.osm up to date using osmosis. Apply the diffs
 in osmosis and then apply a bounding box/polygon filter before writing out
 the updated osm file.

 been thinking that all that I would really need would be osm_point,
 osm_line and osm_polygon tables, and all those three would only need one
 attribute field, tags as hstore datatype.  All the rest I could do with
 SQL inside database.

 You are required to have the slim mode tables (nodes,ways,rels) to be able
 to apply diffs.

Thanks, I will have a try with global diffs and bbox. And sorry about
being unclear, I knew I need slim mode tables for updating, I meant that
for what I am using the OSM data I will only need points, lines, polygons
and all the tags.  Well, that covers the most, actually.

-Jukka-


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


[OSM-dev] [Fwd: Re: osm2pgsql diff mechanics]

2010-06-11 Thread Jukka Rahkonen
Lennard wrote:

 I have a related question. What might be the best procedure to follow if
 I
 just want to keep the Finnish excerpt up to date? I have been using the
 Geofabrik country file and osm2pgsql, but now it takes about 40 minutes
 to
 run and some 20 minutes more for some updates and extra indexes etc.
 which
 I want to have. Is it possible to generate something like Finland.diff
 files to be used with osm2pgsql for updating the PostGIS database?  I
 have

 You can update an extract with the global diffs. Use the bbox parameter
 for osm2pgsql to limit the working area to the area of your extract.

 You can also keep an extract.osm up to date using osmosis. Apply the diffs
 in osmosis and then apply a bounding box/polygon filter before writing out
 the updated osm file.

 been thinking that all that I would really need would be osm_point,
 osm_line and osm_polygon tables, and all those three would only need one
 attribute field, tags as hstore datatype.  All the rest I could do with
 SQL inside database.

 You are required to have the slim mode tables (nodes,ways,rels) to be able
 to apply diffs.

Thanks, I will have a try with global diffs and bbox. And sorry about
being unclear, I knew I need slim mode tables for updating, I meant that
for what I am using the OSM data I will only need points, lines, polygons
and all the tags.  Well, that covers the most, actually.

-Jukka-



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


Re: [OSM-dev] [OSM-server setup]

2010-06-11 Thread Pieren
On Fri, Jun 11, 2010 at 1:45 PM, PARVEEN ARORA parveenarora...@gmail.comwrote:

 Connection to database failed: FATAL:  Ident authentication failed for user
 user_name



Perhaps the answer is here:
http://wiki.openstreetmap.org/wiki/Osm2pgsql#DB_access
and there:
http://wiki.openstreetmap.org/wiki/Mapnik#Authentication_failed
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


Re: [osmosis-dev] Need Help

2010-06-11 Thread Klemens
What is the error message that you get?


On 11.06.2010 13:38, PARVEEN ARORA wrote:
 Hello Every one,
 I am Parveen Arora .An engineering student.
 I am doing a project of setting osm -server   for Our state punjab in India
 and to develop its and features of Main OpenStreetMap.
 i have followed the instruction given at the following website.
 
 http://weait.com/content/build-your-own-openstreetmap-server
 
 But it has not wrked upto end.
 The follwing command is not working.
 |cd ~/bin/osm2pgsql
 ./osm2pgsql -S default.style --slim -d gis -C 2048
 ~/planet/planet-100217.osm.bz2|
 
 Please help me and give suggesions that what should i do move forward.
 
 -
 Regards
 Parveen Arora
 www.osmpunjab.co.cc http://www.osmpunjab.co.cc/
 
 
 
 ___
 osmosis-dev mailing list
 osmosis-...@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/osmosis-dev


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


[OSM-dev] compile error on osm2pgsql for Macosx + Patch

2010-06-11 Thread Michael Kussmaul
Hi,

Not sure how to report this - when compiling the current SVN-version of 
osm2pgsql for macosx, I receive a compiler error (malloc.h: No such file or 
directory).

It seems including malloc.h is anyway unnecessary, as stdlib.h already takes 
care to get the correct malloc implementation - so after removing the line 

#include malloc.h

in the file middle-pgsql.c, everything went fine.

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


Re: [josm-dev] JOSM-Tested

2010-06-11 Thread Matthias Julius
Dirk Stöcker openstreet...@dstoecker.de writes:

 In my eyes the current release is more stable and bug-free than any 
 release before, so tested can be set. Except in case translators do major 
 texts today I would vote for making todays nightly build tested tomorrow.

It might be a good idea to declare a feature and string freeze and
issue a call for translation updates for a few days before each
testing release.  This would give translators a chance to catch up.
It might also boost their motivation a little bit when they know that
their perfect 100% translation actually will make it into a release.

Are there any translators on this list?  How would you like that to be
handled?

Matthias

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


Re: [OSM-dev] compile error on osm2pgsql for Macosx + Patch

2010-06-11 Thread Dane Springmeyer
Hi Michael, I've seen this as well and reported here:

http://trac.openstreetmap.org/ticket/3027.

It's interesting that you can remove the reference altogether, I was able to 
get things to compile by adding malloc/malloc.h. Not sure about the right 
solution.

I also updated the homebrew build script [1] with that patch, so I'll need to 
update that when this gets fixed in trunk.

Dane

[1] http://github.com/mxcl/homebrew/blob/master/Library/Formula/osm2pgsql.rb

On Jun 11, 2010, at 6:05 AM, Michael Kussmaul wrote:

 Hi,
 
 Not sure how to report this - when compiling the current SVN-version of 
 osm2pgsql for macosx, I receive a compiler error (malloc.h: No such file or 
 directory).
 
 It seems including malloc.h is anyway unnecessary, as stdlib.h already takes 
 care to get the correct malloc implementation - so after removing the line 
 
 #include malloc.h
 
 in the file middle-pgsql.c, everything went fine.
 
 thanks
 Michael
 ___
 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 diff mechanics

2010-06-11 Thread Stephan Knauss
Jukka Rahkonen wrote:
 Thanks, I will have a try with global diffs and bbox.

This is what I use to apply a diff to a partial extract:

http://wiki.openstreetmap.org/wiki/User:Stephankn/knowledgebase

Stephan

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


Re: [josm-dev] JOSM-Tested

2010-06-11 Thread Dirk Stöcker
On Fri, 11 Jun 2010, Matthias Julius wrote:

 In my eyes the current release is more stable and bug-free than any
 release before, so tested can be set. Except in case translators do major
 texts today I would vote for making todays nightly build tested tomorrow.

 It might be a good idea to declare a feature and string freeze and
 issue a call for translation updates for a few days before each
 testing release.  This would give translators a chance to catch up.
 It might also boost their motivation a little bit when they know that
 their perfect 100% translation actually will make it into a release.

 Are there any translators on this list?  How would you like that to be
 handled?

Yes. I'am. I always tell me before release that everything must be 
translated. Usually I try to do so :-)

No really. Usually in the time after announcing tested stage first time 
only bug-fixes are done and they don't usually add new user visible 
strings, but mainly error messages or the like (or new plugin strings). I 
also take care that the translators have a chance to catch up before, so 
the languages which currently try the 100% (German, Ukrainian, Russian, 
Italian, ...) have the chance to do so.

On the other hand JOSM is in flux always, so texts in updated plugins 
become outdated and many language miss newer strings anyways. Until now it 
seems impossible to get a release handling for JOSM translations. There 
are always only few people who really actively translate texts and most 
languages stay in the incomplete state. And there are really many strings 
in JOSM and always comming a lot of new strings.

I know this situation from other projects and it seems it is unsolvable, 
so I don't really want to stop development because of missing 
translations. Only solution would be a release branching each time we hav 
a tested, but due to various reason explained in length in other mails I 
still don't think the currently working josm process should be changed 
without need.

This does not mean that when there is a chance to better motivate our 
translators we shouldn't try it.

... Giving each of them a free copy of the software?


... (hmm, wrong development model  :-)

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)


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


Re: [josm-dev] JOSM-Tested

2010-06-11 Thread Frederik Ramm
Hi,

Ævar Arnfjörð Bjarmason wrote:
 This wouldn't solve the issue of having 100% complete translations at
 time of release. But it seems that for overall translation
 completeness Translatewiki is working great for OSM. We both have
 active OSM contributors, and an active general translation community
 contributing.

To be honest I'm not keen on having anything translated by members of a 
general translation community. There are many things which, I believe, 
need the OSM context to be translated properly.

I recently changed the E-D translation on launchpad for a number of 
OAuth related items. I don't remember what the problem was exactly but 
it was clear that the translator did not know anything about how OAuth 
works, but just chose context-free translations of the terms involved. 
This resulted in a very skewed overall picture. The person did have an 
OSM background but it seems no OAuth knowledge.

I would expect many more problems of that caliber to show up if we let 
people without OSM exposure translate stuff. It may just about work for 
the web site (but even there I'm skeptical) but not for a sophisticated 
editor.

In my eyes, a *bad* (or half-good) translation is worse than no 
translation at all. If members of the JOSM or at least OSM community do 
not have the time to translate JOSM into Ancient Greek then I'd prefer 
not to have an Ancient Greek JOSM at all, rather than having an Ancient 
Greek JOSM which has been translated by Ancient Greek enthusiast who 
knew nothing of OSM.

Unfortunately the statistics capture quantity, not quality.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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