search

mapbox / carto

fast CSS-like map stylesheets
https://cartocss.readthedocs.io/
Apache License 2.0
652 stars 129 forks source link

Support new raster colorization in Mapnik trunk #5

Closed yhahn closed 11 years ago

yhahn commented 13 years ago

Just got word of this work a few moments ago: https://github.com/BenMoores/mapnik-trunk/wiki/RasterColorizer. It should land in trunk next week. Ben is also going to be updating Cascadenik to work with this, so we should have tmcw or kkaefer work in lock step or even bounce ideas off with ben.

tmcw commented 13 years ago

No longer actionable; this api has changed significantly. We'll do another push to support this when it's documented in Mapnik core.

springmeyer commented 13 years ago

https://github.com/BenMoores/mapnik-trunk/wiki/RasterColorizer are valid docs (I would move them to mapnik trac right now but it is down) and I've now applied to mapnik core just now (https://github.com/mapnik/mapnik2/commit/3b8c06ff8a945913b4aac6d3631cea090e1cb107), so re-opening.

springmeyer commented 13 years ago

Also, bens patchs to cascadenik are here that we can grab for css style ideas: https://github.com/BenMoores/Cascadenik/commits/mapnik2

springmeyer commented 13 years ago

whoops, meant to re-open this when I commented.

tmcw commented 13 years ago

All right, let's start thinking about what this might look like then.

Here's a first iteration, borrowing from how CSS Animation Keyframes are represented. I think it's a +1 as far as clarity and flexibility and a -1 because, unlike core CSS, we already have nested styles, and this, on the surface and certainly to a degree in the parser, will be overloading that concept.

springmeyer commented 12 years ago

hmm, looks like this was spuriously closed, re-opening.

springmeyer commented 12 years ago

@tmcw - great sketchup. you think it is ready to apply to test? Also, perhaps we could move this syntax discussion to an issue at https://github.com/mapnik/carto-spec.

@rcoup - I can't track down the original css sketches we had based on mozilla's css3 - any comments from your end?

springmeyer commented 12 years ago

note: raster colorization depends on being able to operate on one band, so to get this to work the user would likely need to pass band=1 to the advanced options for the layer referencing a gdal raster.

rcoup commented 12 years ago

came up with https://gist.github.com/1260522 as a slightly different alternative. Not better, just different :)

Thoughts?

tmcw commented 12 years ago

@rcoup: unfortunately the ::thing pattern is already established in Carto as attachment syntax and wouldn't be dual-purposable for this without making the parsing structure more complex.

I wonder about the selector syntax - that also already exists in Carto, but are bands the only way that one could filter through rasters? It sounds like, from the docs and Dane's comment, that selecting a band would have to be on the level of adding and editing the datasource, not within the stylesheet.

rcoup commented 12 years ago

@tmcw: fair enough, I just felt that an attachment was kinda a good way to think of a stop :)

A datasource points to (for example) a TIF file, but whether it's added to the map as an image (eg. aerial photos), or whether a single band is rendered via a RasterSymbolizer (eg. Digital Elevation Model) seems more up to the stylesheet imo.

Mapnik doesn't support the concept of Raster Attribute Tables or has any other methods of filtering rasters that I know of, and I haven't seen any plans to implement that stuff.

tmcw commented 12 years ago

A datasource points to (for example) a TIF file, but whether it's added to the map as an image (eg. aerial photos), or whether a single band is rendered via a RasterSymbolizer (eg. Digital Elevation Model) seems more up to the stylesheet imo.

Sort of; there's certainly already some interaction between the two levels in Carto and elsewhere. For instance, one can use a filter in a carto expression like #world[name="USA"] and also provide the filter as a SQLite or Postgres select - Carto doesn't attempt to optimize datasources in any kind of magical way in that case. From the Mapnik perspective, it seems that band selection is staying in the datasource level, and thus having this seem like a stylesheet-level setting might be odd, since this'll mean that the stylesheet can create a bunch of datasources if you have 12-band hyperspectral stuff. Just as a 'have we done this before' thing, it'd mean a pretty big break from the current system, which treats the MML datasources as literals rather than things manipulable by the stylesheet.

tmcw commented 12 years ago

Okay, first chunk of work in https://github.com/mapbox/carto/commit/1dcafcc

You can see the style of attributes I'm trying out here: http://ds.io/rWUjcn . I think it's pretty compact, but there's still a lot to do

brudy48 commented 12 years ago

am using TileMill Version 0.9.0 (v0.9.0-141-g1b9a2ab) is any of this supported within that? sorry if this post is in wrong location.

tmcw commented 12 years ago

@brudy48 none of this ticket is implemented yet, so it's not available in any TileMill version.

springmeyer commented 11 years ago

I have reviewed this, tested, and @hrwgc has taken it for its paces. There are a few bugs I'll open other tickets about, but overall I think we should move this to master and let it live.

I do like the idea of being able to set bands at the style level, but like @tmcw notes this just will not work right now given that bands are a concept of the GDAL datasource only in Mapnik. Since I don't see any obvious ways of changing that now, I think we should just live with the major caveat here that colorizing will not work (predictably/at all) unless you've explicitly set the band at the datasource level (In the case of TileMill this would mean passing band=1 to the advanced layer options).

Longer term - say at Mapnik 3.x when Mapnik can make breaking changes, I could see adding first class support for rasters to Mapnik's filter syntax. At that point perhaps all these bits could be re-written and use better syntax. But, until then, or if that never happens, the current approach is definitely functional.

springmeyer commented 11 years ago

follow up issue at #251