Re: [OSM-dev] Java library OSM-binary is on Maven Central

[Sebastiaan Couwenberg]

On 10/20/20 5:22 PM, Simon Legner wrote:
> On Tue, Oct 20, 2020 at 10:07 AM Sebastiaan Couwenberg
>  wrote:
>> Maven has version 1.4.0, but this release is not tagged yet.
>>
>> Should it have been a SNAPSHOT release on Maven?
> 
> No, the 1.4.0 release was intended…

Will there be a 1.4.0 release then?

It would be good to propagate the repo change to the openstreetmap
namespace and groupId for the Java libarary to downstream distributions.

In case of a release, perhaps we should have a party, a new release
after 6 years deserves that :-D

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] Java library OSM-binary is on Maven Central

[Sebastiaan Couwenberg]

On 10/20/20 9:26 AM, Simon Legner wrote:
> openstreetmap/OSM-binary [1] is the library for reading/writing OSM
> pbf files. Since today, its Java version is available from Maven
> Central [2, 3]. Big thanks to everyone involved [4]!

Maven has version 1.4.0, but this release is not tagged yet.

Should it have been a SNAPSHOT release on Maven?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[osmosis-dev] Migrating tickets from Trac to GitHub

[Sebastiaan Couwenberg]

The OSM Trac instance has been discontinued for most project that used
it, there are still quite a few outstanding tickets for osmosis in Trac
though [0].

It is currently the place were tickets for osmosis should be filed as
issues on GitHub are disabled.

Perhaps it's time to move the tickets from Trac to GitHub?

[0]
https://trac.openstreetmap.org/query?status=new=assigned=reopened=osmosis=priority

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [osmosis-dev] Osmosis 0.47.3 released

[Sebastiaan Couwenberg]

On 4/12/20 4:28 PM, Jocelyn Jaubert wrote:
> Do you know if this new version will be used on Debian, via backports for
> example, or at least on next testing version?

Yes, see:

 https://tracker.debian.org/pkg/osmosis

0.47.4 should migrate to testing tomorrow, so the backport will be
updated then.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] pgsql2osm software

[Sebastiaan Couwenberg]

Thanks for sharing your software.

Looking through the source I noticed some code smells like creating XML
as strings instead of using lxml and not quoting variables used in SQL.
flake8 also reports several issues with convert2osm.py.

One also wonders how this compares to ogr2osm which can be used for the
same purpose. Have you tried using that before deciding to write this?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] Any problem with Debian tile servers?

[Sebastiaan Couwenberg]

On 4/8/19 8:11 PM, Tom Browder wrote:
> I want to run my own tile server but I run Debian 9 on the server I plan to
> use. All the docs I have seen so far target Ubuntu. Is there any problem
> with using other Linux distros?

You can't use PPAs on Debian like those documented in switch2osm, but
you can build mod_tile from source.

The biggest benefit of using Debian over Ubuntu is that the geospatial
package are actively maintained in Debian, in Ubuntu they are not. There
is someone actually triaging bugs and able to provide stable updates for
important issues in packages, Ubuntu does not have that.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: LiveJOSM project

[Sebastiaan Couwenberg]

On 12/4/18 10:39 PM, Jiri Vlasak wrote:
> I would like to announce the LiveJOSM [1] project. It's not much, just
> Debian Live [2] with JOSM preinstalled (+ some plugins).

Why not install the josm package from the backports repository?

No need for the icon hack then.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: JMapViewer release downloads no longer available

[Sebastiaan Couwenberg]

On 08/18/2018 04:25 PM, Vincent Privat wrote:
> OK. This is not linked to JMapViewer itself but likely caused by a software
> upgrade or a change of configuration on OSM SVN server.

SVN is still at 1.8.8, so it's most likely caused by the webserver
configuration to add the banner.

> Can you adapt the Debian watcher to the new links?

Yes, I've added bunch of mangle rules to make it work again, see:

 
https://salsa.debian.org/debian-gis-team/jmapviewer/commit/527e494d2edd51dac1fe89f21c83aab50c8460cc

> It's also possible to get the latest version with this SVN command:
> 
> $ svn propget ReleaseVersion
> https://svn.openstreetmap.org/applications/viewer/jmapviewer
> 2.7

Since JOSM is still very focused on SVN, I guess there are no plans to
move it and JMapViewer to GitHub where we could use the tarballs from
the release tags?

> Le sam. 18 août 2018 à 15:35, Sebastiaan Couwenberg  a
> écrit :
> 
>> On 08/18/2018 03:20 PM, Vincent Privat wrote:
>>> What do you mean by "not available"? The page is displayed and we can
>>> download releases from there.
>>
>> IIRC there was an index page which contained the links to all the releases.
>>
>> This was used by uscan(1) in the Debian package to check for new
>> upstream releases. This doesn't work any more:
>>
>> $ uscan --report
>> uscan warn: In debian/watch,
>>   no matching hrefs for pattern
>>
>>
>> https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/(\d+(?
>> <https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/(%5Cd+(?>
>> :\.\d+)*)
>> at /usr/bin/uscan line 4307,  line 3.
>>
>> Looking at the page HTML the links to the version directories changed from:
>>
>>2.0/
>>
>> To:
>>
>> 
>>
>>> Le sam. 18 août 2018 à 12:16, Sebastiaan Couwenberg 
>>> a écrit :
>>>
>>>> With the deprecation of svn.openstreetmap.org, the JMapViewer release
>>>> page [0] is no longer available.
>>>>
>>>> The banner at the top refers to the OpenStreetMap organisation on
>>>> GitHub, but there is no jmapviewer project there.
>>>>
>>>> Are there plans to move jmapviewer to GitHub, or if not, can the release
>>>> download page be restored?
>>>>
>>>> [0] https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/

Kind Regards,

Bas

Re: JMapViewer release downloads no longer available

[Sebastiaan Couwenberg]

On 08/18/2018 03:20 PM, Vincent Privat wrote:
> What do you mean by "not available"? The page is displayed and we can
> download releases from there.

IIRC there was an index page which contained the links to all the releases.

This was used by uscan(1) in the Debian package to check for new
upstream releases. This doesn't work any more:

$ uscan --report
uscan warn: In debian/watch,
  no matching hrefs for pattern

https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/(\d+(?:\.\d+)*)
at /usr/bin/uscan line 4307,  line 3.

Looking at the page HTML the links to the version directories changed from:

   2.0/

To:



> Le sam. 18 août 2018 à 12:16, Sebastiaan Couwenberg  a
> écrit :
> 
>> With the deprecation of svn.openstreetmap.org, the JMapViewer release
>> page [0] is no longer available.
>>
>> The banner at the top refers to the OpenStreetMap organisation on
>> GitHub, but there is no jmapviewer project there.
>>
>> Are there plans to move jmapviewer to GitHub, or if not, can the release
>> download page be restored?
>>
>> [0] https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/

JMapViewer release downloads no longer available

[Sebastiaan Couwenberg]

With the deprecation of svn.openstreetmap.org, the JMapViewer release
page [0] is no longer available.

The banner at the top refers to the OpenStreetMap organisation on
GitHub, but there is no jmapviewer project there.

Are there plans to move jmapviewer to GitHub, or if not, can the release
download page be restored?

[0] https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/

Kind Regards,

Bas

[osmosis-dev] Porting osmosis to Netty 4

[Sebastiaan Couwenberg]

As reported in Trac #5489 [0], osmosis uses Netty 3 which its upstream
stopped supporting in 2016. Osmosis needs to be ported to Netty 4.

The lack of security support for Netty 3 is reason for its removal from
the next Debian stable release. And unless osmosis is updated to use
Netty 4, it will also be removed (and by extension from Ubuntu which
syncs its packages from Debian).

I'd very much like to keep osmosis in Debian, but like FauxFaux do not
have the skills required to port osmosis to Netty 4.

Who does have the skills to port osmosis to Netty 4? If no developer has
time, would a crowfunding campaign help to fund development time?

[0] https://trac.openstreetmap.org/ticket/5489

Kind Regards,

Bas

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

Re: [OSM-dev] osm2pgsql 0.96.0-RC1

[Sebastiaan Couwenberg]

On 04/22/2018 09:48 AM, Paul Norman wrote:
> The following changes affect packagers
> 
> - The built-in version of libosmium has been updated to 2.14.0, and it
> no longer bundles protozero internally. osm2pgsql now bundles both
> libosmium and protozero because of the close ties between osm2pgsql and
> llibosmium. Other versions of libosmium are not supported by the
> maintainers.
> 
> - osm2pgsql can now use LuaJIT:
> https://github.com/openstreetmap/osm2pgsql/pull/810
> 
> 
> I would particularly like feedback from packagers, given the libosmium
> changes.

osm2pgsql (0.96.0~rc1+ds-1~exp1) is already available in Debian
experimental, it doesn't use LuaJIT though.

As long as libosmium doesn't break backwards compatibility, using a
newer version to build osm2pgsql shouldn't be an issue. The Debian
packages uses the packaged libosmium & protozero and strips the embedded
copies from the osm2pgsql source package.

Since libosmium and protozero (used to) have a higher frequency of new
releases that osm2pgsql, the embedded copies in osm2pgsql can be
re-instated if updates of the libosmium and/or protozero packages cause
breakage. Since embedded code copies are frowned upon in Debian the
packaged dependencies will be used for as long as possible.

Kind Regards,

Bas

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

Re: [osmosis-dev] NOTIVE: table "actions" does not exist, skipping

[Sebastiaan Couwenberg]

On 05/28/2017 03:49 PM, Pander wrote:
> On 05/28/2017 03:21 PM, Sebastiaan Couwenberg wrote:
>> On 05/28/2017 03:01 PM, Pander wrote:
>>> Also the page offers the command
>>>
>>> sudo -u postgres psql -d gis -f
>>> /usr/share/doc/osmosis/examples/pgsnapshot_schema_0.6_linestring.sql
>>>
>>> when I want longstring support, but there is no information on which I
>>> should base my decision. Where can I find more information or what is
>>> recommended for my goal here?
>>
>> It all depends on what you want to do with the database. Applying the
>> _action, _bbox & _linestring SQL scripts in addition to the basic schema
>> gives you more tables and geometry columns for spatial queries which you
>> then don't need to construct yourself.
> 
> Correct that bbox and linestring are relevant when you are going to
> calculate routing? And action when you are makeing changes to the database?

Not per se. The bbox and linestring changes can be used for various
cases. E.g. highlighting the bbox for a selected way as an obvious example.

The linestring column is very useful to not need to construct the
feature yourself from the individual nodes.

The actions table is used when applying diffs:

"
 Adds the optional "action" table which allows derivative tables to be
 kept up to date when diffs are applied.
"

https://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage_0.45#PostGIS_Tasks_.28Snapshot_Schema.29

> My goal is to have a database which updates daily and I am only going to
> run queries on it (no routing) and I am not going to make changes to the
> data. So it is correct that none of these extra script are useful in my
> case?

It depends on your queries. Try your use case with just the minimal
schema and add what you need based on that experience.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [osmosis-dev] NOTIVE: table "actions" does not exist, skipping

[Sebastiaan Couwenberg]

On 05/28/2017 03:01 PM, Pander wrote:
> I am following instructions from
> https://wiki.openstreetmap.org/wiki/Osmosis/PostGIS_Setup to run a
> database with an export of a country from Geofabrik.
> 
> When I run
> 
> sudo -u postgres psql -d gis -f
> /usr/share/doc/osmosis/examples/pgsnapshot_schema_0.6.sql
> 
> I get this message
> 
> psql:/usr/share/doc/osmosis/examples/pgsnapshot_schema_0.6.sql:4:
> NOTICE:  table "actions" does not exist, skipping
> 
> Is this a bug which I should report in trac?

No, it's just a notice that the "DROP TABLE IF EXISTS actions;" query
did not delete the table because it doesn't exist.

> Also the page offers the command
> 
> sudo -u postgres psql -d gis -f
> /usr/share/doc/osmosis/examples/pgsnapshot_schema_0.6_linestring.sql
> 
> when I want longstring support, but there is no information on which I
> should base my decision. Where can I find more information or what is
> recommended for my goal here?

It all depends on what you want to do with the database. Applying the
_action, _bbox & _linestring SQL scripts in addition to the basic schema
gives you more tables and geometry columns for spatial queries which you
then don't need to construct yourself.

Have a look at the comments on the top of those files for their purpose.
If you don't need that, you can skip applying those scripts.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: Using CachedFile class for /data/help-browser.css in HelpBrowser class

[Sebastiaan Couwenberg]

Hi Simon,

Thanks for the feedback.

On 09/22/2016 11:10 PM, Simon Legner wrote:
> the proposed change makes sense. I'm happy to commit it once a JOSM
> ticket has been created (for reference). Note that you can also use
> `CachedFile#getContentReader` to obtain a `BufferedReader`.

I've forwarded the changes as included in the Debian package in:

 https://josm.openstreetmap.de/ticket/13687

It doesn't use getContentReader() though.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Using CachedFile class for /data/help-browser.css in HelpBrowser class

[Sebastiaan Couwenberg]

Today an issue was reported for the josm Debian package about the Help
menu option causing an exception. [0] This turned out to be caused by
help-browser.css being moved out of the jar for the Debian package.

Most code uses the CachedFile class to access embedded resources in jar,
and I wonder if the HelpBrowser shouldn't do so too. This would simplify
the patch included in the Debian package, and increase consistency in
the JOSM code.

If there is interest for the above I'll forward the relevant changes [1]
for JOSM trunk in a Trac ticket.

[0] https://bugs.debian.org/838247
[1]
https://anonscm.debian.org/cgit/pkg-grass/josm.git/tree/debian/patches/06-move_data_out_of_jar.patch#n70

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] osm2pgsql 0.90.1 release

[Sebastiaan Couwenberg]

On 07/18/2016 03:25 PM, Paul Norman wrote:
> On 7/18/2016 6:07 AM, Sebastiaan Couwenberg wrote:
>> Important for context is that "something" was mapnik (from 2.2 to 3.0),
>> which is non-trivial due to breaking its reverse dependencies.
> 
> I believe I also asked about osm2pgsql, but I'm left in a situation
> where I don't have the permissions to do it myself or a route to move
> forwards.

You're one of the administrators of the openstreetmap PPA on Launchpad,
using the PPA is the most viable route forwards to provide newer package
versions for Ubuntu.

What permissions are blocking you in Ubuntu? Just the main archive, or
do you also have issues with the PPA?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] osm2pgsql 0.90.1 release

[Sebastiaan Couwenberg]

On 07/18/2016 02:24 PM, Paul Norman wrote:
> On 7/18/2016 4:32 AM, Komяpa wrote:
>> Is it available for Ubuntu Xenial?
> 
> It should compile fine, but Xenial has osm2pgsql 0.88.1 by default. I
> haven't backported all the changes to the 0.88.x branch, but I could.
> 
> The chances of Ubuntu getting the bug fixes is close to zero. I asked
> for a backport from Xenial to Trusty of something and got absolutely no
> response.

Important for context is that "something" was mapnik (from 2.2 to 3.0),
which is non-trivial due to breaking its reverse dependencies.

Both mapnik and osm2pgsql are in the universe component of Ubuntu, this
means that the packages are not maintained by Canonical employees and
the burden of maintaining those packages in Ubuntu is on the community.

Unfortunately the Ubuntu community lacks the number of developers to
maintain all those packages properly. Even Debian from where the Ubuntu
packages originate doesn't have enough developers to maintain all
20.000+ packages properly, but fortunately the situation in Debian is
not as problematic as in Ubuntu.

I spend all my spare time on maintaining the many GIS & OSM packages in
Debian keeping them in good shape, I cannot do the same for Ubuntu
unless maintaining the packages for Ubuntu becomes my day job.

The openstreetmap PPA on Launchpad could provide backports of OSM
packages for Ubuntu independently of the main Ubuntu archive, but has
the same problem as Ubuntu itself: it needs people to maintain those
packages for Ubuntu.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] osm2pgsql 0.90.1 release

[Sebastiaan Couwenberg]

On 07/18/2016 01:32 PM, Komяpa wrote:
> Is it available for Ubuntu Xenial?

If not, you can easily rebuild the source package maintained by the
Debian GIS team [0] using the documented workflow for backports [1].

There is no coordinated effort to maintain packages for Ubuntu, possibly
because Ubuntu attracts users, not developers who contribute to package
maintenance.

[0] https://tracker.debian.org/pkg/osm2pgsql
[1] https://pkg-grass.alioth.debian.org/policy/packaging.html#git-backports

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[OSM-dev] OSGeo-Live team needs help: Someone who looks after OSM data, tools and writes documentation is needed

[Sebastiaan Couwenberg]

 Forwarded Message 
Subject: [Live-demo] OSGeo-Live team needs help: Someone who looks after
OSM data, tools and writes documentation is needed
Date: Sat, 11 Jun 2016 13:06:11 +0200
From: Astrid Emde 
To: Live Demo 

Hello OSM enthusiasts,

this is a mail from the OSGeo-Live team [1]. OSGeo-Live is a linux based
distribution of open source geospatial software which is handed out at
conferences around the world, and used as the foundation for open source
geospatial training courses.

We use OSGeo-Live to teach enthusiasts how to create geospatial data
with free tools.

At the moment, we include an extract of OSM data, and how to use Mapnik,
but we'd love to be doing a better job of promoting OSM which in turn
should attract motivated geospatial people into the OSM community.

The catch is that we need some help understanding OSM tools, and keeping
these tools and docs up to date, which is where you (the OSM community)
comes in.

We are hoping to find one or two people who can help us write
Application Overview [2] and 10-15 min Quickstart docs, and act as a
point of contact to advise on OSM as we build each release.

This is what we are looking for. Are you interested to help? It could be
a single person or a team. And the OSGeo-Live team is also supporting,
when help is needed.

This is what you have to do - don't worry, it should not be too much work ;)
* provide the up-to-date software every half a year when a new version
of OSGeo-Live is coming out
* check the documentation (Overview and Quickstart)  -> is there
anything to update
* provide new up-to-date OSM data (f.e. for version 10.0 we will provide
data from Bonn where FOSS4G 2016 will be in august)
* provide a quickstart (tutorial to help people to get to know OSM and
make the first steps) - this quickstart does not exist at the moment and
has to be written
* OSM covers data and OSM tools (like JOSM) which are not documented yet
** we only have a documentation for Mapnik
http://live.osgeo.org/en/overview/mapnik_overview.html

Are you interested? If yes - please let us know. (subscribe to the
OSGeo-Live (Live-demo) mailing list [4] or write to astrid_e...@osgeo.org)

Regards

Astrid from OSGeo-Live PSC

[1] http://live.osgeo.org
[2] OSM Overview http://live.osgeo.org/en/overview/osm_dataset_overview.html
[3] OSGeo-Live Dokumentation in the OSGeo wiki
http://wiki.osgeo.org/wiki/Live_GIS_Disc
[4] Live-demo mailing list
https://lists.osgeo.org/mailman/listinfo/live-demo

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

[osmosis-dev] osmosis 0.45

[Sebastiaan Couwenberg]

On 05/27/2016 01:12 PM, Brett Henderson wrote:
> I've just released Osmosis 0.45.
> http://bretth.dev.openstreetmap.org/osmosis-build/osmosis-0.45.tgz
> http://bretth.dev.openstreetmap.org/osmosis-build/osmosis-0.45.zip
> 
> 
> [...]
> 
> Let me know if you see any issues.

The release tag is missing in the GitHub repository.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] Release candidate for new osm2pgsql 0.88.0 stable release

[Sebastiaan Couwenberg]

On 27-02-16 14:20, Paul Norman wrote:
> We are preparing a new osm2pgsql stable series release, 0.90.0. This
> includes the switch to cmake for builds and libosmium for parsing.
> 
> Help is needed from packagers testing that the build system works for them.

Switching the Debian packaging to CMake was trivial, and allowed the
removal of custom install rules.

The biggest difference is that /usr/bin/nodecachefilereader is no longer
installed, but it's sources are still included and built. The renamed
node-persistent-cache-reader is just not installed any more. PR #544 has
a fix: https://github.com/openstreetmap/osm2pgsql/pull/544

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [josm-dev] JMapViewer 1.12 release to accompany JOSM 8964?

[Sebastiaan Couwenberg]

On 31-10-15 15:08, Sebastiaan Couwenberg wrote:
> On 31-10-15 14:11, Vincent Privat wrote:
>> I have a few other remarks on the Debian package.
>> The package still depends on libandroid-json-org-java and
>> libcommons-codec-java, they should be dropped:
>>
>> - org.json was dropped in 6756, see
>> https://josm.openstreetmap.de/ticket/9590
>> - Apache Commons Codec was dropped in 8149, see
>> https://josm.openstreetmap.de/ticket/11257
>>
>> commons-codec.jar must also be removed from 00-build.patch
> 
> Thanks, fixed in josm (0.0.svn8969+dfsg-2).

Removing commons-codec.jar from the Class-Path seems to have broken the
OAuth support as reported in Debian Bug #804072
(https://bugs.debian.org/804072).

How do the tested & latest builds handle these dependencies?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[OSM-dev] Call For papers Geospatial devroom @FOSDEM 2016

[Sebastiaan Couwenberg]

 Forwarded Message 
Subject: [OSGeo-Discuss] Call For papers Geospatial devroom @FOSDEM 2016
Date: Mon, 2 Nov 2015 08:22:03 +0100
From: Johan Van de Wauw 
To: OSGeo Discussions , LocationTech Working
Group discussion list 

Please forward!

FOSDEM is a free and non-commercial event bringing together about 5000
developers in Brussels, Belgium. The goal is to provide open source
software developers and communities a place to meet and share
thoughts. The participation is free of charge, although donations are
welcome. The next edition will take place the last weekend ofJanuary
30 - 31 2016. This year for the second time there will be a Geospatial
devroomon Sunday 31/1/2016, organised by members of the OSGeo,
Locationtech and OpenStreetMap communities.

Geospatial technology is becoming rapidly mainstream. The idea
underpinning the geospatial devroom is bringing together developers
with different backgrounds to disclosethe opportunities offered by
cutting-edge open source geospatial technologies. Due to the success
of last years devroom, a Belgium local chapter of OSGeo, OSGeo.be was
founded, and is now taking part of the organisation of the devroom as
driving community.

The Geospatial devroom is the place to talk about the state of the art
of open, geo-related data, free and open source geospatial software
and its ecosystem. This includes standards and tools, e.g. spatial
databases, online mapping tools, geospatial services, used for
collecting, storing, delivering, analysing, and visualizing geodata.
We welcome submissions about:

* Web and desktop GIS applications
* Interoperable geospatial web services and specifications
* Collection of data using sensors/drones/satellites
* Open hardware for geospatial applications
* Geo-analytic algorithms/libraries
* Geospatial extensions for classical databases (indexes, operations)
and dedicated databases
* Collaborative editing/versioning of geodata
* Big geodata, scalable GIS applications
* Volunteered Geograpic information - Crowdsourced data

HOW TO SUBMIT YOUR PROPOSAL FOR A TALK

Are you thrilled to present your work to other open source developers?
Would you like to run a discussion? Any other ideas? Please submit
your proposal using the Pentabarf event planning tool at:

https://penta.fosdem.org/submission/FOSDEM16

Make sure to select the 'Geospatial devroom' as  'Track'. Please,
specify in the notes if you prefer for your presentation either a
short timeslot (lightning talks ~10 minutes) or along timeslot (20
minutes presentation + discussion). However, note that time slots are
indicative and will be assigned according to the needs of the session.

The DEADLINE for submissions is Tuesday **1st December 2015**.
Notification of acceptance will be sent to the Authors by Friday
11/12/2015 at the latest.

Should you have any questions, please do not hesitate to get in touch
with the organisers of the devroom at fosdem-geospat...@gisky.be!

Johan Van de Wauw
Margherita Di Leo
Astrid Emde
Anne Ghisla
Martin Hammitzsch
Andy Petrella
Dirk Frigne
Olivier Courtin
Thomas Gratier

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

Re: [josm-dev] JMapViewer 1.12 release to accompany JOSM 8964?

[Sebastiaan Couwenberg]

On 31-10-15 01:52, Vincent Privat wrote:
> I see https://packages.debian.org/sid/josm depends on jmapviewer 1.11 and
> not 1.12, is it OK?

It works with both, so no need to require the latest version.

JMapViewer 1.12 was a bugfix release, the API didn't change.

That's quite fortunate so we didn't need to bother the freeplane
maintainer for another compatibility fix.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [josm-dev] JMapViewer 1.12 release to accompany JOSM 8964?

[Sebastiaan Couwenberg]

On 31-10-15 14:11, Vincent Privat wrote:
> I have a few other remarks on the Debian package.
> The package still depends on libandroid-json-org-java and
> libcommons-codec-java, they should be dropped:
> 
> - org.json was dropped in 6756, see
> https://josm.openstreetmap.de/ticket/9590
> - Apache Commons Codec was dropped in 8149, see
> https://josm.openstreetmap.de/ticket/11257
> 
> commons-codec.jar must also be removed from 00-build.patch

Thanks, fixed in josm (0.0.svn8969+dfsg-2).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [josm-dev] JMapViewer 1.12 release to accompany JOSM 8964?

[Sebastiaan Couwenberg]

On 30-10-15 12:22, Vincent Privat wrote:
> Done!

Thanks!

The updated Debian packages will be available later today.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[josm-dev] JMapViewer 1.12 release to accompany JOSM 8964?

[Sebastiaan Couwenberg]

With the new tested snapshot for JOSM I also expected the JMapViewer
1.12 release with wiktorns recent tile chache changes.

I see that there is no JMapViewer 1.12 release yet, can we expect that soon?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [josm-dev] JOSM Version check source (VersionTest macro) to troubleshoot strange version

[Sebastiaan Couwenberg]

On 11-10-15 13:31, Dirk Stöcker wrote:
> On Sat, 10 Oct 2015, Sebastiaan Couwenberg wrote:
> 
>> On 10-10-15 00:01, Dirk Stöcker wrote:
>>> On Fri, 9 Oct 2015, Sebastiaan Couwenberg wrote:
>>>
>>>>> No. As you mark it as Debian in the agent it's correct to strip the
>>>>> SVN
>>>>> text. This patch as far as I remember was designed in cooperation with
>>>>> me. For SVN we react different in tickets - We tell the user first to
>>>>> update to recent SVN version assuming the user can build the software
>>>>> himself. This is not the correct reply for Debian version, so the SVN
>>>>> should not be there. Simply change the patch to set "Debian"
>>>>> instead of
>>>>> "SVN", as I see that there is no patch in the GIT yet for this
>>>>> purpose.
>>>>
>>>> Based on the bug report and your changes to the VersionTest macro, it
>>>> seemed the patch may have been unneeded in the first place.
>>>>
>>>> I prefer the User-Agent without SVN substring anyway, so I'll happily
>>>> keep it for the Debian package.
>>>>
>>>> The Debian Build-Name change is currently only available in the
>>>> 00-build.patch on the stretch branch:
>>>>
>>>> https://anonscm.debian.org/cgit/pkg-grass/josm.git/tree/debian/patches/00-build.patch?h=stretch#n57
>>>>
>>>>
>>>
>>> Hmm, maybe these two together need some rework. If you simply change
>>> Is-Local-Build (above the Build-Name) to false the patch to Version.java
>>> can be dropped and manifest is more correct.
>>
>> Settings Is-Local-Build to false goes against the guidelines from the
>> 'How to create a build' documentation [0].
>>
>> The Debian package is not an "official" release provided by
>> josm.openstreetmap.de for which Is-Local-Build: true is appropriate.
> 
> I added " or another approved organization" there, so it's appropriate
> now :-)

Alright, the Debian package has been updated accordingly. :-)

It will be included in the next upload, that should be next weekend to
give the freeplane maintainer a little time to look into supporting
JMapViewer 1.11 in the freeplane openmaps plugin.

>> If the motivation for this change is to not need the Version.java
>> change, I don't think that's appropriate. I prefer keeping Version.java
>> change and correctly identifying the Debian package builds as a custom
>> build not provided by josm.openstreetmap.de.
> 
> Local build really means user local builds. That's not true for Debian.
> As we discussed and agreed on a proper marking of the Debian version
> setting this to false is better. All these settings are only there to
> allow us proper support reaction for requests.

Shouldn't the Main-Version in the MANIFEST.MF now also include Debian
instead of SVN? Or should we just keep stripping the SVN string?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [josm-dev] JOSM Version check source (VersionTest macro) to troubleshoot strange version

[Sebastiaan Couwenberg]

On 10-10-15 00:01, Dirk Stöcker wrote:
> On Fri, 9 Oct 2015, Sebastiaan Couwenberg wrote:
> 
>>> No. As you mark it as Debian in the agent it's correct to strip the SVN
>>> text. This patch as far as I remember was designed in cooperation with
>>> me. For SVN we react different in tickets - We tell the user first to
>>> update to recent SVN version assuming the user can build the software
>>> himself. This is not the correct reply for Debian version, so the SVN
>>> should not be there. Simply change the patch to set "Debian" instead of
>>> "SVN", as I see that there is no patch in the GIT yet for this purpose.
>>
>> Based on the bug report and your changes to the VersionTest macro, it
>> seemed the patch may have been unneeded in the first place.
>>
>> I prefer the User-Agent without SVN substring anyway, so I'll happily
>> keep it for the Debian package.
>>
>> The Debian Build-Name change is currently only available in the
>> 00-build.patch on the stretch branch:
>>
>> https://anonscm.debian.org/cgit/pkg-grass/josm.git/tree/debian/patches/00-build.patch?h=stretch#n57
>>
> 
> Hmm, maybe these two together need some rework. If you simply change
> Is-Local-Build (above the Build-Name) to false the patch to Version.java
> can be dropped and manifest is more correct.

Settings Is-Local-Build to false goes against the guidelines from the
'How to create a build' documentation [0].

The Debian package is not an "official" release provided by
josm.openstreetmap.de for which Is-Local-Build: true is appropriate.

If the motivation for this change is to not need the Version.java
change, I don't think that's appropriate. I prefer keeping Version.java
change and correctly identifying the Debian package builds as a custom
build not provided by josm.openstreetmap.de.

[0]
https://josm.openstreetmap.de/wiki/DevelopersGuide/CreateBuild#TheREVISIONfile

> Removing SVN from the other line in build.xml is probably still required
> (we don't use build.xml but a makefile on the server). But I'd include
> that single change in your 00-build.patch for better readability.

The patches have different origins and authors, that's why I prefer to
keep them separate. I've also considered merging all build.xml changes
in 00-build.patch, but so far prefer to keep the separate patches.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[josm-dev] JOSM Version check source (VersionTest macro) to troubleshoot strange version

[Sebastiaan Couwenberg]

Is the source for the JOSM Version check, the VersionTest macro used in
StartupPageSource wiki, available somewhere?

It currently is unable to handle the version used for the Debian package
which is reported as a strange version:

 '8159 Debian nl) Linux Debian GNU/Linux unstable (sid'

This was triggered by the addition of the Build-Name property to better
identify the Debian builds.

I suspect that the VersionTest regex doesn't support the use of the
Build-Name property.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [josm-dev] JOSM Version check source (VersionTest macro) to troubleshoot strange version

[Sebastiaan Couwenberg]

On 09-10-15 17:39, Dirk Stöcker wrote:
>> Works now? Please check that it checks against tested and does not
>> tell to update unless there's really a newer one. SVN version already
>> tell you to update when a new latest is there.
> 
> Need to correct me. For SVN it only tells you to update when you are
> least 50 versions behind. So it can't be tested ATM, as tested to latest
> diff is only 40.

Thanks for the quick fixes, the Startup page now reports:

 * Active version '8159 Debian' should be updated! The current stable
   snapshot is 8800 and 8840 is the unstable development version.

This is for http.agent:

'JOSM/1.5 (8159 Debian en) Linux Debian GNU/Linux unstable (sid)'

The Debian package carries a very old patch [0] that strips the addition
of the SVN substring for local builds to fix Debian Bug #598920 [1]. We
may need to consider dropping that patch now.

What are your thoughts about that?

[0]
http://anonscm.debian.org/cgit/pkg-grass/josm.git/tree/debian/patches/05-fix_version.patch
[1] https://bugs.debian.org/598920

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [josm-dev] JOSM Version check source (VersionTest macro) to troubleshoot strange version

[Sebastiaan Couwenberg]

On 09-10-15 21:27, Dirk Stöcker wrote:
> On Fri, 9 Oct 2015, Sebastiaan Couwenberg wrote:
> 
>> Thanks for the quick fixes, the Startup page now reports:
>>
>> * Active version '8159 Debian' should be updated! The current stable
>>   snapshot is 8800 and 8840 is the unstable development version.
> 
> Well yes, that will remain a Debian problem. Will you ever get a version
> where the Wiki will not ask for an update with our monthly cycle :-)

We still don't have JCS packaged for Debian, but thanks to Emmanuel
Bourg there is some progress on this front with the upload of the jcache
spec.

I'm currently working on updating the JOSM package to 8800 using the
embedded JCS and newer metadata-extractor version.

>> The Debian package carries a very old patch [0] that strips the addition
>> of the SVN substring for local builds to fix Debian Bug #598920 [1]. We
>> may need to consider dropping that patch now.
>>
>> What are your thoughts about that?
> 
> No. As you mark it as Debian in the agent it's correct to strip the SVN
> text. This patch as far as I remember was designed in cooperation with
> me. For SVN we react different in tickets - We tell the user first to
> update to recent SVN version assuming the user can build the software
> himself. This is not the correct reply for Debian version, so the SVN
> should not be there. Simply change the patch to set "Debian" instead of
> "SVN", as I see that there is no patch in the GIT yet for this purpose.

Based on the bug report and your changes to the VersionTest macro, it
seemed the patch may have been unneeded in the first place.

I prefer the User-Agent without SVN substring anyway, so I'll happily
keep it for the Debian package.

The Debian Build-Name change is currently only available in the
00-build.patch on the stretch branch:

https://anonscm.debian.org/cgit/pkg-grass/josm.git/tree/debian/patches/00-build.patch?h=stretch#n57

These changes are also in my local master branch that I'll push to the
git repository on Alioth soon after finishing the changes for JOSM 8800.

> But you can drop "08-disable_gettext-merge.patch". That speed issue has
> been fixed some time ago.

That patch has also been disabled some time ago, as part of the changes
for JOSM 8800 these old disabled patches are now removed entirely, not
just disabled in the series file.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] Referential Integrity Problem

[Sebastiaan Couwenberg]

 I have added a command to the Osmium tool (http://osmcode.org/osmium/) to
 check
 for referential integrity problems. (If you want to try this yourself, you
 need the git master version.)

Any change of publishing a new release that includes this and other changes?

Kind Regards,

Bas


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

Re: [josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

 On Wed, 17 Jun 2015, Sebastiaan Couwenberg wrote:

 Do you understand the point of view of a distribution like Debian?

 It's clear that you don't share Debians concerns for software freedom
 and
 focus on quality. And you're not alone in that, that's why it's always
 Debian people that bring up those issues, the rest of the Open Source
 community doesn't care enough.

 We did major efforts to clear the license situation of JOSM some time ago
 and also did other requested changes. But what you request has NOTHING to
 do with the Debian ideals. You can simply request code changes and when
 your get told that this is nonsense answer with well, but you don't care
 for Debian ideals.

The license changes were and are still much appreciated, by myself and the
wider Free Software community. But that's not the topic of discussion,
that's the new JCS requirement.

 Do you care enough about this issue to file a bug report so that it
 doesn't get lost again (e.g. when I give up on josm packaging out of
 sheer
 frustration)?

 Refer to the documentation how to file a bug using the reportbug utilty
 or
 plain email:

 You already know it, so why file a report and then I remember that I tried
 once and then gave up, so I don't try that again.

Because you cannot be bothered I did you a favor and filed the bug report:

https://bugs.debian.org/789161

We already patch the build.xml to append the following to the REVISION file:

 Debian-Release: ${debian.version}

We also patch Version.java  AboutAction.java to use this value in the
About box.

Based on the comments in build.xml we should also add the following to
have the value used for the stats identification:

 Build-Name: Debian

I've updated the patch to implement the above, and it will be included in
the next upload to unstable. It will then finds its way into the next
Debian and Ubuntu releases.

Kind Regards,

Bas


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

Re: [josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

 On Thu, 18 Jun 2015, Nelson A. de Oliveira wrote:

 I'm not aware of any other distribution, which tries to tell developers
 that
 they should not use another some open source code with valid license or
 implement workarounds so that packagers are happy. I've never done this
 or
 heard of this for openSUSE and I created and maintain a lot of packages
 there.

 The problem isn't using another software/code/lib/etc, but using a
 local or embedded copy.

 No. The request is that we do not use it or make it optional.

I only asked if it was possible to make it optional, to quote my initial
email:


 Would it be possible to make JCS an optional dependency and use the
 previous caching mechanism if it's not available?

 This would make it easier to package current JOSM tested snapshots (and
 backports for these) until JCS is more widely available in distributions
 (JCS 2.0 is still at beta1).


Thanks for continuously misrepresenting my words.

Kind Regards,

Bas


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

Re: [josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

On 06/18/2015 03:57 PM, Dirk Stöcker wrote:
 On Thu, 18 Jun 2015, Sebastiaan Couwenberg wrote:
 
 No. The request is that we do not use it or make it optional.

 I only asked if it was possible to make it optional, to quote my initial
 email:
 ...
 Thanks for continuously misrepresenting my words.
 
 Do we speak different languages?

Apparently we do. So it's no use to continue this discussion with you.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

 On Wed, 17 Jun 2015, Vincent Privat wrote:

 We understand the problem but I don't know if keeping the old cache is
 easy
 nor feasible. Wiktor what do you think? Is the old code still there or
 has
 it been dropped during the switch ?

 Actually I DO NOT see the problem.

 Debian requires building from source which is true for most other
 distributions as well. That's fine.

 Debian does nowhere require that a software needs to be split into
 multiple pieces. That may have some advantages but also has a series of
 disadvantages. And if nobody has time to do it, then simply don't do it!

I wish it was that simple. While the Debian Policy does not explicitly
require splitting out embedded dependencies, it's a very common packaging
best practice.

Debian does recommend upstream developers to not include 3rd party code, see:

https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code

While it's phrased mostly for C/C++ shared libraries, it applies to Java
projects just the same.

 JCS is now an integral part of JOSM. As it is also a library it could be
 provided by another package. But that's not required and also can be
 changed at any time in the future.

 Altogether I never understood the way Debian packages JOSM and from user
 side it's complicated, error prone and also wastes space on harddisk. To
 fulfill Debian guidelines building a jar from source would be perfectly
 fine like you build binaries for other tools.

 So Debian packages do a lot of actually unnecessary work and need constant
 adaption to changing source code. But that's the choice of package
 maintainers and no requirement.

This attitude makes me want to remove the josm package from Debian again.

Last time this caused a number of users of the josm package in Debian to
object, instead of pushing for the removal of the package I started to
co-maintain the package. That went surprisingly well until recently,
mostly thanks to Vincent who's been a superb upstream to work with.

Kind Regards,

Bas




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

Re: [josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

 I can try to have a look but I never packaged something on Debian before.
 Is there a Debian packaging for dummies somewhere? :)

The Debian New Maintainers' Guide is the official resource for people new
to Debian packaging:

https://www.debian.org/doc/manuals/maint-guide/

For the Debian GIS team we also have the team policy documenting best
practices:

http://pkg-grass.alioth.debian.org/policy/index.html#introduction

The Debian Java team, under whose umbrella the JCS package and
dependencies are most appropriate, also has some minimal documentation on
the wiki:

https://wiki.debian.org/Java/Packaging

Unfortunately the debian-maven-helper tool is not documented very well,
and this is the tool you'll most likely use to package Apache Commons
projects. There is only an example:

https://wiki.debian.org/Java/MavenDebianHelper

Kind Regards,

Bas


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

Re: [josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

On 06/17/2015 09:28 AM, Wiktor Niesiobedzki wrote:
 I don't quite understand what's your goal. All dependencies are
 included in josm*.jar. Do you intend to create your own *jar for
 distribution without dependencies and use separate packages to provide
 them?

For software to be included in Debian the software itself and all its
dependencies need to be built from source, because Debian cares deeply
about its commitment to Free Software.

Just shipping JARs is not acceptable because .class files are not
source. While shipping binaries is the norm in the Java world, this is
incompatible with the Free Software principle of allowing users to
modify the software they receive. That requires the software in its
preferred form for modification (source code).

I'm not happy with the switch to JCS. The 2.0 branch is still in beta
and doesn't look very mature yet. Its requirement to build JOSM has
prevented me from keeping the josm Debian package in sync with the
latest tested snapsnots. Having the previous caching mechanism available
too would allow us to keep using that until JCS 2.0 matures and has
packaging available.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

 But when you download the source code from our repository, you will get
 all the dependencies. Ant build will create a jar that will contain all
 necessary dependencies within. What's wrong with such approach?

Bundling dependencies is not a good thing. Take JMapViewer for example, we
build this separately in Debian because it's also used by Freeplane. If
both josm  freeplane were to bundle the dependency we need to apply
updates and bugfixes to both copies instead of just the component itself.

There will be other software that will use JCS in once that's packaged in
Debian, bundling JCS in JOSM prevents these other projects from benefiting
from the JCS build.

Kind Regards,

Bas


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

Re: [josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

 We understand the problem but I don't know if keeping the old cache is
 easy
 nor feasible. Wiktor what do you think? Is the old code still there or has
 it been dropped during the switch ?
 Even if it's possible, it might lead to Debian specific bugs...

I'm afraid keeping the old caching as an alternative is not an option,
that's why I didn't raise the issue before. If it is possible, this would
remove the barrier preventing josm updates in Debian though.

 Couldn't we help you to package JCS on Debian instead?

Yes that's possible and very much appreciated. Have a look at the JCS
Request For Package bug where I've recorded my progress.

https://bugs.debian.org/783538

There are too few contributors to the Debian GIS team to allow me to
dedicate sufficient time to packaging JCS and maintaining it in the long
term. All my time is currently consumed preparing transitions for GDAL 
SpatiaLite, reviewing and sponsoring uploads for others, and mentoring a
new contributor. The Debian Java team is likewise understaffed, so I can't
blame them for the lack of help with packaging JCS. Everyone has enough on
their plate with the packages we maintain already to not jump at the
request for a new package they don't need themselves.

Kind Regards,

Bas


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

Re: [josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

 On Wed, 17 Jun 2015, Sebastiaan Couwenberg wrote:

 I wish it was that simple. While the Debian Policy does not explicitly
 require splitting out embedded dependencies, it's a very common
 packaging
 best practice.

 A recommendation is still no requirement.

 Debian does recommend upstream developers to not include 3rd party code,
 see:

 While there are common practices to make software packaging friendly, it
 is strange when a distribution tries the explain developers how they
 should develop their software. Especially as Debian does not follow common
 guidelines itself.

Do you have concrete examples or are your just spreading FUD?

 So Debian packages do a lot of actually unnecessary work and need
 constant
 adaption to changing source code. But that's the choice of package
 maintainers and no requirement.

 This attitude makes me want to remove the josm package from Debian
 again.

 Last time this caused a number of users of the josm package in Debian to
 object, instead of pushing for the removal of the package I started to
 co-maintain the package. That went surprisingly well until recently,
 mostly thanks to Vincent who's been a superb upstream to work with.

 Because Vincent is a nice guy and tries to make everybody happy. And
 probably also because he does not know the whole history.

 But if I look at the history, then from all the possible Linux
 distributions out there packaging JOSM only Debian is coming permanently
 to request that we change it here and there and do that and this. And
 because of self-applied restriction which aren't even required.

Do you understand the point of view of a distribution like Debian?

It's clear that you don't share Debians concerns for software freedom and
focus on quality. And you're not alone in that, that's why it's always
Debian people that bring up those issues, the rest of the Open Source
community doesn't care enough.

 And together with that requests from our side have simply been ignored
 many times. E.g. the debian build is still not marked in a way, that we
 could see them in our stats. Recomendation still is to add DEBIAN or
 D in the version string like SVN for the self-builds.

I'm happy to make such a change, but this request is unknown to me. The
previous maintainer is unable to maintain his many packages, it's quite
likely he's the only one who was asked this.

Do you care enough about this issue to file a bug report so that it
doesn't get lost again (e.g. when I give up on josm packaging out of sheer
frustration)?

Refer to the documentation how to file a bug using the reportbug utilty or
plain email:

https://www.debian.org/Bugs/Reporting

Kind Regards,

Bas


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

[josm-dev] JCS as optional dependency

[Sebastiaan Couwenberg]

Would it be possible to make JCS an optional dependency and use the
previous caching mechanism if it's not available?

This would make it easier to package current JOSM tested snapshots (and
backports for these) until JCS is more widely available in distributions
(JCS 2.0 is still at beta1). There are still several missing pieces to
get JCS packaged in Debian for example.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[osmosis-dev] Version 0.44 release

[Sebastiaan Couwenberg]

The Detailed Description documentation on the wiki redirects to the 0.44
documentation from a while, but the latest stable tarball and git tag
are still at 0.43.1.

Is it time for an official 0.44 release to get the changes in the master
branch more widely available?

For the osmosis Debian package I've been including patches from the
master branch already, but I prefer to drop them in favor of a new
upstream release that includes those changes.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] Osm2pgsql 0.87.3 release

[Sebastiaan Couwenberg]

On 05/01/2015 02:32 PM, Sarah Hoffmann wrote:
 On Fri, May 01, 2015 at 11:32:34AM +0200, Sebastiaan Couwenberg wrote:
 Because GitHub issue #231 wasn't resolved again, I didn't think the
 lockfree issue was fully addressed in this release and therefor didn't
 remove the option on the problematic architectures initially.
 
 As far as I understood the ticket, it is boost here that doesn't have
 its dependencies right, i.e linking against boost_atomic in
 osm2pgsql is more of a workaround for broken boost installations than
 an actual necessity.
 
 If you have to patch the Debian build anyways, it might be better to
 add the additional link dependency than adding --without-lockfree.
 At the very least it would be intersting to know if it resolves the issues.

I've done a few test builds on the arm64 and ppc64el porterbox where
--without-lockfree is not used, but -lboost_atomic is appended to
LDFLAGS instead. This also addresses the build failures on these two
architectures too.

The question is now why the build system doesn't do this automatically
as it does on the unproblematic architectures.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[josm-dev] New JMapViewer release for JOSM 8109

[Sebastiaan Couwenberg]

Hi all,

The Debian package for JOSM 8109 fails to build because it uses
TemplatedTMSTileSource() introduced in jmapviewer r30933.

Are you planning a JMapViewer 1.06 release to accompany JOSM 8109?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-dev] ogr2osm coordinate precision

[Sebastiaan Couwenberg]

On 07/01/2014 08:04 AM, Frederik Ramm wrote:
 Hi,
 
 On 07/01/2014 12:19 AM, Sebastiaan Couwenberg wrote:
 Using Replace Geometry preserves the history of the objects, enables
 easy tag merging, and restores borders to their official geometry.
 
 If you are saying that you regularly kill any modifications made by
 mappers and replace the OSM geometry with some official shape file
 without even investigating who changed what and why, then you are
 clearly acting against OSM best practice and you should stop!
 
 OSM is not intended to be a mirror of some official data set. You may
 edit OSM's data with the aid of third party data - but not blindly and
 without looking at what you are doing.

If we want addresses to use the correct city, the settlement boundaries
should match the official dataset.

I'm almost insulted by your insinuation that changes are not checked,
but I consider it just your communication style.

 How do you make sure that you are not overwriting a change that someone
 has made on purpose because there was a mistake in the official geometry?

Using the history of the objects in question.

All changes made to administrative boundaries in The Netherlands over
the past two years by users other than myself were either mistakes
(connecting non-boundary ways to boundaries and moving the connected
node, or deleting whole boundary ways by mistake or combining ways) or
additions of suburb boundaries (our infamous admin_level 11).

 Bye
 Frederik

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-dev] ogr2osm coordinate precision

[Sebastiaan Couwenberg]

On 06/30/2014 01:35 AM, Paul Norman wrote:
 
 On 2014-06-29 2:24 PM, Sebastiaan Couwenberg wrote:
 Currently ogr2osm outputs OSM node element using 9 decimal places for
 lat/lon coordinates, shouldn't it use 7 decimal places instead to match
 the documentation?
 
 OSM nodes in general have no limit on precision. Nodes stored in the API
 do. Editors will generally need higher precision to avoid accumulated
 errors with geometry manipulation operations.

 ogr2osm uses the --sigificant-digits and --rounding-digits options to
 set the precision, and uses the default values of 9 and 7 respectively.

 The significant digits is essentially only used for the output. The
 internal storage uses an integer multipled by 10**significant, but that
 actually cancels out with
 https://github.com/pnorman/ogr2osm/blob/master/ogr2osm.py#L499-L500
 
 Rounding digits is used for deduplicating nodes, and should always be =
 significant digits. The reason for this is that many data sources come
 with errors where coordinates are *supposed* to be the same in two
 linestrings, but aren't, so they don't always get correctly merged. NHD
 is one source where this is particularly bad. Decreasing
 --rounding-digits to 5 or so may help with NHD (see the Hoover Dam for a
 good test).
 
 As the deduplication takes place deep in the internals in a tight loop
 and is one of the longest parts of converting file, it running fast is
 important, so complicated radius calculations are out.
 
 With most data sources, the default values are fine.

Thanks for the clarifications.

I agree that the default values are fine, especially regarding their use
in deduplication.

Because the API returns nodes with only 7 decimal places, would you
recommend the use of --sigificant-digits=7 when the resulting OSM data
is intended for updating existing data in OSM (using Replace Geometry in
JOSM)?

This way the coordinates downloaded from the API would match those from
ogr2osm, and needlessly modifying the node coordinates with a higher
precision could be prevented.

Kind Regards,

Bas

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

Re: [OSM-dev] ogr2osm coordinate precision

[Sebastiaan Couwenberg]

On 06/30/2014 11:35 PM, Frederik Ramm wrote:
 Hi,
 
 On 06/30/2014 11:08 PM, Sebastiaan Couwenberg wrote:
 This way the coordinates downloaded from the API would match those from
 ogr2osm, and needlessly modifying the node coordinates with a higher
 precision could be prevented.
 
 Why would anyone use JOSM's replace geometry method to replace a
 geometry with something that looks identical?

I can't speak for anyone, but I use it to update both the geometry and
tagging with the new data from ogr2osm.

My use case are the administrative borders in The Netherlands and the
~monthly updates affecting a subset of settlements.

Using Replace Geometry preserves the history of the objects, enables
easy tag merging, and restores borders to their official geometry.

The ways only look identical at high zoom levels, the low zoom levels
show that they aren't identical.

At least merging the start and end nodes of the way to replace is
required to not break the ring when replacing the geometry.

Even though the start and end nodes have not moved and still use the
same coordinates (albeit with a higher precision), the osmChange will
modify the node but only increase its version still setting the same
coordinates.

That would be the JOSM bug Paul hinted at, and the source of my quest to
improve the extracts I use to maintain the boundaries in OSM.

Kind Regards,

Bas

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

[OSM-dev] ogr2osm coordinate precision

[Sebastiaan Couwenberg]

Currently ogr2osm outputs OSM node element using 9 decimal places for
lat/lon coordinates, shouldn't it use 7 decimal places instead to match
the documentation?

The wiki documentation lat/lon values says:


float
≥ −90.0 and ≤ 90.0
with 7 decimal places


http://wiki.openstreetmap.org/wiki/Node#Structure


ogr2osm uses the --sigificant-digits and --rounding-digits options to
set the precision, and uses the default values of 9 and 7 respectively.

https://github.com/pnorman/ogr2osm/blob/master/ogr2osm.py#L113

ogr2osm uses the --sigificant-digits value for the precision in the
output. Should it use the --rounding-digits value or even a separate
variable specifically for the output?

https://github.com/pnorman/ogr2osm/blob/master/ogr2osm.py#L557

I was tempted to submit a pull request but didn't, because I'm not sure
if it's a bug or if I'm just missing something.

Kind Regards,

Bas

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