Re: [mapserver-users] The Case of the Disappearing Roads

[Rahkonen Jukka]

Hi,

Have you tried to use ogrtindex http://www.gdal.org/ogrtindex.html instead of 
tile4ms? Try also if there is any difference if you read the tileindex through 
ogr or with the native Mapserver method. I have found some differencies with 
these options. For example I found this note from my mapfiles (but Even Rouault 
could not reproduce my SDO_BODY error).
#CONNECTIONTYPE OGR #with this SDO_BODY does not work on Linux build (CentOS)
  TILEINDEX "/ms4w/apps/ogrtindextest.shp,0"

-Jukka Rahkonen-

Joseph Marlin wrote:

> I am indeed using tile indices. I didn't think there would be any problem 
> with that
> step, but just to be sure I went ahead and checked. They all looked ok, but I
> noticed that all the features that use tile indexes were the exact features 
> that
> aren't showing up- small roadways, highway shields, etc. This was highly
> suspicious, and so I did a lot of digging.
> 
> I recreated all the index shape files, this time using an old version of the 
> tile4ms
> and shptree utilities that I had fortunately saved when I generated the map in
> 2011, and found that tileindex shapefiles were no much larger, and the map was
> rendered correctly!
> 
> So, all I can say for sure is that the current version of tile4ms and shptree
> definitely did not work. This issue has been reported at least twice before it
> seems,
> http://trac.osgeo.org/mapserver/ticket/4259
> http://www.mail-archive.com/mapserver-
> us...@lists.osgeo.org/msg17207.html
> 
> And I guess it is worth noting that this problem is still present in the 
> latest
> version (MapServer version 6.2.1 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=AGG
> SUPPORTS=FREETYPE SUPPORTS=ICONV INPUT=JPEG INPUT=SHAPEFILE).
> 
> Thanks so so much for your help! Let me know if you need further info.
> Joseph
> 
> 
> 
> - Original Message -
> From: "thomas bonfort" 
> To: "Joseph Marlin" 
> Cc: "MapserverList OSGEO" 
> Sent: Saturday, August 10, 2013 3:18:03 AM
> Subject: Re: [mapserver-users] The Case of the Disappearing Roads
> 
> Another thing to check: are you using a tileindex to reference your 
> shapefiles,
> and if so, is the tileindex up-to-date (i.e. does it reference all your 
> shapefiles).
> 
> --
> thomas
> 
> On 9 August 2013 20:04, Joseph Marlin  wrote:
> > Thanks Thomas for the idea. I think I understand what you're asking. We pre-
> render all our tiles though, so while the screenshots are indeed showing a
> javascript viewer, that viewer is simply loading the prerendered images,
> retrieved from tilecache. And I have made sure that it isn't TileCache 
> storing old
> tiles.
> >
> > - Original Message -
> > From: "thomas bonfort" 
> > To: "Joseph Marlin" 
> > Cc: "MapserverList OSGEO" 
> > Sent: Friday, August 9, 2013 1:54:41 PM
> > Subject: Re: [mapserver-users] The Case of the Disappearing Roads
> >
> > Joseph,
> > are the images you are posting a direct result of a getmap request
> > (i.e. with width=1007&height=454), or are they a screenshot of a
> > javascript client that is doing tiled requests to mapserver?
> > If those are tiled requests, are your layer/class minscale/maxscale
> > settings set to the exact values of your requested resolutions (i.e.
> > their might be some rounding errors in that case that make a
> > scale-dependant class appear or disappear based on floating point
> > rounding errors).
> >
> > --
> > thomas
> >
> > On 9 August 2013 19:03, Joseph Marlin  wrote:
> >> The Case of the Disappearing Roads
> >>
> >> We create shapefiles with SQL querying world data that's been loaded into a
> PostgreSQL database. A python script requests tiles from mapserver at 
> different
> zoom levels, and we generate the entire map like that.
> >>
> >> Now, at the sixth zoom level, level 3 roads (medium size roads) should be
> rendered. However, they are actually rendered only in a small section of the
> world, a box bounded by Toronto in the northwest, Cleveland in the southwest,
> and the Atlantic in the east. Elsewhere, level 3 roads are not rendered at 
> all.
> >>
> >> As you can see in this image: http://i.imgur.com/6McvGOJ.png, the small
> gray roads, level 3 roads, (and highway shields, for that matter) that are 
> visible
> on the top half suddenly stop being rendered by mapserver.
> >>
> >> In all the following more zoomed in levels, no roadways smaller than
> >> level 2 are rendered at all anywhere, as you can see here:
> >> http://i.imgur.com/8MTcPoi.png. I've verified that the shapefiles
> >> contain the data on the smaller roads as I have viewed them just fine
> >> with QGIS, as you can see here: http://i.imgur.com/S3W3Iy8.png
> >>
> >> I'm so confused as to what could possibly make roads disappear midway
> through a level. If it was a problem with my mapfile, why would they show up 
> in
> part of Northeast US, but not anywhere else? Where do I even start looking to
> solve this?
> >>
> >> Thanks so much!
> >>
> >> Additional info:
> >> SRS: EPSG:900913
> >> Zoom levels: 19567.8792375, 9783.93961875, 4891.96

Re: [mapserver-users] The Case of the Disappearing Roads

[thomas bonfort]

Joseph,
This does indead sound like a bug in tile4ms, and a quick test locally
showed I was also unable to create a valid tileindex with tile4ms.
That said, given the (absence of) activity around tile4ms (be it in
code maintenance or user feedback), I would highly recommend to do as
Jukka pointed out, that is to use the orgtindex command.

regards,
thomas

On 12 August 2013 21:22, Jeff McKenna  wrote:
> For good karma (think of it as a way to thank Thomas and others for
> tackling these questions) since you have a problem dataset handy, you
> could create a tiny one or two features sample, with one layer, and
> package all that in an archive with a README.txt and champion this
> change through the tickets you mentioned.
>
> Thanks!
>
> -jeff
>
>
> --
> Jeff McKenna
> MapServer Consulting and Training Services
> http://www.gatewaygeomatics.com/
>
>
> On 2013-08-12 4:14 PM, Joseph Marlin wrote:
>> I am indeed using tile indices. I didn't think there would be any problem 
>> with that step, but just to be sure I went ahead and checked. They all 
>> looked ok, but I noticed that all the features that use tile indexes were 
>> the exact features that aren't showing up- small roadways, highway shields, 
>> etc. This was highly suspicious, and so I did a lot of digging.
>>
>> I recreated all the index shape files, this time using an old version of the 
>> tile4ms and shptree utilities that I had fortunately saved when I generated 
>> the map in 2011, and found that tileindex shapefiles were no much larger, 
>> and the map was rendered correctly!
>>
>> So, all I can say for sure is that the current version of tile4ms and 
>> shptree definitely did not work. This issue has been reported at least twice 
>> before it seems,
>> http://trac.osgeo.org/mapserver/ticket/4259
>> http://www.mail-archive.com/mapserver-users@lists.osgeo.org/msg17207.html
>>
>> And I guess it is worth noting that this problem is still present in the 
>> latest version (MapServer version 6.2.1 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=AGG 
>> SUPPORTS=FREETYPE SUPPORTS=ICONV INPUT=JPEG INPUT=SHAPEFILE).
>>
>> Thanks so so much for your help! Let me know if you need further info.
>> Joseph
>>
>>
>>
>> - Original Message -
>> From: "thomas bonfort" 
>> To: "Joseph Marlin" 
>> Cc: "MapserverList OSGEO" 
>> Sent: Saturday, August 10, 2013 3:18:03 AM
>> Subject: Re: [mapserver-users] The Case of the Disappearing Roads
>>
>> Another thing to check: are you using a tileindex to reference your
>> shapefiles, and if so, is the tileindex up-to-date (i.e. does it
>> reference all your shapefiles).
>>
>> --
>> thomas
>>
>> On 9 August 2013 20:04, Joseph Marlin  wrote:
>>> Thanks Thomas for the idea. I think I understand what you're asking. We 
>>> pre-render all our tiles though, so while the screenshots are indeed 
>>> showing a javascript viewer, that viewer is simply loading the prerendered 
>>> images, retrieved from tilecache. And I have made sure that it isn't 
>>> TileCache storing old tiles.
>>>
>>> - Original Message -
>>> From: "thomas bonfort" 
>>> To: "Joseph Marlin" 
>>> Cc: "MapserverList OSGEO" 
>>> Sent: Friday, August 9, 2013 1:54:41 PM
>>> Subject: Re: [mapserver-users] The Case of the Disappearing Roads
>>>
>>> Joseph,
>>> are the images you are posting a direct result of a getmap request
>>> (i.e. with width=1007&height=454), or are they a screenshot of a
>>> javascript client that is doing tiled requests to mapserver?
>>> If those are tiled requests, are your layer/class minscale/maxscale
>>> settings set to the exact values of your requested resolutions (i.e.
>>> their might be some rounding errors in that case that make a
>>> scale-dependant class appear or disappear based on floating point
>>> rounding errors).
>>>
>>> --
>>> thomas
>>>
>>> On 9 August 2013 19:03, Joseph Marlin  wrote:
 The Case of the Disappearing Roads

 We create shapefiles with SQL querying world data that's been loaded into 
 a PostgreSQL database. A python script requests tiles from mapserver at 
 different zoom levels, and we generate the entire map like that.

 Now, at the sixth zoom level, level 3 roads (medium size roads) should be 
 rendered. However, they are actually rendered only in a small section of 
 the world, a box bounded by Toronto in the northwest, Cleveland in the 
 southwest, and the Atlantic in the east. Elsewhere, level 3 roads are not 
 rendered at all.

 As you can see in this image: http://i.imgur.com/6McvGOJ.png, the small 
 gray roads, level 3 roads, (and highway shields, for that matter) that are 
 visible on the top half suddenly stop being rendered by mapserver.

 In all the following more zoomed in levels, no roadways smaller than level 
 2 are rendered at all anywhere, as you can see here: 
 http://i.imgur.com/8MTcPoi.png. I've verified that the shapefiles contain 
 the data on the smaller roads as I have viewed them just fine with QGIS, 
 as

Re: [mapserver-users] The Case of the Disappearing Roads

[thomas bonfort]

I just had a look, and committed a fix that works for me in
https://github.com/mapserver/mapserver/issues/4259 (will be in 6.2.2
and 6.4.0)

--
thomas

On 13 August 2013 10:49, thomas bonfort  wrote:
> Joseph,
> This does indead sound like a bug in tile4ms, and a quick test locally
> showed I was also unable to create a valid tileindex with tile4ms.
> That said, given the (absence of) activity around tile4ms (be it in
> code maintenance or user feedback), I would highly recommend to do as
> Jukka pointed out, that is to use the orgtindex command.
>
> regards,
> thomas
>
> On 12 August 2013 21:22, Jeff McKenna  wrote:
>> For good karma (think of it as a way to thank Thomas and others for
>> tackling these questions) since you have a problem dataset handy, you
>> could create a tiny one or two features sample, with one layer, and
>> package all that in an archive with a README.txt and champion this
>> change through the tickets you mentioned.
>>
>> Thanks!
>>
>> -jeff
>>
>>
>> --
>> Jeff McKenna
>> MapServer Consulting and Training Services
>> http://www.gatewaygeomatics.com/
>>
>>
>> On 2013-08-12 4:14 PM, Joseph Marlin wrote:
>>> I am indeed using tile indices. I didn't think there would be any problem 
>>> with that step, but just to be sure I went ahead and checked. They all 
>>> looked ok, but I noticed that all the features that use tile indexes were 
>>> the exact features that aren't showing up- small roadways, highway shields, 
>>> etc. This was highly suspicious, and so I did a lot of digging.
>>>
>>> I recreated all the index shape files, this time using an old version of 
>>> the tile4ms and shptree utilities that I had fortunately saved when I 
>>> generated the map in 2011, and found that tileindex shapefiles were no much 
>>> larger, and the map was rendered correctly!
>>>
>>> So, all I can say for sure is that the current version of tile4ms and 
>>> shptree definitely did not work. This issue has been reported at least 
>>> twice before it seems,
>>> http://trac.osgeo.org/mapserver/ticket/4259
>>> http://www.mail-archive.com/mapserver-users@lists.osgeo.org/msg17207.html
>>>
>>> And I guess it is worth noting that this problem is still present in the 
>>> latest version (MapServer version 6.2.1 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=AGG 
>>> SUPPORTS=FREETYPE SUPPORTS=ICONV INPUT=JPEG INPUT=SHAPEFILE).
>>>
>>> Thanks so so much for your help! Let me know if you need further info.
>>> Joseph
>>>
>>>
>>>
>>> - Original Message -
>>> From: "thomas bonfort" 
>>> To: "Joseph Marlin" 
>>> Cc: "MapserverList OSGEO" 
>>> Sent: Saturday, August 10, 2013 3:18:03 AM
>>> Subject: Re: [mapserver-users] The Case of the Disappearing Roads
>>>
>>> Another thing to check: are you using a tileindex to reference your
>>> shapefiles, and if so, is the tileindex up-to-date (i.e. does it
>>> reference all your shapefiles).
>>>
>>> --
>>> thomas
>>>
>>> On 9 August 2013 20:04, Joseph Marlin  wrote:
 Thanks Thomas for the idea. I think I understand what you're asking. We 
 pre-render all our tiles though, so while the screenshots are indeed 
 showing a javascript viewer, that viewer is simply loading the prerendered 
 images, retrieved from tilecache. And I have made sure that it isn't 
 TileCache storing old tiles.

 - Original Message -
 From: "thomas bonfort" 
 To: "Joseph Marlin" 
 Cc: "MapserverList OSGEO" 
 Sent: Friday, August 9, 2013 1:54:41 PM
 Subject: Re: [mapserver-users] The Case of the Disappearing Roads

 Joseph,
 are the images you are posting a direct result of a getmap request
 (i.e. with width=1007&height=454), or are they a screenshot of a
 javascript client that is doing tiled requests to mapserver?
 If those are tiled requests, are your layer/class minscale/maxscale
 settings set to the exact values of your requested resolutions (i.e.
 their might be some rounding errors in that case that make a
 scale-dependant class appear or disappear based on floating point
 rounding errors).

 --
 thomas

 On 9 August 2013 19:03, Joseph Marlin  wrote:
> The Case of the Disappearing Roads
>
> We create shapefiles with SQL querying world data that's been loaded into 
> a PostgreSQL database. A python script requests tiles from mapserver at 
> different zoom levels, and we generate the entire map like that.
>
> Now, at the sixth zoom level, level 3 roads (medium size roads) should be 
> rendered. However, they are actually rendered only in a small section of 
> the world, a box bounded by Toronto in the northwest, Cleveland in the 
> southwest, and the Atlantic in the east. Elsewhere, level 3 roads are not 
> rendered at all.
>
> As you can see in this image: http://i.imgur.com/6McvGOJ.png, the small 
> gray roads, level 3 roads, (and highway shields, for that matter) that 
> are visible on the top half suddenly stop being rendered by m

Re: [mapserver-users] Best way to do a batch reprojection (on windows)

[Rahkonen Jukka]

Hi,

I would say that the multi-projection tileindex is the way to go. You can 
experiment by downloading first Mapserver dev version from 
http://gisinternals.com/sdk/PackageList.aspx?file=release-1600-gdal-mapserver.zip.
 Then you can
a) make a backup copy of your  C:\ms4w\Apache\cgi-bin  directory 
b) copy all the dll files from \DGAL_dev\bin into C:\ms4w\Apache\cgi-bin
c) copy mapserv.exe from \GDAL_dev\bin\ms\apps into C:\ms4w\Apache\cgi-bin

Now you *may* have a MS4W version which supports multi-projection tileindexes. 
For sure this installation is not production safe and Mapserver with mixed 
binaries may not work at all. Better option would be to contact Gateway 
Geomatics http://www.gatewaygeomatics.com/ and ask them to make a custom MS4W 
build for you but then I suppose you must be prepared to use some money for 
making things happen fast.

-Jukka Rahkonen-

> -Alkuperäinen viesti-
> Lähettäjä: mapserver-users-boun...@lists.osgeo.org [mailto:mapserver-users-
> boun...@lists.osgeo.org] Puolesta Evans, James R Civ USAF ACC 84
> RADES/SCZE
> Lähetetty: 13. elokuuta 2013 1:47
> Vastaanottaja: mapserver-users@lists.osgeo.org
> Aihe: Re: [mapserver-users] Best way to do a batch reprojection (on windows)
> 
> Well, the reprojection from NAD83 UTM Zone 16 to WGS84 didn't go so well.
> The edges don't exactly line up so I have a one pixel gap at the upper left 
> hand
> corner, and a big gap at the lower right hand corner.  So, would I have better
> luck reprojecting to some other projection, or should I just leave the data 
> the
> way it is and hope that some future version of Mapserver (MS4W) will support
> multiple projections in the same layer?
> Thanks,
> James
> 
> 
> -Original Message-
> From: Evans, James R Civ USAF ACC 84 RADES/SCZE
> Sent: Thursday, August 08, 2013 10:40 AM
> To: mapserver-users@lists.osgeo.org
> Subject: RE: [mapserver-users] Best way to do a batch reprojection (on
> windows)
> 
> I'm using the latest released version of MS4W, not even the latest debug 
> builds,
> so that probably won't work for me.  I'll see what the result is for this 
> first
> conversion.  It would be nice to be able to have one contiguous layer without
> having to do the reprojection.
> Thanks,
> James
> 
> 
> -Original Message-
> From: Rahkonen Jukka [mailto:jukka.rahko...@mmmtike.fi]
> Sent: Wednesday, August 07, 2013 10:38 PM
> To: Evans, James R Civ USAF ACC 84 RADES/SCZE; mapserver-
> us...@lists.osgeo.org
> Subject: Re: [mapserver-users] Best way to do a batch reprojection (on
> windows)
> 
> Hi,
> 
> Stop what you do, it is not the right thing anymore. It should not be 
> necessary to
> reproject the images into a common projection any more. This page describes
> how Mapserver is planned to be made to support tileindex with mixed
> projections http://mapserver.org/development/rfc/ms-rfc-100.html and this
> one proves that it has been implemented
> https://github.com/mapserver/mapserver/pull/4697. I am not sure but the
> development builds in http://gisinternals.com/sdk/ may include this new
> feature.
> 
> Before this warping to a common coordinate system has been the way to go
> and gdalwarp is for sure good tool for that. I have using it with average
> resampling for aerial images.  However, there is one nasty problem with 
> warping
> images one by one into a common projection and it is caused by the rotation
> that results from warping. Each rotated image will have nodata collards in the
> corner areas and Mapserver must make them transparent when it is serving the
> final layer. It in simple, but only with uncompressed images because effective
> compression methods are lossy and after compression the nodata areas do not
> have just one pixel value like 0,0,0 but they have also close values like 
> 0,1,0 and
> 0,0,1 etc. and those pixels will not be transparent.
> 
> So I would suggest you to stop what you do and start evaluting tileindex with
> mixed projections. Warping images in-a-fly with Mapserver is fast and you do
> not need to be afraid of that. Your WMS users won't be happy with
> EPSG:4326 or any other single projection for the whole USA anyway so there
> would not be any difference, they will ask reprojected images in any case.
> 
> You can start with the JPEG2000 images as they are but if you want more speed
> later you can convert them without reprojecting inte tiled GeoTIFFs with jpeg
> compression. Nodata problem will not occur in this case because images are not
> rotated.
> 
> -Jukka Rahkonen-
> 
> 
> James_in_Utah wrote:
> 
> > Hi,
> > I have the NAIP imagery for CONUS, and it's rather large.  About
> > 4.2TBs,
> of
> JP2 files.  It's projected in 10 UTM zones across the country.  If I'm going 
> to offer
> a single layer with Mapserver, I think I have to reproject all of the files 
> into a
> single projection, say WGS84.  I'm trying to figure out a good way to do that.
> GlobalMapper seems to have this functi

[mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[Andrea Peri]

Hi,

Try.ing to set a label on a MULTILINESTRING dataset.

I set a label with Follow capability.

ANGLE FOLLOW

But I'm having this error:

 msOGRFileNextShape(): OGR error. IllegalArgumentException:
BufferBuilder::bufferLineSingleSided only accept linestrings

Is the Follow compatible with a MultiLinestring dataset or need only simple
linestrings ?

Thx,

-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[thomas bonfort]

there's something strange in your error message... the
singleSidedBuffer stuff is in GEOS, and should have nothing to do in
msOGRFileNextShape. post your whole mapfile layer.

On 13 August 2013 17:42, Andrea Peri  wrote:
> Hi,
>
> I tested trasforming the multilinestring dataset in a linestring dataset but
> the error is still here.
>
> msDrawMap(): Image handling error. Failed to draw layer named
> 'rt_topogr.50k.etichette.topon_idro_50k'.
>
> msOGRFileNextShape(): OGR error. IllegalArgumentException:
> BufferBuilder::bufferLineSingleSided only accept linestrings
>
> So it is not really due to a multilinestring vs linestring question.
>
> The quest carry on.
>
>
>
> 2013/8/13 Andrea Peri 
>>
>> Hi,
>>
>> Try.ing to set a label on a MULTILINESTRING dataset.
>>
>> I set a label with Follow capability.
>>
>> ANGLE FOLLOW
>>
>> But I'm having this error:
>>
>>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
>> BufferBuilder::bufferLineSingleSided only accept linestrings
>>
>> Is the Follow compatible with a MultiLinestring dataset or need only
>> simple linestrings ?
>>
>> Thx,
>>
>> --
>> -
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -
>
>
>
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
>
> ___
> 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] Angle Follow will accept only simple linestring don't MultiLinestring ?

[Andrea Peri]

Hi,

I tested trasforming the multilinestring dataset in a linestring dataset
but the error is still here.

msDrawMap(): Image handling error. Failed to draw layer named
'rt_topogr.50k.etichette.topon_idro_50k'.
msOGRFileNextShape(): OGR error. IllegalArgumentException:
BufferBuilder::bufferLineSingleSided only accept linestrings

So it is not really due to a multilinestring vs linestring question.

The quest carry on.



2013/8/13 Andrea Peri 

> Hi,
>
> Try.ing to set a label on a MULTILINESTRING dataset.
>
> I set a label with Follow capability.
>
> ANGLE FOLLOW
>
> But I'm having this error:
>
>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
> BufferBuilder::bufferLineSingleSided only accept linestrings
>
> Is the Follow compatible with a MultiLinestring dataset or need only
> simple linestrings ?
>
> Thx,
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
>



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[Andrea Peri]

I'm using spatialite 4.1.1,
so use ogr to access the db.

  LAYER
NAME "rt_topogr.50k.etichette.topon_idro_50k"
STATUS OFF
EXTENT 1554750.74 4678325.52 1771722.76 4924791.90
TYPE LINE
CONNECTIONTYPE OGR
CONNECTION "/path-to-spatialite/zz_topografica.sqlite"
DATA "select PK_UID_2, TOPO_OK, GEOMETRY from topon_idro_50k"
PROJECTION
  "+init=epsg:3003 +towgs84=0,0,0,0,0,0,0"
END
METADATA
  "wms_title" "topon_idro_50k"
  "wms_extent" "1554750.74 4678325.52 1771722.76 4924791.90"
END
LABELCACHE ON
MAXSCALEDENOM 60100
MINSCALEDENOM 1
CLASS
  NAME ''
  MAXSCALEDENOM 60100
  MINSCALEDENOM 1
  LABEL
TEXT '[TOPO_OK]'
COLOR 0 85 255
OUTLINECOLOR 212 255 255
OUTLINEWIDTH 1
MAXSCALEDENOM 60100
MINSCALEDENOM 40100
FONT "LiberationSans-Regular"
TYPE truetype
SIZE 7
ANGLE FOLLOW
OFFSET 15 99
POSITION auto
PRIORITY 10
MAXOVERLAPANGLE 180.0
BUFFER 1
FORCE OFF
PARTIALS FALSE
MINDISTANCE 200
  END
  LABEL
TEXT '[TOPO_OK]'
COLOR 0 85 255
OUTLINECOLOR 212 255 255
OUTLINEWIDTH 1
MAXSCALEDENOM 40100
MINSCALEDENOM 1
FONT "LiberationSans-Regular"
TYPE truetype
SIZE 9
ANGLE FOLLOW
OFFSET 15 99
POSITION auto
PRIORITY 10
MAXOVERLAPANGLE 180.0
BUFFER 1
FORCE OFF
PARTIALS FALSE
MINDISTANCE 200
  END
END
  END




2013/8/13 thomas bonfort 

> there's something strange in your error message... the
> singleSidedBuffer stuff is in GEOS, and should have nothing to do in
> msOGRFileNextShape. post your whole mapfile layer.
>
> On 13 August 2013 17:42, Andrea Peri  wrote:
> > Hi,
> >
> > I tested trasforming the multilinestring dataset in a linestring dataset
> but
> > the error is still here.
> >
> > msDrawMap(): Image handling error. Failed to draw layer named
> > 'rt_topogr.50k.etichette.topon_idro_50k'.
> >
> > msOGRFileNextShape(): OGR error. IllegalArgumentException:
> > BufferBuilder::bufferLineSingleSided only accept linestrings
> >
> > So it is not really due to a multilinestring vs linestring question.
> >
> > The quest carry on.
> >
> >
> >
> > 2013/8/13 Andrea Peri 
> >>
> >> Hi,
> >>
> >> Try.ing to set a label on a MULTILINESTRING dataset.
> >>
> >> I set a label with Follow capability.
> >>
> >> ANGLE FOLLOW
> >>
> >> But I'm having this error:
> >>
> >>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
> >> BufferBuilder::bufferLineSingleSided only accept linestrings
> >>
> >> Is the Follow compatible with a MultiLinestring dataset or need only
> >> simple linestrings ?
> >>
> >> Thx,
> >>
> >> --
> >> -
> >> Andrea Peri
> >> . . . . . . . . .
> >> qwerty àèìòù
> >> -
> >
> >
> >
> >
> > --
> > -
> > Andrea Peri
> > . . . . . . . . .
> > qwerty àèìòù
> > -
> >
> > ___
> > mapserver-users mailing list
> > mapserver-users@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapserver-users
> >
>



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[Rahkonen Jukka]

Hi,

What if there happens to be empty/null geometries in your source data? I guess 
you can add "AND geometry in not NULL" and perhaps even "AND 
IsValid(geometry)=1" to your DATA line.

-Jukka Rahkonen-


Andrea Peri wrote:

> I'm using spatialite 4.1.1,
> so use ogr to access the db.

  LAYER
NAME "rt_topogr.50k.etichette.topon_idro_50k"
STATUS OFF
EXTENT 1554750.74 4678325.52 1771722.76 4924791.90
TYPE LINE
CONNECTIONTYPE OGR
CONNECTION "/path-to-spatialite/zz_topografica.sqlite"
DATA "select PK_UID_2, TOPO_OK, GEOMETRY from topon_idro_50k"
PROJECTION
  "+init=epsg:3003 +towgs84=0,0,0,0,0,0,0"
END
METADATA
  "wms_title" "topon_idro_50k"
  "wms_extent" "1554750.74 4678325.52 1771722.76 4924791.90"
END
LABELCACHE ON
MAXSCALEDENOM 60100
MINSCALEDENOM 1
CLASS
  NAME ''
  MAXSCALEDENOM 60100
  MINSCALEDENOM 1
  LABEL
TEXT '[TOPO_OK]'
COLOR 0 85 255
OUTLINECOLOR 212 255 255
OUTLINEWIDTH 1
MAXSCALEDENOM 60100
MINSCALEDENOM 40100
FONT "LiberationSans-Regular"
TYPE truetype
SIZE 7
ANGLE FOLLOW
OFFSET 15 99
POSITION auto
PRIORITY 10
MAXOVERLAPANGLE 180.0
BUFFER 1
FORCE OFF
PARTIALS FALSE
MINDISTANCE 200
  END
  LABEL
TEXT '[TOPO_OK]'
COLOR 0 85 255
OUTLINECOLOR 212 255 255
OUTLINEWIDTH 1
MAXSCALEDENOM 40100
MINSCALEDENOM 1
FONT "LiberationSans-Regular"
TYPE truetype
SIZE 9
ANGLE FOLLOW
OFFSET 15 99
POSITION auto
PRIORITY 10
MAXOVERLAPANGLE 180.0
BUFFER 1
FORCE OFF
PARTIALS FALSE
MINDISTANCE 200
  END
END
  END




2013/8/13 thomas bonfort 
mailto:thomas.bonf...@gmail.com>>
there's something strange in your error message... the
singleSidedBuffer stuff is in GEOS, and should have nothing to do in
msOGRFileNextShape. post your whole mapfile layer.

On 13 August 2013 17:42, Andrea Peri 
mailto:aperi2...@gmail.com>> wrote:
> Hi,
>
> I tested trasforming the multilinestring dataset in a linestring dataset but
> the error is still here.
>
> msDrawMap(): Image handling error. Failed to draw layer named
> 'rt_topogr.50k.etichette.topon_idro_50k'.
>
> msOGRFileNextShape(): OGR error. IllegalArgumentException:
> BufferBuilder::bufferLineSingleSided only accept linestrings
>
> So it is not really due to a multilinestring vs linestring question.
>
> The quest carry on.
>
>
>
> 2013/8/13 Andrea Peri mailto:aperi2...@gmail.com>>
>>
>> Hi,
>>
>> Try.ing to set a label on a MULTILINESTRING dataset.
>>
>> I set a label with Follow capability.
>>
>> ANGLE FOLLOW
>>
>> But I'm having this error:
>>
>>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
>> BufferBuilder::bufferLineSingleSided only accept linestrings
>>
>> Is the Follow compatible with a MultiLinestring dataset or need only
>> simple linestrings ?
>>
>> Thx,
>>
>> --
>> -
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -
>
>
>
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
>
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>



--
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[thomas bonfort]

why the double label? they seem to be the same, but in any case
multiple labels are not supported for FOLLOW.

On 13 August 2013 18:08, Andrea Peri  wrote:
> I'm using spatialite 4.1.1,
> so use ogr to access the db.
>
>   LAYER
> NAME "rt_topogr.50k.etichette.topon_idro_50k"
> STATUS OFF
> EXTENT 1554750.74 4678325.52 1771722.76 4924791.90
> TYPE LINE
> CONNECTIONTYPE OGR
> CONNECTION "/path-to-spatialite/zz_topografica.sqlite"
> DATA "select PK_UID_2, TOPO_OK, GEOMETRY from topon_idro_50k"
> PROJECTION
>   "+init=epsg:3003 +towgs84=0,0,0,0,0,0,0"
> END
> METADATA
>   "wms_title" "topon_idro_50k"
>   "wms_extent" "1554750.74 4678325.52 1771722.76 4924791.90"
> END
> LABELCACHE ON
> MAXSCALEDENOM 60100
> MINSCALEDENOM 1
> CLASS
>   NAME ''
>   MAXSCALEDENOM 60100
>   MINSCALEDENOM 1
>   LABEL
> TEXT '[TOPO_OK]'
> COLOR 0 85 255
> OUTLINECOLOR 212 255 255
> OUTLINEWIDTH 1
> MAXSCALEDENOM 60100
> MINSCALEDENOM 40100
> FONT "LiberationSans-Regular"
> TYPE truetype
> SIZE 7
> ANGLE FOLLOW
> OFFSET 15 99
> POSITION auto
> PRIORITY 10
> MAXOVERLAPANGLE 180.0
> BUFFER 1
> FORCE OFF
> PARTIALS FALSE
> MINDISTANCE 200
>   END
>   LABEL
> TEXT '[TOPO_OK]'
> COLOR 0 85 255
> OUTLINECOLOR 212 255 255
> OUTLINEWIDTH 1
> MAXSCALEDENOM 40100
> MINSCALEDENOM 1
> FONT "LiberationSans-Regular"
> TYPE truetype
> SIZE 9
> ANGLE FOLLOW
> OFFSET 15 99
> POSITION auto
> PRIORITY 10
> MAXOVERLAPANGLE 180.0
> BUFFER 1
> FORCE OFF
> PARTIALS FALSE
> MINDISTANCE 200
>   END
> END
>   END
>
>
>
>
> 2013/8/13 thomas bonfort 
>>
>> there's something strange in your error message... the
>> singleSidedBuffer stuff is in GEOS, and should have nothing to do in
>> msOGRFileNextShape. post your whole mapfile layer.
>>
>> On 13 August 2013 17:42, Andrea Peri  wrote:
>> > Hi,
>> >
>> > I tested trasforming the multilinestring dataset in a linestring dataset
>> > but
>> > the error is still here.
>> >
>> > msDrawMap(): Image handling error. Failed to draw layer named
>> > 'rt_topogr.50k.etichette.topon_idro_50k'.
>> >
>> > msOGRFileNextShape(): OGR error. IllegalArgumentException:
>> > BufferBuilder::bufferLineSingleSided only accept linestrings
>> >
>> > So it is not really due to a multilinestring vs linestring question.
>> >
>> > The quest carry on.
>> >
>> >
>> >
>> > 2013/8/13 Andrea Peri 
>> >>
>> >> Hi,
>> >>
>> >> Try.ing to set a label on a MULTILINESTRING dataset.
>> >>
>> >> I set a label with Follow capability.
>> >>
>> >> ANGLE FOLLOW
>> >>
>> >> But I'm having this error:
>> >>
>> >>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
>> >> BufferBuilder::bufferLineSingleSided only accept linestrings
>> >>
>> >> Is the Follow compatible with a MultiLinestring dataset or need only
>> >> simple linestrings ?
>> >>
>> >> Thx,
>> >>
>> >> --
>> >> -
>> >> Andrea Peri
>> >> . . . . . . . . .
>> >> qwerty àèìòù
>> >> -
>> >
>> >
>> >
>> >
>> > --
>> > -
>> > Andrea Peri
>> > . . . . . . . . .
>> > qwerty àèìòù
>> > -
>> >
>> > ___
>> > mapserver-users mailing list
>> > mapserver-users@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/mapserver-users
>> >
>
>
>
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[Andrea Peri]

Hi Jukka,

I check for this critical questions:

unfortunately none of all them is in the dataset.
No invalid geometry, neither null geometry, neither Empty geometry.
:(

Andrea.


2013/8/13 Rahkonen Jukka 

> Hi,
>
> What if there happens to be empty/null geometries in your source data? I
> guess you can add "AND geometry in not NULL" and perhaps even "AND
> IsValid(geometry)=1" to your DATA line.
>
> -Jukka Rahkonen-
>
> 
> Andrea Peri wrote:
>
> > I'm using spatialite 4.1.1,
> > so use ogr to access the db.
>
>   LAYER
> NAME "rt_topogr.50k.etichette.topon_idro_50k"
> STATUS OFF
> EXTENT 1554750.74 4678325.52 1771722.76 4924791.90
> TYPE LINE
> CONNECTIONTYPE OGR
> CONNECTION "/path-to-spatialite/zz_topografica.sqlite"
> DATA "select PK_UID_2, TOPO_OK, GEOMETRY from topon_idro_50k"
> PROJECTION
>   "+init=epsg:3003 +towgs84=0,0,0,0,0,0,0"
> END
> METADATA
>   "wms_title" "topon_idro_50k"
>   "wms_extent" "1554750.74 4678325.52 1771722.76 4924791.90"
> END
> LABELCACHE ON
> MAXSCALEDENOM 60100
> MINSCALEDENOM 1
> CLASS
>   NAME ''
>   MAXSCALEDENOM 60100
>   MINSCALEDENOM 1
>   LABEL
> TEXT '[TOPO_OK]'
> COLOR 0 85 255
> OUTLINECOLOR 212 255 255
> OUTLINEWIDTH 1
> MAXSCALEDENOM 60100
> MINSCALEDENOM 40100
> FONT "LiberationSans-Regular"
> TYPE truetype
> SIZE 7
> ANGLE FOLLOW
> OFFSET 15 99
> POSITION auto
> PRIORITY 10
> MAXOVERLAPANGLE 180.0
> BUFFER 1
> FORCE OFF
> PARTIALS FALSE
> MINDISTANCE 200
>   END
>   LABEL
> TEXT '[TOPO_OK]'
> COLOR 0 85 255
> OUTLINECOLOR 212 255 255
> OUTLINEWIDTH 1
> MAXSCALEDENOM 40100
> MINSCALEDENOM 1
> FONT "LiberationSans-Regular"
> TYPE truetype
> SIZE 9
> ANGLE FOLLOW
> OFFSET 15 99
> POSITION auto
> PRIORITY 10
> MAXOVERLAPANGLE 180.0
> BUFFER 1
> FORCE OFF
> PARTIALS FALSE
> MINDISTANCE 200
>   END
> END
>   END
>
>
>
>
> 2013/8/13 thomas bonfort  thomas.bonf...@gmail.com>>
> there's something strange in your error message... the
> singleSidedBuffer stuff is in GEOS, and should have nothing to do in
> msOGRFileNextShape. post your whole mapfile layer.
>
> On 13 August 2013 17:42, Andrea Peri  aperi2...@gmail.com>> wrote:
> > Hi,
> >
> > I tested trasforming the multilinestring dataset in a linestring dataset
> but
> > the error is still here.
> >
> > msDrawMap(): Image handling error. Failed to draw layer named
> > 'rt_topogr.50k.etichette.topon_idro_50k'.
> >
> > msOGRFileNextShape(): OGR error. IllegalArgumentException:
> > BufferBuilder::bufferLineSingleSided only accept linestrings
> >
> > So it is not really due to a multilinestring vs linestring question.
> >
> > The quest carry on.
> >
> >
> >
> > 2013/8/13 Andrea Peri mailto:aperi2...@gmail.com>>
> >>
> >> Hi,
> >>
> >> Try.ing to set a label on a MULTILINESTRING dataset.
> >>
> >> I set a label with Follow capability.
> >>
> >> ANGLE FOLLOW
> >>
> >> But I'm having this error:
> >>
> >>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
> >> BufferBuilder::bufferLineSingleSided only accept linestrings
> >>
> >> Is the Follow compatible with a MultiLinestring dataset or need only
> >> simple linestrings ?
> >>
> >> Thx,
> >>
> >> --
> >> -
> >> Andrea Peri
> >> . . . . . . . . .
> >> qwerty àèìòù
> >> -
> >
> >
> >
> >
> > --
> > -
> > Andrea Peri
> > . . . . . . . . .
> > qwerty àèìòù
> > -
> >
> > ___
> > mapserver-users mailing list
> > mapserver-users@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapserver-users
> >
>
>
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[Andrea Peri]

The two label are at different max/min scaledenominator.
The goal is to have little label size at low scales and bigger font size at
bigger scales.

However only one lable is active at one scale level.

Is this incompatible with "follow" ?



2013/8/13 thomas bonfort 

> why the double label? they seem to be the same, but in any case
> multiple labels are not supported for FOLLOW.
>
> On 13 August 2013 18:08, Andrea Peri  wrote:
> > I'm using spatialite 4.1.1,
> > so use ogr to access the db.
> >
> >   LAYER
> > NAME "rt_topogr.50k.etichette.topon_idro_50k"
> > STATUS OFF
> > EXTENT 1554750.74 4678325.52 1771722.76 4924791.90
> > TYPE LINE
> > CONNECTIONTYPE OGR
> > CONNECTION "/path-to-spatialite/zz_topografica.sqlite"
> > DATA "select PK_UID_2, TOPO_OK, GEOMETRY from topon_idro_50k"
> > PROJECTION
> >   "+init=epsg:3003 +towgs84=0,0,0,0,0,0,0"
> > END
> > METADATA
> >   "wms_title" "topon_idro_50k"
> >   "wms_extent" "1554750.74 4678325.52 1771722.76 4924791.90"
> > END
> > LABELCACHE ON
> > MAXSCALEDENOM 60100
> > MINSCALEDENOM 1
> > CLASS
> >   NAME ''
> >   MAXSCALEDENOM 60100
> >   MINSCALEDENOM 1
> >   LABEL
> > TEXT '[TOPO_OK]'
> > COLOR 0 85 255
> > OUTLINECOLOR 212 255 255
> > OUTLINEWIDTH 1
> > MAXSCALEDENOM 60100
> > MINSCALEDENOM 40100
> > FONT "LiberationSans-Regular"
> > TYPE truetype
> > SIZE 7
> > ANGLE FOLLOW
> > OFFSET 15 99
> > POSITION auto
> > PRIORITY 10
> > MAXOVERLAPANGLE 180.0
> > BUFFER 1
> > FORCE OFF
> > PARTIALS FALSE
> > MINDISTANCE 200
> >   END
> >   LABEL
> > TEXT '[TOPO_OK]'
> > COLOR 0 85 255
> > OUTLINECOLOR 212 255 255
> > OUTLINEWIDTH 1
> > MAXSCALEDENOM 40100
> > MINSCALEDENOM 1
> > FONT "LiberationSans-Regular"
> > TYPE truetype
> > SIZE 9
> > ANGLE FOLLOW
> > OFFSET 15 99
> > POSITION auto
> > PRIORITY 10
> > MAXOVERLAPANGLE 180.0
> > BUFFER 1
> > FORCE OFF
> > PARTIALS FALSE
> > MINDISTANCE 200
> >   END
> > END
> >   END
> >
> >
> >
> >
> > 2013/8/13 thomas bonfort 
> >>
> >> there's something strange in your error message... the
> >> singleSidedBuffer stuff is in GEOS, and should have nothing to do in
> >> msOGRFileNextShape. post your whole mapfile layer.
> >>
> >> On 13 August 2013 17:42, Andrea Peri  wrote:
> >> > Hi,
> >> >
> >> > I tested trasforming the multilinestring dataset in a linestring
> dataset
> >> > but
> >> > the error is still here.
> >> >
> >> > msDrawMap(): Image handling error. Failed to draw layer named
> >> > 'rt_topogr.50k.etichette.topon_idro_50k'.
> >> >
> >> > msOGRFileNextShape(): OGR error. IllegalArgumentException:
> >> > BufferBuilder::bufferLineSingleSided only accept linestrings
> >> >
> >> > So it is not really due to a multilinestring vs linestring question.
> >> >
> >> > The quest carry on.
> >> >
> >> >
> >> >
> >> > 2013/8/13 Andrea Peri 
> >> >>
> >> >> Hi,
> >> >>
> >> >> Try.ing to set a label on a MULTILINESTRING dataset.
> >> >>
> >> >> I set a label with Follow capability.
> >> >>
> >> >> ANGLE FOLLOW
> >> >>
> >> >> But I'm having this error:
> >> >>
> >> >>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
> >> >> BufferBuilder::bufferLineSingleSided only accept linestrings
> >> >>
> >> >> Is the Follow compatible with a MultiLinestring dataset or need only
> >> >> simple linestrings ?
> >> >>
> >> >> Thx,
> >> >>
> >> >> --
> >> >> -
> >> >> Andrea Peri
> >> >> . . . . . . . . .
> >> >> qwerty àèìòù
> >> >> -
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > -
> >> > Andrea Peri
> >> > . . . . . . . . .
> >> > qwerty àèìòù
> >> > -
> >> >
> >> > ___
> >> > mapserver-users mailing list
> >> > mapserver-users@lists.osgeo.org
> >> > http://lists.osgeo.org/mailman/listinfo/mapserver-users
> >> >
> >
> >
> >
> >
> > --
> > -
> > Andrea Peri
> > . . . . . . . . .
> > qwerty àèìòù
> > -
>



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[thomas bonfort]

yes, that's incompatible. use multiple scale-dependant classes for now

On 13 August 2013 18:26, Andrea Peri  wrote:
> The two label are at different max/min scaledenominator.
> The goal is to have little label size at low scales and bigger font size at
> bigger scales.
>
> However only one lable is active at one scale level.
>
> Is this incompatible with "follow" ?
>
>
>
> 2013/8/13 thomas bonfort 
>>
>> why the double label? they seem to be the same, but in any case
>> multiple labels are not supported for FOLLOW.
>>
>> On 13 August 2013 18:08, Andrea Peri  wrote:
>> > I'm using spatialite 4.1.1,
>> > so use ogr to access the db.
>> >
>> >   LAYER
>> > NAME "rt_topogr.50k.etichette.topon_idro_50k"
>> > STATUS OFF
>> > EXTENT 1554750.74 4678325.52 1771722.76 4924791.90
>> > TYPE LINE
>> > CONNECTIONTYPE OGR
>> > CONNECTION "/path-to-spatialite/zz_topografica.sqlite"
>> > DATA "select PK_UID_2, TOPO_OK, GEOMETRY from topon_idro_50k"
>> > PROJECTION
>> >   "+init=epsg:3003 +towgs84=0,0,0,0,0,0,0"
>> > END
>> > METADATA
>> >   "wms_title" "topon_idro_50k"
>> >   "wms_extent" "1554750.74 4678325.52 1771722.76 4924791.90"
>> > END
>> > LABELCACHE ON
>> > MAXSCALEDENOM 60100
>> > MINSCALEDENOM 1
>> > CLASS
>> >   NAME ''
>> >   MAXSCALEDENOM 60100
>> >   MINSCALEDENOM 1
>> >   LABEL
>> > TEXT '[TOPO_OK]'
>> > COLOR 0 85 255
>> > OUTLINECOLOR 212 255 255
>> > OUTLINEWIDTH 1
>> > MAXSCALEDENOM 60100
>> > MINSCALEDENOM 40100
>> > FONT "LiberationSans-Regular"
>> > TYPE truetype
>> > SIZE 7
>> > ANGLE FOLLOW
>> > OFFSET 15 99
>> > POSITION auto
>> > PRIORITY 10
>> > MAXOVERLAPANGLE 180.0
>> > BUFFER 1
>> > FORCE OFF
>> > PARTIALS FALSE
>> > MINDISTANCE 200
>> >   END
>> >   LABEL
>> > TEXT '[TOPO_OK]'
>> > COLOR 0 85 255
>> > OUTLINECOLOR 212 255 255
>> > OUTLINEWIDTH 1
>> > MAXSCALEDENOM 40100
>> > MINSCALEDENOM 1
>> > FONT "LiberationSans-Regular"
>> > TYPE truetype
>> > SIZE 9
>> > ANGLE FOLLOW
>> > OFFSET 15 99
>> > POSITION auto
>> > PRIORITY 10
>> > MAXOVERLAPANGLE 180.0
>> > BUFFER 1
>> > FORCE OFF
>> > PARTIALS FALSE
>> > MINDISTANCE 200
>> >   END
>> > END
>> >   END
>> >
>> >
>> >
>> >
>> > 2013/8/13 thomas bonfort 
>> >>
>> >> there's something strange in your error message... the
>> >> singleSidedBuffer stuff is in GEOS, and should have nothing to do in
>> >> msOGRFileNextShape. post your whole mapfile layer.
>> >>
>> >> On 13 August 2013 17:42, Andrea Peri  wrote:
>> >> > Hi,
>> >> >
>> >> > I tested trasforming the multilinestring dataset in a linestring
>> >> > dataset
>> >> > but
>> >> > the error is still here.
>> >> >
>> >> > msDrawMap(): Image handling error. Failed to draw layer named
>> >> > 'rt_topogr.50k.etichette.topon_idro_50k'.
>> >> >
>> >> > msOGRFileNextShape(): OGR error. IllegalArgumentException:
>> >> > BufferBuilder::bufferLineSingleSided only accept linestrings
>> >> >
>> >> > So it is not really due to a multilinestring vs linestring question.
>> >> >
>> >> > The quest carry on.
>> >> >
>> >> >
>> >> >
>> >> > 2013/8/13 Andrea Peri 
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> Try.ing to set a label on a MULTILINESTRING dataset.
>> >> >>
>> >> >> I set a label with Follow capability.
>> >> >>
>> >> >> ANGLE FOLLOW
>> >> >>
>> >> >> But I'm having this error:
>> >> >>
>> >> >>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
>> >> >> BufferBuilder::bufferLineSingleSided only accept linestrings
>> >> >>
>> >> >> Is the Follow compatible with a MultiLinestring dataset or need only
>> >> >> simple linestrings ?
>> >> >>
>> >> >> Thx,
>> >> >>
>> >> >> --
>> >> >> -
>> >> >> Andrea Peri
>> >> >> . . . . . . . . .
>> >> >> qwerty àèìòù
>> >> >> -
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > -
>> >> > Andrea Peri
>> >> > . . . . . . . . .
>> >> > qwerty àèìòù
>> >> > -
>> >> >
>> >> > ___
>> >> > mapserver-users mailing list
>> >> > mapserver-users@lists.osgeo.org
>> >> > http://lists.osgeo.org/mailman/listinfo/mapserver-users
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > -
>> > Andrea Peri
>> > . . . . . . . . .
>> > qwerty àèìòù
>> > -
>
>
>
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[Andrea Peri]

ok, thx.
I change to multiple scale.

However I do a rapid check removing a label component, but the problem is
still here.

Now I rewrite a more exact mapfile using two classes.

Andrea.




2013/8/13 thomas bonfort 

> yes, that's incompatible. use multiple scale-dependant classes for now
>
> On 13 August 2013 18:26, Andrea Peri  wrote:
> > The two label are at different max/min scaledenominator.
> > The goal is to have little label size at low scales and bigger font size
> at
> > bigger scales.
> >
> > However only one lable is active at one scale level.
> >
> > Is this incompatible with "follow" ?
> >
> >
> >
> > 2013/8/13 thomas bonfort 
> >>
> >> why the double label? they seem to be the same, but in any case
> >> multiple labels are not supported for FOLLOW.
> >>
> >> On 13 August 2013 18:08, Andrea Peri  wrote:
> >> > I'm using spatialite 4.1.1,
> >> > so use ogr to access the db.
> >> >
> >> >   LAYER
> >> > NAME "rt_topogr.50k.etichette.topon_idro_50k"
> >> > STATUS OFF
> >> > EXTENT 1554750.74 4678325.52 1771722.76 4924791.90
> >> > TYPE LINE
> >> > CONNECTIONTYPE OGR
> >> > CONNECTION "/path-to-spatialite/zz_topografica.sqlite"
> >> > DATA "select PK_UID_2, TOPO_OK, GEOMETRY from topon_idro_50k"
> >> > PROJECTION
> >> >   "+init=epsg:3003 +towgs84=0,0,0,0,0,0,0"
> >> > END
> >> > METADATA
> >> >   "wms_title" "topon_idro_50k"
> >> >   "wms_extent" "1554750.74 4678325.52 1771722.76 4924791.90"
> >> > END
> >> > LABELCACHE ON
> >> > MAXSCALEDENOM 60100
> >> > MINSCALEDENOM 1
> >> > CLASS
> >> >   NAME ''
> >> >   MAXSCALEDENOM 60100
> >> >   MINSCALEDENOM 1
> >> >   LABEL
> >> > TEXT '[TOPO_OK]'
> >> > COLOR 0 85 255
> >> > OUTLINECOLOR 212 255 255
> >> > OUTLINEWIDTH 1
> >> > MAXSCALEDENOM 60100
> >> > MINSCALEDENOM 40100
> >> > FONT "LiberationSans-Regular"
> >> > TYPE truetype
> >> > SIZE 7
> >> > ANGLE FOLLOW
> >> > OFFSET 15 99
> >> > POSITION auto
> >> > PRIORITY 10
> >> > MAXOVERLAPANGLE 180.0
> >> > BUFFER 1
> >> > FORCE OFF
> >> > PARTIALS FALSE
> >> > MINDISTANCE 200
> >> >   END
> >> >   LABEL
> >> > TEXT '[TOPO_OK]'
> >> > COLOR 0 85 255
> >> > OUTLINECOLOR 212 255 255
> >> > OUTLINEWIDTH 1
> >> > MAXSCALEDENOM 40100
> >> > MINSCALEDENOM 1
> >> > FONT "LiberationSans-Regular"
> >> > TYPE truetype
> >> > SIZE 9
> >> > ANGLE FOLLOW
> >> > OFFSET 15 99
> >> > POSITION auto
> >> > PRIORITY 10
> >> > MAXOVERLAPANGLE 180.0
> >> > BUFFER 1
> >> > FORCE OFF
> >> > PARTIALS FALSE
> >> > MINDISTANCE 200
> >> >   END
> >> > END
> >> >   END
> >> >
> >> >
> >> >
> >> >
> >> > 2013/8/13 thomas bonfort 
> >> >>
> >> >> there's something strange in your error message... the
> >> >> singleSidedBuffer stuff is in GEOS, and should have nothing to do in
> >> >> msOGRFileNextShape. post your whole mapfile layer.
> >> >>
> >> >> On 13 August 2013 17:42, Andrea Peri  wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I tested trasforming the multilinestring dataset in a linestring
> >> >> > dataset
> >> >> > but
> >> >> > the error is still here.
> >> >> >
> >> >> > msDrawMap(): Image handling error. Failed to draw layer named
> >> >> > 'rt_topogr.50k.etichette.topon_idro_50k'.
> >> >> >
> >> >> > msOGRFileNextShape(): OGR error. IllegalArgumentException:
> >> >> > BufferBuilder::bufferLineSingleSided only accept linestrings
> >> >> >
> >> >> > So it is not really due to a multilinestring vs linestring
> question.
> >> >> >
> >> >> > The quest carry on.
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2013/8/13 Andrea Peri 
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> Try.ing to set a label on a MULTILINESTRING dataset.
> >> >> >>
> >> >> >> I set a label with Follow capability.
> >> >> >>
> >> >> >> ANGLE FOLLOW
> >> >> >>
> >> >> >> But I'm having this error:
> >> >> >>
> >> >> >>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
> >> >> >> BufferBuilder::bufferLineSingleSided only accept linestrings
> >> >> >>
> >> >> >> Is the Follow compatible with a MultiLinestring dataset or need
> only
> >> >> >> simple linestrings ?
> >> >> >>
> >> >> >> Thx,
> >> >> >>
> >> >> >> --
> >> >> >> -
> >> >> >> Andrea Peri
> >> >> >> . . . . . . . . .
> >> >> >> qwerty àèìòù
> >> >> >> -
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > -
> >> >> > Andrea Peri
> >> >> > . . . . . . . . .
> >> >> > qwerty àèìòù
> >> >> > -
> >> >> >
> >> >> > ___
> >> >> > mapserver-users mailing list
> >> >> > mapserver-users@lists.osgeo.org
> >> >> > http://lists.osgeo.org/mailman/listinfo/mapserver-users
> >> >> >
> >> >
> >> >

Re: [mapserver-users] draw map at a precise scale

[Lime, Steve D (MNIT)]

Via the CGI you can use a combination of mapxy, mode=map, and scale parameters.

Steve

From: mapserver-users-boun...@lists.osgeo.org 
[mailto:mapserver-users-boun...@lists.osgeo.org] On Behalf Of Michael McInnis
Sent: Monday, August 12, 2013 1:02 PM
To: mapserver-users@lists.osgeo.org
Subject: [mapserver-users] draw map at a precise scale

I've been searching for a way to draw my map at a specific map location and a 
specific scale.

IE -90, 38 (Decimal Degree) at 1:100,000 scale

I've seen the zoomscale() and zoompoint() functions but they appear to be pixel 
coordinate driven and require extents which you wouldn't know, that's the point.

I can write the math to do the extent calculation manually but figure this is 
such a basic functionality it must
already exist in mapserver?

Anyone done this before?

Thanks
Michael McInnis
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Angle Follow will accept only simple linestring don't MultiLinestring ?

[Andrea Peri]

Hi,
Perhaps I found the explanation.

The "angle follow" with OGR is using the
BufferBuilder::bufferLineSingleSided
That function seem don't work with a MultiLinestring . It necessary need a
simple linestring.

The question is that sometime the simple linestirng when is clipped from
the visible bbox of the map to render, is transformed in a MultiLinestring.
As showed in attached image.

So a linestring geometry clipped by the visible bbox will become a
multilinestring geometry and the bufferLineSingleSided will give error to
put a "follow angle".

Andrea.

2013/8/13 Andrea Peri 

> ok, thx.
> I change to multiple scale.
>
> However I do a rapid check removing a label component, but the problem is
> still here.
>
> Now I rewrite a more exact mapfile using two classes.
>
> Andrea.
>
>
>
>
> 2013/8/13 thomas bonfort 
>
>> yes, that's incompatible. use multiple scale-dependant classes for now
>>
>> On 13 August 2013 18:26, Andrea Peri  wrote:
>> > The two label are at different max/min scaledenominator.
>> > The goal is to have little label size at low scales and bigger font
>> size at
>> > bigger scales.
>> >
>> > However only one lable is active at one scale level.
>> >
>> > Is this incompatible with "follow" ?
>> >
>> >
>> >
>> > 2013/8/13 thomas bonfort 
>> >>
>> >> why the double label? they seem to be the same, but in any case
>> >> multiple labels are not supported for FOLLOW.
>> >>
>> >> On 13 August 2013 18:08, Andrea Peri  wrote:
>> >> > I'm using spatialite 4.1.1,
>> >> > so use ogr to access the db.
>> >> >
>> >> >   LAYER
>> >> > NAME "rt_topogr.50k.etichette.topon_idro_50k"
>> >> > STATUS OFF
>> >> > EXTENT 1554750.74 4678325.52 1771722.76 4924791.90
>> >> > TYPE LINE
>> >> > CONNECTIONTYPE OGR
>> >> > CONNECTION "/path-to-spatialite/zz_topografica.sqlite"
>> >> > DATA "select PK_UID_2, TOPO_OK, GEOMETRY from topon_idro_50k"
>> >> > PROJECTION
>> >> >   "+init=epsg:3003 +towgs84=0,0,0,0,0,0,0"
>> >> > END
>> >> > METADATA
>> >> >   "wms_title" "topon_idro_50k"
>> >> >   "wms_extent" "1554750.74 4678325.52 1771722.76 4924791.90"
>> >> > END
>> >> > LABELCACHE ON
>> >> > MAXSCALEDENOM 60100
>> >> > MINSCALEDENOM 1
>> >> > CLASS
>> >> >   NAME ''
>> >> >   MAXSCALEDENOM 60100
>> >> >   MINSCALEDENOM 1
>> >> >   LABEL
>> >> > TEXT '[TOPO_OK]'
>> >> > COLOR 0 85 255
>> >> > OUTLINECOLOR 212 255 255
>> >> > OUTLINEWIDTH 1
>> >> > MAXSCALEDENOM 60100
>> >> > MINSCALEDENOM 40100
>> >> > FONT "LiberationSans-Regular"
>> >> > TYPE truetype
>> >> > SIZE 7
>> >> > ANGLE FOLLOW
>> >> > OFFSET 15 99
>> >> > POSITION auto
>> >> > PRIORITY 10
>> >> > MAXOVERLAPANGLE 180.0
>> >> > BUFFER 1
>> >> > FORCE OFF
>> >> > PARTIALS FALSE
>> >> > MINDISTANCE 200
>> >> >   END
>> >> >   LABEL
>> >> > TEXT '[TOPO_OK]'
>> >> > COLOR 0 85 255
>> >> > OUTLINECOLOR 212 255 255
>> >> > OUTLINEWIDTH 1
>> >> > MAXSCALEDENOM 40100
>> >> > MINSCALEDENOM 1
>> >> > FONT "LiberationSans-Regular"
>> >> > TYPE truetype
>> >> > SIZE 9
>> >> > ANGLE FOLLOW
>> >> > OFFSET 15 99
>> >> > POSITION auto
>> >> > PRIORITY 10
>> >> > MAXOVERLAPANGLE 180.0
>> >> > BUFFER 1
>> >> > FORCE OFF
>> >> > PARTIALS FALSE
>> >> > MINDISTANCE 200
>> >> >   END
>> >> > END
>> >> >   END
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > 2013/8/13 thomas bonfort 
>> >> >>
>> >> >> there's something strange in your error message... the
>> >> >> singleSidedBuffer stuff is in GEOS, and should have nothing to do in
>> >> >> msOGRFileNextShape. post your whole mapfile layer.
>> >> >>
>> >> >> On 13 August 2013 17:42, Andrea Peri  wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I tested trasforming the multilinestring dataset in a linestring
>> >> >> > dataset
>> >> >> > but
>> >> >> > the error is still here.
>> >> >> >
>> >> >> > msDrawMap(): Image handling error. Failed to draw layer named
>> >> >> > 'rt_topogr.50k.etichette.topon_idro_50k'.
>> >> >> >
>> >> >> > msOGRFileNextShape(): OGR error. IllegalArgumentException:
>> >> >> > BufferBuilder::bufferLineSingleSided only accept linestrings
>> >> >> >
>> >> >> > So it is not really due to a multilinestring vs linestring
>> question.
>> >> >> >
>> >> >> > The quest carry on.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > 2013/8/13 Andrea Peri 
>> >> >> >>
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> Try.ing to set a label on a MULTILINESTRING dataset.
>> >> >> >>
>> >> >> >> I set a label with Follow capability.
>> >> >> >>
>> >> >> >> ANGLE FOLLOW
>> >> >> >>
>> >> >> >> But I'm having this error:
>> >> >> >>
>> >> >> >>  msOGRFileNextShape(): OGR error. IllegalArgumentException:
>> >> >> >> BufferBuilder::bufferLineSingleSided only accept li