Hi Christian, Sorry for answering so late, it escaped me. There was a difference in approach. Cheesybiscuits and Martin rightfully pointed out what the standard allows for. However, my position was: ’you need to find a sensible way to deal with your spatial infrastructure and that might not include everything you can do’. So, theirs was a technical, mine an organisational view.
Things get complicated by itself, as Martin demonstrated with his road-casing example. So, I want to keep it as simple as possible. There are cases where you cannot. But going back to your problem, there are a few thoughts how I would approach things. If you write everything in one sld, you have the advantage of a single source of truth, but the problem is that you need to do regression testing in case something changes. If you change the design for one layer, you must answer the question: does this label/filter/pattern/whatever also work for the other layer it is applied to? So, you may opt to separate them. The simple length of a sld is a point of consideration for me as well. The possible re-use by others is also a point of consideration for me. Obviously this is easier if the style is simpler. Well, there is an offset, the style has to be complicated enough to save you work, i.e. not trivial and general enough to be applied with little re-work. So, it is about balance. A very simple and similar problem to yours: We have a layer ‘bushfire prone areas’, which was derived from a 10m grid and as a consequence is highly complicated and slow to load. For that reason there is another generalised layer from 50K upwards. The sld’s are called SCHEMA_layername_authorShorthand_number.sld and in two files. The two layers are called using a layergroup. Good about that is: there is only one layer to test with one sld. Bad is: if I change the colour I must not forget the other sld. There is also the issue of metadata. Both layers are an expression of the same data, so there is only one metadata record, which is connected to the layergroup and displayed. I don’t show the single layers. The layer group cannot help you to select the ‘correct’ layer at a particular scale, only the filter (in the sld) can do that. If you have one or more attributes you can use for filtering (in my case road_type and road_classes come to mind -- http://docs.geoserver.org/stable/en/user/styling/sld-reference/filters.html http://www.opengeospatial.org/standards/filter ) then use it or them to chop up your dataset and if there is none, it may be sensible to create a variable. Filters and their syntax are worth knowing because even if you do not use them in SLDs, you will use them in WFS. I love Martin’s example with the variable, haven’t tried that. Layergroups, however, can encapsulate the logic, which different layers or parts of the same layer are assembled as a spatial feature class that you want as and is shown as one unit. That includes, which layers are on top of the others. Whatever you choose to do, follow it through and spend some time and think about naming conventions of your layers, slds and groups or use something like svn to administer your slds and versions of them. With these things there is no right or wrong. It seems I am for the simple things, you are not. If you’re (unlike me) highly organised then go for the complicated structures. That is the beauty of Geoserver that it gives you the choice. However, you do not want to sit in front of your own work when revisiting stuff thinking: ‘what the hell did I think, when I did this and why did I do it this way?’ I think, that is a position ‘cheesybiscuits’ and Martin can wholeheartedly agree to. Cheers Christian ----- ____________________________ Dr Christian Maul Project Manager Information Services Branch Department of Sustainability and Environment Level13, Marland House, 570 Bourke Street Melbourne 3000 PO Box 500, East Melbourne Vic 3002 Telephone: +61-3-8636 2325 Telefax: +61-3-8636 2813 -- View this message in context: http://osgeo-org.1560.n6.nabble.com/SLD-drawing-order-tp4948595p5004147.html Sent from the GeoServer - User mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
