tilery / utilery Goto Github PK

Not sure we need to pull out Flask actually, and we may be comfortable with Werkzeug only.

Todo if we go this way:

• manage global database object (and close connection)
• basic config module

It may help to have SQL requests to be run in //.

https://github.com/aio-libs/aiopg

So instead of http://tile.org/recipe1:layername/0/0/0.png we'd have http://tile.org/recipe1/layername/0/0/0.png.
We'd keep the recipe name optional in the URL, and then no recipe name would means default one.

Cons:

• for the consumers, one HTTP call will be needed per recipe (but we can see a recipe as a source, and that doesn't matter at the end that two sources are served by the same piece of code or not, from the consumer point of view)

Pros:

• makes the API much simpler (what is Utilery supposed to answer with an URL like http://tile.org/all+default:all+roads+tgi:xxx+defaults:buildings/0/0/0.png ? Valid request? Invalid? Serve all? serve given layer names?)
• less URL possibilities means easier to cache

My opinion is that recipes as namespaces doesn't match the simplicity mantra of this project.

@cquest thoughts?

We need a bit of documentation for installation, configuration, production usage.

I'm poking around looking for MVT servers and this package looks neat and concise. Is there still interest in maintaining / developing it?

Made the experiment on addok and it's worth it for a pure API.

We need to find a way to install Shapely without needing to sudo apt-get anything.

http://docs.travis-ci.com/user/migrating-from-legacy/#How-do-I-install-APT-sources-and-packages%3F
travis-ci/apt-source-safelist#38

Hello, a bit of supplementary documentation would be great to know how properly launch utilery. Because you can install, configure, then there are no docs about launching. Hopefully there was some notes about it there : https://wiki.openstreetmap.org/wiki/User:Vincent_95/installation_osm142