pnorman/ogr2osm

New Maintainer

Closed this issue · 10 comments

Firefishy commented

@pnorman has put out a request seeking a new maintainer for ogr2osm

I'm currently maintainer of https://github.com/pnorman/ogr2osm, but I no 
longer have the interest or time to keep up with issues filed and PRs. 
If someone is interested in maintaining it, please let me know and I can 
transfer the repo.

Source: https://lists.openstreetmap.org/pipermail/dev/2021-March/031105.html

Firefishy commented

Obviously really appreciate @pnorman for being awesome :-)

Firefishy commented

@roelderickx maybe you interested? It would be good to maintain this as a general purpose tool.

roelderickx commented

First of all, I would like to thank @pnorman and all other contributors for their commitment on this project.

Last week I noticed the quest for a new maintainer on the openstreetmap developer mailinglist and I already gave it a first thought. I am willing to continue the development and I believe I can free up enough time to maintain the project.

As you probably already saw I needed specific functionalities for another project and I ended up rewriting ogr2osm to become ogr2pbf. That means I have a full understanding of the code, but since I am not a mapper my knowledge about the OSM file format is limited. I probably need to catch up with that first, as well as some basics on ogr datasources.

Where I already took the project:

  • Most of the issues of ogr2osm have been addressed in ogr2pbf.
  • PBF output is added. OSM output is still possible and I have no plans on removing that.
  • Python 2 support is removed in favour of python 3. This should not be a problem today and if needed, pnorman's version will not disappear.
  • It is object oriented and useable as a library now. There is definitely a need for this, see the issue opened by @dericke as well as his fork and the project already depending on ogr2pbf.
  • The translation files now use a class in stead of loose functions. It is at least easier to maintain, but it implies everyone should rewrite their translations. It may be a first step in a solution for issue 14.
  • More test cases are added to ensure compatibilty with ogr2osm

What needs to be done:

  • Review the license. As @pnorman pointed out in one of the issues, it is not a pure MIT license.
  • Remove the mandatory dependency on protobuf, there are several use cases and most of them do not require PBF output
  • Revert the name of the repository to ogr2osm and set OSM output as the default

Any thoughts? Is there a specific direction you want this project to go? Are there primary use cases I need to familiarize with?

  • 👍2
pnorman commented

I haven't done anything with ogr2osm in a few years, so I don't feel I should be setting any direction. I've invited roelderickx to this repository. I've given @roelderickx access.

If we're going to continue with the current ogr2pbf code and rename it, I'd suggest renaming that repo and we can link from here to there.

roelderickx commented

Thanks @pnorman

Meanwhile the suggested changes are done in my fork: protobuf is not a mandatory dependency anymore, osm output is the default and the repository is renamed to ogr2osm.

During the next week I will continue to close a few issues which are either already solved in pnorman's version or which are not ogr2osm issues.

We'll see what's next, if everyone agrees to continue with my version I will:

  • close the issues already resolved in my version, commenting on how it is solved
  • keep issues containing useful information open for historical reference
  • recreate the remaining issues in my fork, with a link to the original issue
  • review both open pull requests and either close or merge them (I don't know what I'll decide yet, it is not really relevant at this point)
  • update the ogr2osm OSM wiki page

The objective should be that @pnorman does not have to bother about open issues or pull requests anymore, and that people are instructed to clone the actively maintained fork.

roelderickx commented

Unless there are objections I will link from here to my version in a few days and adapt the OSM wiki accordingly. I will continue to provide long term support on pnorman's version for those who still use python 2 or those who need more time to convert their translation files. This will be strictly limited to bugfixes.
A PyPI package will be created as described in roelderickx#2: version 1.*.* will be created from this branch, version 2.*.* and up will be the latest maintained version.

Firefishy commented

I'd suggest dropping Python 2 support.

I don't think it is necessary to support 2 versions.

roelderickx commented

Thanks for your input @Firefishy.
I will not create a package from this branch because it requires a modification to be done first and I will start at version 1 for my branch.