New Maintainer

[Firefishy]

@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]

@jendrusk @dericke @roelderickx @simon04 @AdamWill ^^^

[Firefishy]

Obviously really appreciate @pnorman for being awesome :-)

[Firefishy]

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

[Firefishy]

@suke-blog ^^^

[roelderickx]

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?

[pnorman]

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]

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]

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]

I'd suggest dropping Python 2 support.

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

[roelderickx]

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.