[Geotools-devel] [jira] Created: (GEOT-3144) SimpleFeatureTypeBuilder does not set default attribute value
SimpleFeatureTypeBuilder does not set default attribute value - Key: GEOT-3144 URL: http://jira.codehaus.org/browse/GEOT-3144 Project: GeoTools Issue Type: Bug Components: core feature Affects Versions: 2.6.4 Reporter: Sebastian Graca Fix For: 2.6.4 Attachments: SimpleFeatureTypeBuilderTest.java SimpleFeatureTypeBuilder ignores provided default value for attributes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Nominate Shane Bailie for GeoTools commit access
+1 -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Nominate-Shane-Bailie-for-GeoTools-commit-access-tp5097014p5189602.html Sent from the geotools-devel mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] UOM rescaling and DPI
Milton Jonathan ha scritto: > Hey there > > Hmm, I guess I see what you mean, although I feel like it is just a > different way of seeing things. > > Let's see: > > > symbolizers to have the same size. However on the screen 50 pixels > > are long X, whilst when printed the are long just X/3 because the > > priter can cram a lot more pixels in the same space. > > Right, that's why I said that symbolizers given in pixels end up with a > smaller apparent size as DPI increases. > > Now, if you say your symbolizer has a size of 10 pixels, then obviously > it changes size as you change screen resolutions, right? (think monitors > with different resolutions). What I mean is that if the *size of the > pixel* changes, that's another story! So, if you say that you want it to > be invariable in INCHES (or millimeters), then in theory wouldn't inches > be the unit of measure you want, instead of pixels? > > Taking a quick look via Google I found this "OGC OWS-6 Symbology > Encoding (SE) Changes" document (from 2009) > portal.opengeospatial.org/files/?artifact_id=33515 > > It seems to include inches (and millimeters, and some other stuff) as > valid Units of Measure. > > So I guess that would be the way to go if you want things to always show > up with the same apparent size, regardless of DPI issues (if that's what > you want). > > As a final note, I still think that stating a size in meters should keep > the symbolizer proportional to the remainder of the map (as I believe it > does now) So I'm confused... what do you suggest I should do for people that want to get a printout at 300dpi out of a GeoServer GetMap request so that it looks like on screen (no reduced size symbols?). I looked around because I remember MapFish somehow sends the target DPI to MapServer exactly for printing purposes and found this: http://mapserver.org/development/rfc/ms-rfc-55.html They call it defresolution and it's doing basically what I'm suggesting, multiplying all symbol sizes by targetDpi/standarDdpi. Can we find any agreement on how we should call this so that I can move on and deliver this functionality? :-) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] FilterFactory creating by default case insensitive LIKE
I can remember this discussion since I think I pointed out the problem with the indices. And I was against it. I am wondering that this feature is implemented. Nobody, having a little knowledge about db engines would formulate such an SQL clause putting performance for large tables into the cellar. It is better to store the uppercase content into an additional attribute. Anyways, I see some questions on the user lists like "Why is the performance so slow " and then we have to inform the user to not use this feature, but we are offering it. Strange. Quoting Justin Deoliveira : > Yeah seems strange. Although something vaguely familiar perhaps for cite > tests. But I can't recall anything that would require that behavior, I > think case sensitive should be the default. > > On 10-06-16 11:12 AM, Andrea Aime wrote: >> Hi, >> the current filter factory creates case insensitive like filters >> which end up being encoded in sql as upper(att) like 'BLAH%' >> making it impossible to use indexing. >> >> Was that done on purpose or just by accident? >> >> Cheers >> Andrea >> > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > -- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > This message was sent using IMP, the Internet Messaging Program. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3143) FeatureTypes.getAncestors will not terminate if a FeatureType has a getSuper() that is not also a FeatureType
FeatureTypes.getAncestors will not terminate if a FeatureType has a getSuper()
that is not also a FeatureType
-
Key: GEOT-3143
URL: http://jira.codehaus.org/browse/GEOT-3143
Project: GeoTools
Issue Type: Bug
Components: core main
Affects Versions: 2.7-M0, 2.6.4, 2.6.5, 2.7-M1
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies
Fix For: 2.6.5, 2.7-M1
FeatureTypes.getAncestors will not terminate if a FeatureType has a getSuper()
that is not also a FeatureType. This is a simple oversight that caused by
depending on builders that do not set non-features as super.
Discussion:
http://osgeo-org.1803224.n2.nabble.com/Issue-in-2-6-4-FeatureTypes-getAncestors-td5185387.html
{code}
Original Message
Subject: [Geotools-gt2-users] Issue in 2.6.4 FeatureTypes.getAncestors(...)
Date: Wed, 16 Jun 2010 15:52:58 +0800
From: Thorsten Reitz
To: geotools-gt2-us...@lists.sourceforge.net
Hi GeoTools team,
I would have directly put that on the JIRA, but am not sure where to
register:
In GeoTools 2.6.4, there is an issue in FeatureTypes.getAncestors(...)
that will in some cases, specifically when a FeatureType's supertype is
not a FeatureType, but a ComplexType (as it is the case for the
AbstractFeatureType instance, for example, that GeoTools creates by
default) make the function loop indefinitely. This was resolved in 2.5.8
already. We'd suggest the following patch to the function:
public static List getAncestors(FeatureType featureType) {
List ancestors = new ArrayList();
AttributeType type = featureType;
while (type.getSuper() != null) {
if (type.getSuper() instanceof FeatureType) {
FeatureType superType = (FeatureType) featureType.getSuper();
ancestors.add(superType);
}
type = type.getSuper();
}
return ancestors;
}
Kind regards,
Thorsten
--
Thorsten Reitz
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5 | 64283 Darmstadt | Germany
{code}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Nominate Xiangtan Lin for GeoTools commit access
+1 -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Nominate-Xiangtan-Lin-for-GeoTools-commit-access-tp5161768p5188985.html Sent from the geotools-devel mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] UOM rescaling and DPI
Hey there Hmm, I guess I see what you mean, although I feel like it is just a different way of seeing things. Let's see: > symbolizers to have the same size. However on the screen 50 pixels > are long X, whilst when printed the are long just X/3 because the > priter can cram a lot more pixels in the same space. Right, that's why I said that symbolizers given in pixels end up with a smaller apparent size as DPI increases. Now, if you say your symbolizer has a size of 10 pixels, then obviously it changes size as you change screen resolutions, right? (think monitors with different resolutions). What I mean is that if the *size of the pixel* changes, that's another story! So, if you say that you want it to be invariable in INCHES (or millimeters), then in theory wouldn't inches be the unit of measure you want, instead of pixels? Taking a quick look via Google I found this "OGC OWS-6 Symbology Encoding (SE) Changes" document (from 2009) portal.opengeospatial.org/files/?artifact_id=33515 It seems to include inches (and millimeters, and some other stuff) as valid Units of Measure. So I guess that would be the way to go if you want things to always show up with the same apparent size, regardless of DPI issues (if that's what you want). As a final note, I still think that stating a size in meters should keep the symbolizer proportional to the remainder of the map (as I believe it does now) Cheers Milton Andrea Aime wrote: > Milton Jonathan ha scritto: >> Hello Andrea >> >> I don't have any code around me right now, but I can tell you my >> understanding of this topic: >> - DPI should affect the pixels/meter ratio (map scale). >> - Symbolizers given in meters should not change apparent size when DPI >> varies, as the size of the map in meters also remains the same. In >> this situation, when DPI increases the sizes in pixels of both the map >> and the symbolizers should increase proportionately. >> - Symbolizers given in pixels should have a SMALLER apparent size if >> DPI increases: the same number of pixels now represent a smaller size >> in the real world (more dots in the same inch) >> >> That said, I don't think that a new rescaling step should be >> necessary. My feeling is that the DPI setting should affect the map >> scale (pixels/meter) passed over to the UomRescaleStyleVisitor. >> >> Of course, it could be ME who is missing something :P > > Right, my understanding is different than yours. > Think you want to generate an image that you need to send to a printer > doing 300dpi. Your screen is 100dpi or something like that instead. > > The dpi is just an accident of the display technology, but you want the > symbolizers to have the same size. However on the screen 50 pixels > are long X, whilst when printed the are long just X/3 because the priter > can cram a lot more pixels in the same space. > > You want the output to look the same, but to do so, you need to generate > a symbolizer that's 3 times larger in terms of pixel, to preserve its > size in cm. > > So no matter if you are sizing in pixels or in meters, you need to > compensate for the DPI change by rescaling everything by > targetDpi/standardDpi > > Makes sense? > > Afaik this is what uDig does for printing (looking for confirmation > on this one) > > Cheers > Andrea > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Backporting UOM work on 2.6.x
Justin Deoliveira ha scritto: > Is it feasible to only activate it via a system property? This seems to > have been the approach to backporting new features to the stable branch > in the past. Although perhaps this work is too "cross cutting" to do so? Actually yeah, it's doable, the uom rescaling activation is pretty much localized into a couple of spots in the code, so I could just do that, make it depend on a system property Good idea, thanks for the suggestion Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Backporting UOM work on 2.6.x
Is it feasible to only activate it via a system property? This seems to have been the approach to backporting new features to the stable branch in the past. Although perhaps this work is too "cross cutting" to do so? On 10-06-16 12:37 AM, Andrea Aime wrote: > Jody Garnett ha scritto: >> I think that kind of seals the deal andrea; you are the module >> maintainer. As I recall the UOM patch mostly leverages api that was >> introduced for 2.6 but did not yet function? > > Correct, there are no API changes, it's just a matter of applying > a style visitor which is btw well tested (good part of the > patch is actually made of tests) > >> Is there any api changes at all introduced by the patch? If so we >> could talk about them and see if they are significant. Only real >> danger is if the SLD parser or transformer is effected; and even then >> any changes should be additive. > > It is not affected, as far as I can see the uom were already parsed, > but ignored. > Not sure if the uom are encoded back in the transformer > tough, never checked that > > Cheers > Andrea > > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] FilterFactory creating by default case insensitive LIKE
Yeah seems strange. Although something vaguely familiar perhaps for cite tests. But I can't recall anything that would require that behavior, I think case sensitive should be the default. On 10-06-16 11:12 AM, Andrea Aime wrote: > Hi, > the current filter factory creates case insensitive like filters > which end up being encoded in sql as upper(att) like 'BLAH%' > making it impossible to use indexing. > > Was that done on purpose or just by accident? > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] FilterFactory creating by default case insensitive LIKE
On Wed, Jun 16, 2010 at 1:12 PM, Andrea Aime wrote: > Hi, > the current filter factory creates case insensitive like filters > which end up being encoded in sql as upper(att) like 'BLAH%' > making it impossible to use indexing. > > Was that done on purpose or just by accident? seems wrong to me - I don't recall that like filters are supposed to be case insensitive. Ian -- Ian Turton -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] FilterFactory creating by default case insensitive LIKE
Hi, the current filter factory creates case insensitive like filters which end up being encoded in sql as upper(att) like 'BLAH%' making it impossible to use indexing. Was that done on purpose or just by accident? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3142) VirtualTable support does not honor pk and srid settings
VirtualTable support does not honor pk and srid settings Key: GEOT-3142 URL: http://jira.codehaus.org/browse/GEOT-3142 Project: GeoTools Issue Type: Bug Components: data jdbc-ng Affects Versions: 2.7-M0 Reporter: Andrea Aime Assignee: Andrea Aime Fix For: 2.7-M1 Either setting is actually ignored by the code -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] UOM rescaling and DPI
Milton Jonathan ha scritto: > Hello Andrea > > I don't have any code around me right now, but I can tell you my > understanding of this topic: > - DPI should affect the pixels/meter ratio (map scale). > - Symbolizers given in meters should not change apparent size when DPI > varies, as the size of the map in meters also remains the same. In this > situation, when DPI increases the sizes in pixels of both the map and > the symbolizers should increase proportionately. > - Symbolizers given in pixels should have a SMALLER apparent size if DPI > increases: the same number of pixels now represent a smaller size in the > real world (more dots in the same inch) > > That said, I don't think that a new rescaling step should be necessary. > My feeling is that the DPI setting should affect the map scale > (pixels/meter) passed over to the UomRescaleStyleVisitor. > > Of course, it could be ME who is missing something :P Right, my understanding is different than yours. Think you want to generate an image that you need to send to a printer doing 300dpi. Your screen is 100dpi or something like that instead. The dpi is just an accident of the display technology, but you want the symbolizers to have the same size. However on the screen 50 pixels are long X, whilst when printed the are long just X/3 because the priter can cram a lot more pixels in the same space. You want the output to look the same, but to do so, you need to generate a symbolizer that's 3 times larger in terms of pixel, to preserve its size in cm. So no matter if you are sizing in pixels or in meters, you need to compensate for the DPI change by rescaling everything by targetDpi/standardDpi Makes sense? Afaik this is what uDig does for printing (looking for confirmation on this one) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] UOM rescaling and DPI
Hello Andrea I don't have any code around me right now, but I can tell you my understanding of this topic: - DPI should affect the pixels/meter ratio (map scale). - Symbolizers given in meters should not change apparent size when DPI varies, as the size of the map in meters also remains the same. In this situation, when DPI increases the sizes in pixels of both the map and the symbolizers should increase proportionately. - Symbolizers given in pixels should have a SMALLER apparent size if DPI increases: the same number of pixels now represent a smaller size in the real world (more dots in the same inch) That said, I don't think that a new rescaling step should be necessary. My feeling is that the DPI setting should affect the map scale (pixels/meter) passed over to the UomRescaleStyleVisitor. Of course, it could be ME who is missing something :P Cheers Milton Andrea Aime wrote: > Hi, > I'm looking into exposing the DPI setting as part of > the GeoServer WMS request, mostly so that people can > get images to send to a printer with a certain DPI. > > (note: the streaming renderer already takes a hint > allowing to specify the DPI) > > What I expect to see is that the symbolizers sizes > increase as the DPI increases, and also that > the scale computation changes accordingly. > > I guess that the UOM and DPI rescalings should be independent, > so that DPI rescaling works also with symbolizers whose > size is specified in pixels. Am I right, or I'm getting > confused? > > What I see now is that using DPI and UOM in combination > (and without a custom rescaling step for DPI) > does not affect the size of the symbols on the map > because the UOM rescaling computes the rescaling factor > in a way that's DPI independent. > > Yet what I'd expect to see is that increasing the DPI > should increase the symbol sizes. > However, that should also happen when I'm not using UOM. > > So I think I should introduce a separate rescaling step in > streaming renderer to be used when the DPI is not > the default value. But I wanted to double check that. > > Am I missing something? > > Cheers > Andrea > > PS: I see we already have a generic RescaleStyleVisitor, > I guess I'll use that one for DPI handling (maybe double > checking it's doing all the same rescales as the uom one, > which has quite some unit tests backing it) > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3141) Graceful degradation when the native postgis srid cannot be determined
Graceful degradation when the native postgis srid cannot be determined
--
Key: GEOT-3141
URL: http://jira.codehaus.org/browse/GEOT-3141
Project: GeoTools
Issue Type: Improvement
Affects Versions: 2.6.4
Reporter: Andrea Aime
Assignee: Andrea Aime
Priority: Minor
Fix For: 2.6.5
Now when the native srid cannot be determined (think temporarily empty view at
the startup of a long running application, or sql view in which the user failed
to provide the srid) things basically stop working. With a little change we can
have the functionality back, but at a reduced performance:
{code}
modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/PostgisFilterToSQL.java
index 67fe130..219e98f 100644
@@ -62,7 +62,14 @@ public class PostgisFilterToSQL extends FilterToSQL {
} else {
out.write("ST_GeomFromText('");
out.write(geom.toText());
-out.write("', " + currentSRID + ")");
+if(currentSRID == null && currentGeometry != null) {
+// if we don't know at all, use the srid of the geometry we're
comparing against
+// (much slower since that has to be extracted record by
record as opposed to
+// being a constant)
+out.write("', ST_SRID(\"" + currentGeometry.getLocalName() +
"\"))");
+} else {
+out.write("', " + currentSRID + ")");
+}
}
}
{code}
Basically the srid gets sucked from the geometry we compare against. Given it's
not a static value this will likely prevent the usage of a spatial index...
pity, probably better than an error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Making other symbols obstacles for labels
Hi, I'm looking into a request to have the label conflict resolution algorithm consider other graphic elements as obstacles for labeling, in particular point symbolizers, but it could be something else as well. As I understand this is something the ESRI products allow for. The current labeler already has the ability to store a Rectangle2d as an obstacle and uDig is using to avoid labels overlapping with some map decorations, so the labeler itself would not have to be touched, it already has the necessary area reservation abilities. So I guess what I'd need to to mark certain symbolizers as obstacles. Looks like a good occasion to move TextSymbolizer.getOptions() one level up in Symbolizer so that all symbolizers can have vendor options. I guess the sld could look like: ... true and the renderer would process that directive by marking the rectangle2d used by the geometry as busy (this won't work too well will lines, we'd need a bitmap based conflict resolution to do that better). Ah, I'd need to commit the work on 2.6.x as well, and the above would be an API change. What about doing the API change on trunk only and have the code work against the implementations on 2.6.x Otherwise I can setup a git clone just for this work for the time being. Opinions? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] UOM rescaling and DPI
Hi, I'm looking into exposing the DPI setting as part of the GeoServer WMS request, mostly so that people can get images to send to a printer with a certain DPI. (note: the streaming renderer already takes a hint allowing to specify the DPI) What I expect to see is that the symbolizers sizes increase as the DPI increases, and also that the scale computation changes accordingly. I guess that the UOM and DPI rescalings should be independent, so that DPI rescaling works also with symbolizers whose size is specified in pixels. Am I right, or I'm getting confused? What I see now is that using DPI and UOM in combination (and without a custom rescaling step for DPI) does not affect the size of the symbols on the map because the UOM rescaling computes the rescaling factor in a way that's DPI independent. Yet what I'd expect to see is that increasing the DPI should increase the symbol sizes. However, that should also happen when I'm not using UOM. So I think I should introduce a separate rescaling step in streaming renderer to be used when the DPI is not the default value. But I wanted to double check that. Am I missing something? Cheers Andrea PS: I see we already have a generic RescaleStyleVisitor, I guess I'll use that one for DPI handling (maybe double checking it's doing all the same rescales as the uom one, which has quite some unit tests backing it) -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: AppSchemaConfigurationTest failure mystery?
I will have to test tomorrow on my work machine; will let you know then. Jody On 16/06/2010, at 5:09 PM, Ben Caradoc-Davies wrote: > Jody, > > does AppSchemaConfigurationTest now pass on Windows? > > Kind regards, > Ben. > > On 15/06/10 11:23, Ben Caradoc-Davies wrote: >> Jody, I have committed a fix. Please update and try again. Apologies for >> the inconvenience. >> >> On 15/06/10 11:02, Ben Caradoc-Davies wrote: >>> Aieee. Have a look at gt-xsd-core Schemas:114. >>> >>> HashSet. Platform randomisation, not deterministic behaviour across >>> platforms. >>> >>> I now promise to complete my rant "HashMap Considered Harmful" and to >>> send it to this list. This will be followed by my proposal for the Great >>> HashMap Purge of 2010. > > -- > Ben Caradoc-Davies > Software Engineering Team Leader > CSIRO Earth Science and Resource Engineering > Australian Resources Research Centre -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: AppSchemaConfigurationTest failure mystery?
Jody, does AppSchemaConfigurationTest now pass on Windows? Kind regards, Ben. On 15/06/10 11:23, Ben Caradoc-Davies wrote: > Jody, I have committed a fix. Please update and try again. Apologies for > the inconvenience. > > On 15/06/10 11:02, Ben Caradoc-Davies wrote: >> Aieee. Have a look at gt-xsd-core Schemas:114. >> >> HashSet. Platform randomisation, not deterministic behaviour across >> platforms. >> >> I now promise to complete my rant "HashMap Considered Harmful" and to >> send it to this list. This will be followed by my proposal for the Great >> HashMap Purge of 2010. -- Ben Caradoc-Davies Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
