Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid processing layer datasource if status="off" #153

Closed
artemp opened this issue Oct 11, 2011 · 8 comments
Closed

Avoid processing layer datasource if status="off" #153

artemp opened this issue Oct 11, 2011 · 8 comments
Assignees
Milestone

Comments

@artemp
Copy link
Member

artemp commented Oct 11, 2011

Mapnik should skip processing the element for a if the layer status is 'off" or "0".

@artemp
Copy link
Member Author

artemp commented Oct 11, 2011

[migurski] Nonexistent shapefile throws an unexplained RuntimeError in Python in this situation.

@artemp
Copy link
Member Author

artemp commented Oct 11, 2011

[springmeyer] moving to 0.6.0 milestone, since that will be the next release.

@artemp
Copy link
Member Author

artemp commented Oct 11, 2011

[springmeyer] I think all that needs to happen is a conditional skip of layer processing during the load_map() map_parser::parse_layer call:

http://trac.mapnik.org/browser/trunk/src/load_map.cpp#L321

First grab the layer status and if false or 0, skip all the other layer parsing...

I wonder whether there may also be reason to avoid parsing layers attributes in mapnik core too.

It seems as the point this happens is [http://trac.mapnik.org/browser/trunk/include/mapnik/feature_style_processor.hpp#L90 here], which currently should recognize a layer that is not active (http://trac.mapnik.org/browser/trunk/src/layer.cpp#L179), because a non active layer is also not visible.

@artemp
Copy link
Member Author

artemp commented Oct 11, 2011

[springmeyer] It seems that simply parsing the layer datasource attributes is not the right solution, as noted by jonb in irc: http://mapnik.dbsgeo.com/2009-01-21.txt

Pankur, will be interesting to test what you come up with!

I agree that it would be ideal to have all relevant data from the xml read and parsed such that it could then be modified and saved again. It is the performance hit of parsing that I want to avoid, but perhaps that is 'unavoidable'.

@artemp
Copy link
Member Author

artemp commented Oct 11, 2011

[springmeyer] Moving this to 1.0.0 since a design decision is needed.

My original gripe that prompted this ticket was the attempt to store many different layers (that are really more like many different maps) in one xml file was clumsy and slow compared to mapserver.

Context: http://mapnik-utils.googlecode.com/svn/sandbox/benchmarks/

But, I think the mapnik XML should not be used this way and a separate XML file should be used per layer/datasource that applies to resulting map (in this case).

By 1.0.0 perhaps we can at least give thought to how to properly skip layers from a speed perspective...

@artemp
Copy link
Member Author

artemp commented Oct 11, 2011

[springmeyer] above irc link changed - can be found at: http://mapnik.dbsgeo.com/mapnik_logs/2009/01/21

@artemp
Copy link
Member Author

artemp commented Oct 11, 2011

[springmeyer] for mapnik2 release going to take a look at turning status into an ENUM {'on','off','hidden/etc/' rather than boolean. or maybe changing name to visible as per #61

@knowname
Copy link

Note that Nik4 relies on all layers in the style file to be instanciated, since it is possible to enable or disable the layers and fit the boundingbox according to layers which may not be activated. This doesn't work anymore.
As a solution we could introduce status='initialize' or 'load' in addition to status=off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants