go-spatial / tegola Goto Github PK

QGIS

Tegola

We may need to be able to render 21 and beyond, but 20 is a good hard stop for now (looks like its 17 currently)

Now that we have got to v0.1 we need to start measuring so that we can know what to optimize. Bring on the benchmarks!

First cut will return the UL & LR points in degrees.

CORS should probably be configurable. Let's use this issue to decide if we want a default of: "Access-Control-Allow-Origin":"*" and if not how much of CORS do we want to make configurable?

... and cli flag to specify where the logs should be written.

MVT styling is leveraging the tags property of features. Should we add support for well known tags: i.e. class?

The MVT tile specification leverages the surveyor's formula to determine the area of a polygon.

It's yet to be determined where this algorithm should live:

• In it's own package
• a util package
• A geometry package.

Alternatively the algorithm could live as a method on a polygon.

The issue with Geometry collections is they only have one gid. This could be an issue when encoding to an MVT tile. If so, we should we dynamically create unique ids for each feature in the geometry collection?

As of now, the geometry collection will not be handled.

I have used pgx with PostGIS and it works great.

MVT only supports integers.

MVT Tiles use protocol buffers as it's transport mechanism; make sure to support this.

This is an issue for multiline SQL statements.

We need to figure out a config file format which will support the following:

• Data providers
  • PostGIS
    • Layer definitions and associated SQL
    • Zoom level
• web server
  • port
  • max zoom? - 18 is suggested by slippy maps spec.
  • max tile size? - currently throws a warining with tile > 500k

MVT have an idea of a Tile, we need to support this.

We should be able to reduce the number of points that are encode at different zoom levels by looking at the delta's to see if they are zero for both x, and y. And for runs of a constant for a coordinate we should be able to combine those.

The server process should accept an flag for the location of the config file.

The goal is to keep project dependencies at a minimum. Any necessary external dependencies need to be included in the the projects `vendor/' folder.

Move SRID from the map to the layer. The SRID should indicate what the underlining srid of the data is for that geometry. We will convert that data WebMercator (3857). If the field is not provided it will be assumed to be in 3857.

When filling out the bounding box, I need to make sure there is an ST_TRANSFORM done on the created envelope. Transforming from 3857 to the passed in SRID. (4326) in this case. Or make sure the envelope in the correct coordinates.

This will create an mvt.Layer with the /Z/X/Y values encoded in the tile.

Currently we throw an error which seems to break some client side libs. Maybe we just render an empty tile?

Mapbox has an SQL method they use for calculating the bounding box of a tile based on web mercator's /z/x/y url scheme. The tile server will need to calculate this, or the data provider will need a function to do so.

https://raw.githubusercontent.com/mapbox/postgis-vt-util/master/postgis-vt-util.sql

Support for instantiating new MVT features

I think we need a different set of labels for our issues then what we have now.

I think the labels should be:

• bug
• feature
• newbie
• enhancement
• question

I don't think we need the others, if we are not going to fix something we should just make comments in the issue.

fuzzing will help us identify any edge case bugs.

Need to setup the travis-ci environment to load up fixture data and a postgis database so that it can run the db and provider tests.