RE: [mapserver-users] SOS response XML validity
Very good, thanks for the reply, so we'll have to wait for the fix Best regards, Massimo Ferraguto -Original Message- From: Kralidis,Tom [Ontario] [mailto:tom.krali...@ec.gc.ca] Sent: Mon 16 February 2009 17:01 To: Massimo Ferraguto; mapserver-users@lists.osgeo.org Subject: RE: [mapserver-users] SOS response XML validity I have created a mapfile to generate a SOS response containing data from a database. I have understood that mapserver supports only flat reporting of the database columns to the xml response. My problem is that I wonder whether this kind of flat response is valid or not. If I try to validate the response against the xml schema I get errors. How can I solve this problem of xml validity against the schema? Here are the errors: *** Error start *** Element observedProperty is not allowed under element om:Observation. Reason: The following elements are expected at this location (see below) om:observedProperty om:resultQuality Annotations of type 'om:ObservationType' (see below) Base type for Observations. Observation is an act (event), whose result is an estimate of the value of a property of the feature of interest. The observed property may be any property associated with the type of the feature of interest. The following properties are inherited from AbstractFeatureType: Error location: om:ObservationCollection / om:member / om:Observation / observedProperty Details cvc-model-group: Element observedProperty unexpected by type 'om:ObservationType' of element om:Observation. cvc-elt.5.2.1: The element om:Observation is not valid with respect to the actual type definition 'om:ObservationType'. *** Error end *** after modifying observedProperty == om:observedProperty I get another error: *** Error start *** Text 'temperature' is not allowed for element om:observedProperty. The element declaration's content type is 'element-only'. Error location: om:ObservationCollection / om:member / om:Observation / om:observedProperty Details cvc-complex-type.2.3: Text 'temperature' is not allowed for element om:observedProperty. The element declaration's content type is 'element-only'. cvc-elt.5.2.1: The element om:observedProperty is not valid with respect to the actual type definition 'swe:PhenomenonPropertyType'. *** Error end *** Here is an example response that I get from my server: ?xml version=1.0 encoding=ISO-8859-1? om:ObservationCollection xmlns:gml=http://www.opengis.net/gml; xmlns:ows=http://www.opengis.net/ows/1.1; xmlns:swe=http://www.opengis.net/swe/1.0.1; xmlns:xlink=http://www.w3.org/1999/xlink; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:sos=http://www.opengis.net/sos/1.0; xmlns:om=http://www.opengis.net/om/1.0; gml:id=htb_offering xsi:schemaLocation=http://www.opengis.net/om/1.0 http://schemas.opengis.net/om/1.0.0/om.xsd; gml:description xmlns:gml=http://www.opengis.net/gml;htb data/gml:description gml:name xmlns:gml=http://www.opengis.net/gml;Helsinki test bed data/gml:name om:member om:Observation om:samplingTime gml:TimeInstant gml:timePosition20081127042000/gml:timePosition /gml:TimeInstant /om:samplingTime om:procedure xlink:href=urn:ogc:def:procedure:temperature/ om:observedPropertytemperature/om:observedProperty om:result gml:featureMember xmlns:gml=http://www.opengis.net/gml; gml:temperature gml:boundedBy gml:Envelope gml:lowerCorner25.399600 60.316000/gml:lowerCorner gml:upperCorner25.399600 60.316000/gml:upperCorner /gml:Envelope /gml:boundedBy msGeometry gml:Point gml:pos25.399600 60.316000/gml:pos /gml:Point /msGeometry locationid37/locationid insertionTime20081127042054/insertionTime latitude60.316/latitude longitude25.3996/longitude leveltypealtitude/leveltype levelvalue17/levelvalue levelunitm/levelunit version1/version parameterNametemperature/parameterName value-1.1/value unitC/unit aggregationNameinstant/aggregationName aggregationValue0/aggregationValue aggregationUnitn/a/aggregationUnit formn/a/form /gml:temperature /gml:featureMember /om:result /om:Observation /om:member /om:ObservationCollection Note that we're working on validating the SOS GetObservation output (see http://trac.osgeo.org/mapserver/ticket/2646), and what is in svn trunk is very close to a valid XML document. We're close to having this for 5.4. ..Tom
[mapserver-users] incorrect minscale using php mapscript
Hi all, I'm using php mapscript (MS 5.2.1 on Windows) in my client and have problems with the minscale from the WEB-Section of my mapfile. For example if I set MINSCALE 1 on an imgsize with 1618 x 907 pixels the minscale for creating an image is 17848 on an imgsize with 822 x 503 pixels the minscale is 16355 I get the same wrong scale setting the minscale with mapscript: $map-web-set(minscale, 1); where is the error? Thanks Sven ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Status on ticket 2582?
Hi! Thanks Daniel for taking responsibility for this issue, which has been around for far to long :-) I agree that ticket 1952 discusses a more flexible functionality, but I don't think we need to make this more complicated than it is already. I can't see a situation where you would like to hide a layer from one service type, but not in an other (but thats my opinion). Fixing the 2582 bug would satisfy many of the user needs on this issue. Taking the GROUP functionality into consideration seems to be important, as this possibly could cause some mixup if a hidden layer is inside a group layer. What if all layers inside a GROUP is hidden? Should the group layer still be exposed in the capabilities document? I'd say yes, but other may have a different opinion. Regards, Pål Kristensen Martin Kofahl wrote: Perfect! Although the solution described in ticket 1952 might be more flexible for future use. Daniel Morissette wrote: paalkr wrote: Hi all devs! What is the status on ticket http://trac.osgeo.org/mapserver/ticket/2582 2582 ? Is this going to be included in 5.4? Yes, we'll take care of it for 5.4. Daniel ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- View this message in context: http://n2.nabble.com/Status-on-ticket-2582--tp2337548p2341220.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Pyhton mapscript import error
I am getting error while importing mapscript in python snip import mapscript Traceback (most recent call last): File stdin, line 1, in ? File mapscript.py, line 7, in ? import _mapscript ImportError: /usr/local/lib/python2.4/site-packages/_mapscript.so: undefined symbol: _ZN3agg6gse5x7E /snip when i removed the AGG suport in Mapserver , i am able to import without any error. But my application requires AGG support (ie. with Tilecache) I am using Mapserver 5.2.1, AGG 2.5, Python 2.4 on CentOS. Thanks for any help. Gautam -- View this message in context: http://n2.nabble.com/Pyhton-mapscript-import-error-tp2341344p2341344.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
RE: [mapserver-users] Scalebar (and C# mapscript) issue
Murty, It works fine for me using MapServer 5.0.2 with an equirectangular projection using a WGS84 geoid reference whether I'm zoomed to a world view or to a street-level view. Be sure you are setting the scalebar units member accordingly in C#. For example, scalebar.units = (int)OSGeo.MapServer.MS_UNITS.MS_FEET to set the units to feet. However, I have noted that it will appear garbled and squashed in width if you use units which are not meaningful for the current zoomed area. In other words, don't use inches when zoomed to a city or world view.the numbers are too large to display properly. Write a routine that sets the appropriate units based on the delta degrees that you are showing. For example, if the user chose English units (versus metric) and the current viewport spans roughly ~0.5 nautical miles, then set the units to inches. If the viewport is 0.5 NM and 1 NM, set the units to feet. Otherwise (the viewport spans more than 1 NM), set the units to miles. You can tweak this idea to suit your needs but this works well for me. Brian NOTE: The views expressed are the author's and do not necessarily reflect the official position of LinQuest Corporation or any of its subsidiaries or the organization providing Internet access. From: mapserver-users-boun...@lists.osgeo.org [mailto:mapserver-users-boun...@lists.osgeo.org] On Behalf Of Murty Maganti Sent: Friday, February 13, 2009 2:20 PM To: mapserver-users@lists.osgeo.org Subject: [mapserver-users] Scalebar (and C# mapscript) issue Hello I am having strange issue with scalebar. I have scalebar displayed on map (embed) and scale units are set to miles. It has size of 200x10 pixels. It shows up fine on the map. Then at run time (using C# map script), I just change the units to feet or meters and the bar size shrinks (to almost 10 pixels length), which appears strange to me. Why would the scalebar length changes by changing units. Is there any other setting I need to set to maintain the same scalebar size? This works fine (or not noticeable) for maps which have extents at city level. I am testing on map which displays Ontario province (Canada). Also, you need to have projection elements defined at both map and layer level. In my case, the projection is same (WGS 1984). Thanks Murty ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
RE: [mapserver-users] Scalebar (and C# mapscript) issue
Hi Brian I had verified my code and there is no issue setting the units correctly in C#. In fact, I see the same issue setting the units to feet in map file directly. It seems there is some rounding issue when the scale values are too large. Please see the ticket http://trac.osgeo.org/mapserver/ticket/2890. Thanks a lot for your response. Murty From: Hulbert, Brian [mailto:brian.hulb...@linquest.com] Sent: Tuesday, February 17, 2009 11:13 AM To: Murty Maganti; mapserver-users@lists.osgeo.org Subject: RE: [mapserver-users] Scalebar (and C# mapscript) issue Murty, It works fine for me using MapServer 5.0.2 with an equirectangular projection using a WGS84 geoid reference whether I'm zoomed to a world view or to a street-level view. Be sure you are setting the scalebar units member accordingly in C#. For example, scalebar.units = (int)OSGeo.MapServer.MS_UNITS.MS_FEET to set the units to feet. However, I have noted that it will appear garbled and squashed in width if you use units which are not meaningful for the current zoomed area. In other words, don't use inches when zoomed to a city or world view...the numbers are too large to display properly. Write a routine that sets the appropriate units based on the delta degrees that you are showing. For example, if the user chose English units (versus metric) and the current viewport spans roughly ~0.5 nautical miles, then set the units to inches. If the viewport is 0.5 NM and 1 NM, set the units to feet. Otherwise (the viewport spans more than 1 NM), set the units to miles. You can tweak this idea to suit your needs but this works well for me. Brian NOTE: The views expressed are the author's and do not necessarily reflect the official position of LinQuest Corporation or any of its subsidiaries or the organization providing Internet access. From: mapserver-users-boun...@lists.osgeo.org [mailto:mapserver-users-boun...@lists.osgeo.org] On Behalf Of Murty Maganti Sent: Friday, February 13, 2009 2:20 PM To: mapserver-users@lists.osgeo.org Subject: [mapserver-users] Scalebar (and C# mapscript) issue Hello I am having strange issue with scalebar. I have scalebar displayed on map (embed) and scale units are set to miles. It has size of 200x10 pixels. It shows up fine on the map. Then at run time (using C# map script), I just change the units to feet or meters and the bar size shrinks (to almost 10 pixels length), which appears strange to me. Why would the scalebar length changes by changing units. Is there any other setting I need to set to maintain the same scalebar size? This works fine (or not noticeable) for maps which have extents at city level. I am testing on map which displays Ontario province (Canada). Also, you need to have projection elements defined at both map and layer level. In my case, the projection is same (WGS 1984). Thanks Murty ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Question re: city points layers and markers
Gregory Collins wrote: Hello all, Sorry if this question has an answer in the existing documentation but I've been struggling for days and can't find a solution. I'm trying to render a city points layer on a regional-level map. I want point markers to be placed for all of the cities which are important enough to get labels, but no markers for unlabeled cities. If I use a layer of type point, I get markers for all of the points, which I don't want. The documentation says that for annotation layers, Annotation means that a label point will be calculated for the features, but the feature itself will not be drawn although a marker symbol can be optionally drawn, but I can't seem to get it to draw the markers. What am I doing wrong? G. It would probably help if you show the LAYER definition from your mapfile. -Steve W ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Question re: city points layers and markers
Stephen Woodbridge wood...@swoodbridge.com writes:
Gregory Collins wrote:
Hello all,
Sorry if this question has an answer in the existing documentation but
I've been struggling for days and can't find a solution.
I'm trying to render a city points layer on a regional-level map. I want
point markers to be placed for all of the cities which are important
enough to get labels, but no markers for unlabeled cities.
If I use a layer of type point, I get markers for all of the points,
which I don't want. The documentation says that for annotation layers,
Annotation means that a label point will be calculated for the
features, but the feature itself will not be drawn although a marker
symbol can be optionally drawn, but I can't seem to get it to draw the
markers.
What am I doing wrong?
G.
It would probably help if you show the LAYER definition from your mapfile.
-Steve W
Here's an elided version (the rest of the classes in this layer are
similar):
# Layer NamedPlc ###
LAYER
CONNECTION
MYSQL:Navteq,user=***,password=***,host=***,tables=NamedPlc
CONNECTIONTYPEOGR
DATA SELECT the_geom, poi_name, population,
capital FROM NamedPlc WHERE MBRIntersects(GeomFromText('Polygon((%ominx%
%ominy%, %ominx% %omaxy%,%omaxx% %omaxy%, %omaxx% %ominy%,%ominx% %ominy%))'),
the_geom) ORDER BY population DESC
LABELCACHEon
LABELITEM poi_name
MINSCALEDENOM 3381.6146550891413
MAXSCALEDENOM 886496206.5436879
NAME NamedPlc
TYPE annotation
PROJECTION
proj=longlat
ellps=WGS84
datum=WGS84
END #projection
#-
CLASS
# country capital at level 0
OUTLINECOLOR 80 0 0
EXPRESSION ('[capital]' == '1')
SYMBOL unfilledcircle
OVERLAYCOLOR 80 0 0
OVERLAYOUTLINECOLOR 80 0 0
OVERLAYSYMBOLstar
OVERLAYSIZE 11.0
LABEL
ANGLE 0.0
COLOR 255 255 255
FONT roman
OUTLINECOLOR 0 0 0
PARTIALS False
PRIORITY 10
SIZE 11.0
TYPE truetype
END #(end label)
SIZE 11.0
END #(end country capital at level 0)
G.
--
Gregory Collins g...@gregorycollins.net
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] trying new label positioning - no change
I'm trying the new label positioning improvements for polygons in trunk from http://trac.osgeo.org/mapserver/ticket/606 but AUTO seems to be ignoring the initial CC in the new ordering - with no collisions with other labels, all polygons are labelled at the UL corner of the polygon center. Are there special conditions for AUTO/CC to work? A typical label I'm trying is: LABEL COLOR 0 100 222 SHADOWCOLOR 218 218 218 SHADOWSIZE 1 1 OUTLINECOLOR 255 255 255 TYPE TRUETYPE FONT helvetica-italic SIZE 9 POSITION AUTO WRAP '|' PRIORITY 5 MINFEATURESIZE 16 END AUTO: inline: Picture-1.png POSITION CC does work to label polys at CC: inline: Picture-2.png PS. the new gravity positioning is nice! - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] help on SQL Server 2008 + C# map script
Hi
After firing queryByShape() on SQL Server 2008 layer, getting junk
characters for those field which are null (or have no value) in the
database. Shows fine for those fields with some value.
When I run any sample query on the table in query analyzer, I see the
output as {null}.
If the value is null in the database, I should be getting null reference
or empty string (using C# map script i.e. shapeObj.values). Why I am
getting junk characters.
Appreciate any help.
Thanks
Murty
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Status on ticket 2582?
Hm, I'm not certain sure if MS_DELETE is really a good value for the STATUS key. It's more an attribute ... 'STATUS ON, MS_DELETE'. Using MS_DELETE coequal with OFF would break the DEFAULT value which is quite useful when avoiding grouped layers -- I don't like nesting in the Capabilities document because of one simple copyright layer which can be hidden an set to default. As far as I can see there are three possible solutions: - adding MS_DELETE as an attribute to ON, OFF and DEFAULT (not sure how hard to implement) - adding a new keyword HIDDEN [false|true] coequal to STATUS - some kind of ows_hidden 'true' in the metadata (I'm neither sure when one could require a distinction by service type) Kind regards Martin paalkr wrote: Hi! Thanks Daniel for taking responsibility for this issue, which has been around for far to long :-) I agree that ticket 1952 discusses a more flexible functionality, but I don't think we need to make this more complicated than it is already. I can't see a situation where you would like to hide a layer from one service type, but not in an other (but thats my opinion). Fixing the 2582 bug would satisfy many of the user needs on this issue. Taking the GROUP functionality into consideration seems to be important, as this possibly could cause some mixup if a hidden layer is inside a group layer. What if all layers inside a GROUP is hidden? Should the group layer still be exposed in the capabilities document? I'd say yes, but other may have a different opinion. Regards, Pål Kristensen Martin Kofahl wrote: Perfect! Although the solution described in ticket 1952 might be more flexible for future use. Daniel Morissette wrote: paalkr wrote: Hi all devs! What is the status on ticket http://trac.osgeo.org/mapserver/ticket/2582 2582 ? Is this going to be included in 5.4? Yes, we'll take care of it for 5.4. Daniel ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] help on SQL Server 2008 + C# map script
I guess it's due to a problem in the mssql driver which doesn't properly
handle the null value condition.
Please file a ticket about this issue and I'll look into the details
shortly.
Best regards,
Tamas
2009/2/17 Murty Maganti mmaga...@oriongis.com
Hi
After firing queryByShape() on SQL Server 2008 layer, getting junk
characters for those field which are null (or have no value) in the
database. Shows fine for those fields with some value.
When I run any sample query on the table in query analyzer, I see the
output as {null}.
If the value is null in the database, I should be getting null reference or
empty string (using C# map script i.e. shapeObj.values). Why I am getting
junk characters.
Appreciate any help.
Thanks
Murty
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Problem with loading map file using C# map script
Hi I have a issue loading a map file through map script and need help. I have two map info (tab) files with same name but in two different folders. I have two map files each containing each layer. I am loading these map files using C# map script (each map file is loaded in to a separate mapObj on a separate thread). At run time, when I debug the second mapObj, the layer has items (layerObj.getItem()) from the first layer loaded by the first map file. I verified 'shapepath' on mapObj and it is pointing to correct path. There is nothing wrong there. I am surprised how is it caching the item info, just by the file name (file name is same but they are completely from different folders). When I load the map file one more time (again a different .Net thread, it shows up correct fields). Within my app (Asp.Net), I can consistently replicate this. Thanks Murty ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Problem with loading map file using C# map script
Hmmm. I haven't found such an issue before. If you could post an example that would be helpful to reproduce this. Best regards, Tamas 2009/2/18 Murty Maganti mmaga...@oriongis.com Hi I have a issue loading a map file through map script and need help. I have two map info (tab) files with same name but in two different folders. I have two map files each containing each layer. I am loading these map files using C# map script (each map file is loaded in to a separate mapObj on a separate thread). At run time, when I debug the second mapObj, the layer has items (layerObj.getItem()) from the first layer loaded by the first map file. I verified 'shapepath' on mapObj and it is pointing to correct path. There is nothing wrong there. I am surprised how is it caching the item info, just by the file name (file name is same but they are completely from different folders). When I load the map file one more time (again a different .Net thread, it shows up correct fields). Within my app (Asp.Net), I can consistently replicate this. Thanks Murty ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Pyhton mapscript import error
Hi, python mapscript + agg is a real pain I grabbed a howto file some months ago, on PerryGeo blog (http://www.perrygeo.net/wordpress/) find it here as attachment it works fine. I've just tested it again few minutes ago. Regards Guillaume gautamvs a écrit : I am getting error while importing mapscript in python snip import mapscript Traceback (most recent call last): File stdin, line 1, in ? File mapscript.py, line 7, in ? import _mapscript ImportError: /usr/local/lib/python2.4/site-packages/_mapscript.so: undefined symbol: _ZN3agg6gse5x7E /snip when i removed the AGG suport in Mapserver , i am able to import without any error. But my application requires AGG support (ie. with Tilecache) I am using Mapserver 5.2.1, AGG 2.5, Python 2.4 on CentOS. Thanks for any help. Gautam # agg #agg 2.4 # based on http://trac.osgeo.org/mapserver/ticket/2215 tar -xzvf agg2.4.tar.gz cd agg2.4 emacs src/Makefile # add to CXXFLAGS ... -fPIC CXXFLAGS= $(AGGCXXFLAGS) -I../include -L./ -fPIC # add to the end of file shared: $(OBJ) ../font_freetype/agg_font_freetype.o $(CXX) -shared -W1,-soname,libagg.2.4.so -o libagg.so \$(OBJ) ../font_freetype/agg_font_freetype.o -L/usr/local/lib -lfreetype make cd examples/X11 emacs Makefile #Change: #-I/usr/local/include/freetype2 \ #To: #`freetype-config --cflags` \ # add to both CXXFLAGS .. -fPIC ## CXXFLAGS= $(AGGCXXFLAGS) -I../../include \ -L../../src \ $(PIXFMT) -fPIC CXXFREETYPEFLAGS= $(AGGCXXFLAGS) -Wall \ -I../../include \ -I../../font_freetype \ `freetype-config --cflags` \ -L../../src \ $(PIXFMT) -fPIC ## make freetype cd ../../font_freetype/ ar r libaggfontfreetype.a agg_font_freetype.o cd ../src ln -s ../font_freetype/libaggfontfreetype.a cd .. make clean make cd src make shared sudo cp libagg.so /usr/local/lib sudo ldconfig # mapserver ./configure --without-tiff --with-jpeg --with-png --with-freetype \ --with-zlib --with-threads --with-proj \ --with-gdal=/usr/local/bin/gdal-config --with-wcs --with-ogr \ --with-wmsclient --with-wfsclient --with-wfs \ --without-pdf --with-geos --enable-debug --with-agg=/home/perry/src/agg-2.4 \ --with-postgis=/usr/bin/pg_config \ --with-curl-config=/usr/bin/curl-config --with-httpd=/usr/sbin/apache2 --with-gd=/usr/local \ --with-fastcgi make sudo cp mapserv /usr/lib/cgi-bin/ sudo cp shp2img shp2pdf shptree shptreetst shptreevis sortshp tile4ms scalebar legend msencrypt mapserv /usr/local/bin/ #mapscript cd mapscript/python # swig -python -shadow -modern -o mapscript_wrap.c ../mapscript.i swig -python -shadow -modern -templatereduce -fastdispatch -fvirtual -fastproxy \ -modernargs -castmode -dirvtable -fastinit -fastquery -noproxydel -nobuildnone \ -o mapscript_wrap.c ../mapscript.i python setup.py build cd tests/cases python runalltests.py -v # don't worry about the 4 test failures .. due to postgres database not being present cd ../.. sudo python setup.py install --force___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Re: Mapserver layer selects - resolved
I have finally resolved this issue by upgrading to 8.3.6 and then dropping and recreating the relevant GIST geometry index. Could this be a manifestation of the GIST bug fixed in 8.3.6? Cheers, Stephen On Saturday 14 February 2009 13:55:08 Stephen Davies wrote: Further to my earlier question. I have experimented further and now get the following results: benparts=# SELECT * from swip3 WHERE (pid in (select probe.id from probe where logger_id in (select id from logger where client_id=120)) and rdate='2009-02-12 13:30:00') and (geom setSRID( 'BOX3D(138.5356633 -34.99,138.5397151 -34.8)'::BOX3D,4283) ); id | zname | pid | geom | rdate +---+-+--+--- (0 rows) benparts=# SELECT * from swip3 WHERE (pid in (select probe.id from probe where logger_id in (select id from logger where client_id=120)) and rdate='2009-02-12 13:30:00') and (geom setSRID( 'BOX3D(138.5 -34.99,138.6 -34.9)'::BOX3D,4283) ); id | zname | pid |geom| rdate ++-++-- --- 28 | Zone 2 | 607 | 010120BB107ADFF8DA335161406551D845D17541C0 | 2009-02-12 13:30:00 (1 row) benparts=# SELECT astext(geom) from swip3 WHERE (pid in (select probe.id from probe where logger_id in (select id from logger where client_id=120)) and rdate='2009-02-12 13:30:00'); astext - POINT(138.53758 -34.920449) (1 row) The only thing that changes between query 1 and query 2 is that I have increased the extent constraint. However, as query 3 shows, the point is clearly within the smaller original extent so should have been returned by query 1. No??? Cheers, Stephen -- = Stephen Davies Consulting P/L Voice: 08-8177 1595 Adelaide, South Australia.Fax : 08-8177 0133 Computing Network solutions.Mobile:040 304 0583 VoIP:sip:1132...@sip1.bbpglobal.com ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] trying new label positioning - no change
William: In my testing a polygon layer is definitely starting at position CC. Any chance you're using an annotation layer here? I have found an issue if that's the case. The decision to using one set of positions vs another is made based on the layer type NOT the geometry type. So annotation layers are treated as point layers regardless of the source geometry. As the code sits now that information is lost. Wasn't an issue previously since we didn't vary things. I'll file a bug on this issue. Let me know if this isn't the case for you. One work around is to ditch annotation layers for polygons. They really aren't necessary with the addition of the label priority support in 5.0. Steve William Kyngesburye wokl...@kyngchaos.com 02/17/09 2:55 PM (Sorry, OSX mail habit, the images would be inline next to appropriate text descriptions) The first is POSITION AUTO. Not what I was expecting. The second is POSITION CC. What I was expecting for AUTO, now. On Feb 17, 2009, at 2:29 PM, Steve Lime wrote: So what are pictures 1 2 representing? There's certainly a difference and I would have expected picture 2 to represent the new labeling with CC as the first choice. Steve On 2/17/2009 at 12:42 PM, in message 7da25c07-8345-491d-b082-b268ee480...@kyngchaos.com, William Kyngesburye wokl...@kyngchaos.com wrote: I'm trying the new label positioning improvements for polygons in trunk from http://trac.osgeo.org/mapserver/ticket/606 but AUTO seems to be ignoring the initial CC in the new ordering - with no collisions with other labels, all polygons are labelled at the UL corner of the polygon center. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] trying new label positioning - no change
On Feb 17, 2009, at 11:02 PM, Steve Lime wrote: William: In my testing a polygon layer is definitely starting at position CC. Any chance you're using an annotation layer here? I have found an issue if that's the case. The decision to using one set of positions vs another is made based on the layer type NOT the geometry type. So annotation layers are treated as point layers regardless of the source geometry. As the code sits now that information is lost. Wasn't an issue previously since we didn't vary things. I'll file a bug on this issue. Let me know if this isn't the case for you. O. I've always used annotation layers for feature annotation. But, if it always treats annotation layers as point layers, why does ANGLE FOLLOW work on annotation layers of line features, or gravity positioning on annotation of poly features? Or does that trigger stepping out of the assumed-point default somehow? I did notice when poking around in the source that the labelling routines didn't know about the geometry of individual features. In my own early (v4.4) attempts at reordering the positions for polys (before the recent changes) I added a parameter to the addlabel() functions to pass the shapetype. One work around is to ditch annotation layers for polygons. They really aren't necessary with the addition of the label priority support in 5.0. I'm not sure what you mean here - how does label priority invalidate annotation layers? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life. - Marvin ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] trying new label positioning - no change
Comments inline... William Kyngesburye wokl...@kyngchaos.com 02/17/09 11:34 PM On Feb 17, 2009, at 11:02 PM, Steve Lime wrote: William: In my testing a polygon layer is definitely starting at position CC. Any chance you're using an annotation layer here? I have found an issue if that's the case. The decision to using one set of positions vs another is made based on the layer type NOT the geometry type. So annotation layers are treated as point layers regardless of the source geometry. As the code sits now that information is lost. Wasn't an issue previously since we didn't vary things. I'll file a bug on this issue. Let me know if this isn't the case for you. O. I've always used annotation layers for feature annotation. But, if it always treats annotation layers as point layers, why does ANGLE FOLLOW work on annotation layers of line features, or gravity positioning on annotation of poly features? Or does that trigger stepping out of the assumed-point default somehow? A shapes geometry is used when deciding where to compute a label point. In this case the we're deciding on what the acceptable position array is and that's done when processing the cache, long after the label points original geometry has been destroyed. I did notice when poking around in the source that the labelling routines didn't know about the geometry of individual features. In my own early (v4.4) attempts at reordering the positions for polys (before the recent changes) I added a parameter to the addlabel() functions to pass the shapetype. I think I'd just pass a shapeObj pointer to the msAddLabel() and harvest what is necessary: type and a few indexes. One work around is to ditch annotation layers for polygons. They really aren't necessary with the addition of the label priority support in 5.0. I'm not sure what you mean here - how does label priority invalidate annotation layers? The principle reason to use annotation layers was to control the order in which labels are stuffed into the cache. They were especially useful with polygons since you typically draw those first but if you want to emphasize labels then you'd have to use annotation to make the labels show before other stuff. Label priorities fix that. You can give a polygon layer high priority labels without having to resort to annotation layers later in the mapfile. The benefits (besides working around this bug) are two-fold: 1) performance, you only have to process the polygon features once... 2) brevity, shorter, more concise layer definitions are good... Certainly annotation layers are still useful but principally for things like copyright notices or road shields. Steve ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] trying new label positioning - no change
On Feb 18, 2009, at 12:15 AM, Steve Lime wrote: I did notice when poking around in the source that the labelling routines didn't know about the geometry of individual features. In my own early (v4.4) attempts at reordering the positions for polys (before the recent changes) I added a parameter to the addlabel() functions to pass the shapetype. I think I'd just pass a shapeObj pointer to the msAddLabel() and harvest what is necessary: type and a few indexes. If you think this is something that can be done, it would be nice have geometry and annotation layers both use the same positioning rules based on the geometry type (see comments below). I'm not sure what you mean here - how does label priority invalidate annotation layers? The principle reason to use annotation layers was to control the order in which labels are stuffed into the cache. They were especially useful with polygons since you typically draw those first but if you want to emphasize labels then you'd have to use annotation to make the labels show before other stuff. Label priorities fix that. You can give a polygon layer high priority labels without having to resort to annotation layers later in the mapfile. The benefits (besides working around this bug) are two-fold: 1) performance, you only have to process the polygon features once... 2) brevity, shorter, more concise layer definitions are good... Certainly annotation layers are still useful but principally for things like copyright notices or road shields. Steve Hmm, but mixing the annotations with their geometry in a single layer means you can't turn geometry and annotations on and off separately - I often want to show just the feature geometry, yet be able to turn on their annotations if I need it. Also, what about the drawing order? Won't other feature layers then draw on top of earlier feature layers and annotations of those layers? Or does the label cache force ALL annotations to draw last, no matter what layer they're on? I guess I need a visual diagram of the [now many] various possible combinations of layer types, annotations, priorities and layer ordering to make sense of this. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Time is an illusion - lunchtime doubly so. - Ford Prefect ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Loading Geotiff to PostGIS
Hi all, I got one hill to climb when deloping application using mapserver. I The porblem is, how to store raster data in PostGIS/Postgres SQL. There are multiple ideas I am working on right now I have many satellite raster data in geotiff format (one image data is about 1 GB), I am trying to load these raster data into PostGIS and then wants to render them in web browser through mapserve r(just display them on a top layer acoording to the query extent). my questions are 1. Can we store actually raster data directly in PostgreSQL or PostGIS or we should store it in outside of PostGIS and have some sort ofreference to PostGIS with other data. 2. If we can store the raster data directly in PostGIS, how can upload geotiff image to PostGIS? i know PostGIS can not support raster data input. 3. can mapserver query the PostGIS efficiently with the huge geotiff data? I am a newer to mapserver and PostGIS, Is there someone has the experience with Mapserver PostGIS to handle geotiff image. Any hints and suggestion will be very appreciated. the better one is posting some codes here(if convenient). Thanks very much in advance! Feigle ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
