On 31/12/12 15:20, Andrea Aime wrote:
>  
> Anyways, let's put that aside and assume that you have some client
> device that actually knows its DPI, or you have a user
> that can tell you about it.
let's assume that :)
> In this case what you suggested in the first mail, we'd first have to
> create a new unit of measure name.
> I would avoid creating a new attribute, would just make the coding
> harder and besides the current units
> contain both real world (metre, foot) and display (pixel).
>
> Given that this is an extension, not something coming from OGC, the
> URI representing the dimension on the target device
> should also probably be clear about its extension nature... how about:
> http://www.opengeospatial.org/se/x-units/target/mm
>
> to specify a size in millimeters on the target device? The "x-units"
> is intended to mark the "extension".
but, isn't the existing uom feature already an extension to SLD?

anyway, I'm happy with whatever naming we come up with.
>
> Others around here are certainly better than me at picking names,
> hopefully they will chime in
> (though we might not hear from them for a few days given we're in the
> middle of vacations for many).
>
> The DPI would have to be provided using the existing vendor parameter
> instead, and we'd default
> to roughly 90 as mandated by OGC if not provided.
sure, good idea
>
> The idea of using the UomRescaleStyleVisitor is a good one, and would
> make for minimal changes.
ok, one question here: currently the uom value is of type Unit<Length> -
which does not allow for including a flag that would show if this unit
is to be interpreted as a real-world size, or as a target-device size. I
wonder if a new type should be created, that would have a Unit<Length>
as a member, and a boolean property showing if this is a target-device
size or a real-world size? would you think of this as a good approach?
> Whatever patch in this area must be accompained by proper unit testing
> to be merged into the code
> base.
sure
>
> The patch would land on trunk first, a discussion about a backport on
> the stable series can also be
> made, the change should not be disruptive.
>
sure


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to