Overpass API developpement

[Igor Brejc <>]

Hi,

In my case I used systemd for two reasons:

1. it was documented on the Overpass API page
   
2. I'm coming from the Windows world, where Windows services (similar to systemd) are a standard way of ensuring a background service is started/stopped cleanly when the system starts/shuts down, so it was an obvious choice for me to use systemd (and I agree with marc's comments for his reasons).

As for my use case, I fall more into the second case (running on a notebook for private use), although my "notebook" is a full-blown server PC that needs to be able to return data for the whole world, and I use it only occasionally, pm-suspending it when not in use. 

Given that I my current systemd setup seems to be working OK now (and I spent too much time setting it up, debugging and documenting everything), I will leave it as it is. 

I see Overpass API as a very valuable tool that helps people to use OSM data even when the dataset is huge and ever-increasing. Right now the barrier of entry for users setting their own private instances is quite high, since you need to have at least a moderate level of Linux knowledge to be able to set it up. Those three steps you mention in the blog post are unfortunately not enough to replicate the whole behavior of the Overpass API public instance - there are still several ways how to import the data, then there are diffs, web server etc. and these can get quite messy, especially if you're doing it for the first time. I tried to document how I did it in my own specific case, from a Linux newby perspective (1), but I think a partially automated installation procedure would be better for the end-user.

Cheers,

Igor

(1) https://wiki.openstreetmap.org/wiki/User:Breki/Overpass_API_Installation

On Fri, Oct 27, 2017 at 9:35 AM, marc marc <> wrote:

Hello,

Le 27. 10. 17 à 07:00, Roland Olbricht a écrit :
> The executive summary is: Don't do it. I'm now happy to figure out with
> the affected people what the use cases behind the intent to use systemd
> are and to pave an alternative path.

the main reason for the osm-fr server is that it's the way to do on
recents systems (debian 9, RHEL/Centos).
the secondary reasons:
- easier to restart services in case of a crash, to manage dependencies
- centralized log management in syslog (although it is also possible to
do this by modifying the init.d script).

in a previous email, I was wondering what was the preferred method for
presenting changes to scripts.
talk about it in this thread ? make an issue + PR on github ?

Regards,
Marc