Thanks for the feedback, reply below
On Wed, Jun 11, 2014 at 10:28 AM, Andrea Aime <[email protected]>
wrote:
> On Wed, Jun 11, 2014 at 9:08 AM, Jody Garnett <[email protected]>
> wrote:
>
>> Sorry Ian I misunderstood, you are aware of the second well-known-graphic
>> trick already.
>>
>> Most of the fixes I can think of are at the GeoTools level:
>>
>> 1) Generic GeoTools fix
>>
>> In SLDStyleFactory getIcon method where most of the magic is happening,
>> we could add a "blacklist" here of known external graphics that were unable
>> to be found, and return a placeholder graphic.
>>
>> 2) GeoServer ExternalGraphicFactory fixreadImage(): General error
>> message. unsupported pixmap format
>>
>>
>> A non invasive change we could do from GeoServer is create our own
>> BlackListGraphicFactory
>> that accepts any external graphic request and returns the placeholder
>> "broken" image. The only trick here would be to arrange the factory sort
>> order so this factory is checked "last" ...
>>
>> 3) Specific ImageGraphicFactory fix
>>
>> The ImageGraphicFactory maintains its own cache (static final). We could
>> teach it to note what images could not be found and return a placeholder.
>> We can also store the placeholder in the cache resulting in a relatively
>> easy to implement blacklist.
>>
>> Option 3 is quickest to implement, Option 1 handles both PNG and SVG.
>>
>
> Hi,
> chiming in late, sorry.
> Option 3 is no go, it will break the SLD mandated fallback mechanism, if
> you have more than one graphic you need to fall back to the next one until
> all possibilities are exhausted.
> Option 2 would similarly not work, because it would break falling back to
> marks
>
> Option 1 is the only real option imho, once you tried _everything_ that
> was in the SLD, fell back and found no options, using a mark (because it
> can be rescaled) that gives the idea of an error
> would be probably a good option.
> Again, not sure if we are going to break the compatibility with the SLD
> spec doing that, so maybe check, and in case, add a flag of sorts to
> control it.
> Adding a good ERROR or WARNING level logging stating that we tried all the
> graphics and none worked would be probably good.
>
Agreed option 1 seems like the best approach.
As for the spec, my reading doesn't provide much about a 'default' fallback
or even whether this should be drawn or reported as an exception. I tried
MapServer[1] to see what it would do and for both se_xml and se_inimage I
got exception reports (no better in quality...) but no default mark.
The implementation I came up with renders a question mark using the ttf
specifier and makes a better, single log message. I'm not too happy with
the way the mark looks, however and I'm thinking a more 'standard' (if
there is such a thing) missing image icon would be better. I suppose this
could be included and referenced via a jar URL?
--
Ian Schneider
Software Engineer | Boundless
[email protected]
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
