4.10.0: Some vectors not rendering for a layer
Ed McNierney
ed at TOPOZONE.COM
Sat Oct 21 09:18:22 EDT 2006
Steve -
Thanks! Yes, I did remember that after I finished my coffee yesterday morning <g>; my brain was installed sideways at the time. I actually do the same thing - thanks for taking the time to write it up and post to the list.
- Ed
Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA 01863
Phone: +1 (978) 251-4242
Fax: +1 (978) 251-1396
ed at topozone.com
-----Original Message-----
From: Stephen Woodbridge [mailto:woodbri at swoodbridge.com]
Sent: Friday, October 20, 2006 11:32 PM
To: Ed McNierney
Cc: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] 4.10.0: Some vectors not rendering for a layer
Hi Ed,
Yes, using both DATA and TILEINDEX is an important feature. All my mapfiles use tileindexes that point to a county directories and the DATA statement selects the file from within the directory. This is also why there is the capability to tile4ms to create only directories.
The rational for this is the if you have regions like counties most of the data layers in them will have the same coverage area. I my case with Tiger data I have about 10 layers per county. I could create 10 tileindexes that all have the same spatial coverage, but having only one facilitates filesystem caching and performance and decrease the number of tileindexes that mapserver needs to open and manage.
-Steve
Ed McNierney wrote:
> Andre -
>
> You are talking about the d1 and d2 shapefiles, but you're using both
> DATA and TILEINDEX statements, which seems odd - is each layer
> supposed to be drawing a single shapefile (DATA "d1") or a group of
> shapefiles (TILEINDEX "TIGER04/county_index")? It's still early in
> the morning, but I can't think why it's even allowed to use both in a
> single LAYER - you should need one or the other.
>
> So as you add "new" vectors, are you editing a single shapefile to add
> new vectors to it, or are you adding new shapefiles to a TILEINDEX
> group? If it's the latter, and the new shapefiles don't have the same
> attribute columns as the older ones, that could cause the problem
> you're seeing.
>
> I don't understand what "I cleared all the tiles" means.
>
> Could you clear this up and be very specific about the arrangement of
> the shapefile(s) and tileindex files you're using? Thanks.
>
> - Ed
>
> Ed McNierney President and Chief Mapmaker TopoZone.com / Maps a la
> carte, Inc. 73 Princeton Street, Suite 305 North Chelmsford, MA
> 01863 Phone: +1 (978) 251-4242 Fax: +1 (978) 251-1396 ed at topozone.com
>
>
> -----Original Message----- From: UMN MapServer Users List
> [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On Behalf Of Andre Lockhart
> Sent: Friday, October 20, 2006 2:43 AM To:
> MAPSERVER-USERS at LISTS.UMN.EDU Subject: Re: [UMN_MAPSERVER-USERS]
> 4.10.0: Some vectors not rendering for a layer
>
> We're still having the problem, so I did some experiments today.
>
> There are 2 shapefiles, d1 & d2. Both have the same coordinates, which
> follow the contours of the same roadways. We stop them overlapping by
> defining offsets.
>
> Below is the bit of the mapfile used to render them.
>
> The problem is that only the right offset is displaying for
> North/South roadways, and only the bottom for East/West roadways.
> We're only seeing this with recently drawn vectors/segments. Older
> ones render just fine.
>
> I deleted the d2 layer.
>
> Then I redisplayed the map using the d1 shapefiles (DATA "d1" OFFSET
> -2 -99). The d1 layer offset to the right for the problem segments.
>
> When I used the d2 shapefiles to render the d1 layer (DATA "d2"
> OFFSET -2 -99), the offset was to the left for the problem segments.
> I don't see how this can be possible...how can using a different
> shapefile somehow override the OFFSET directive for the class?
>
> I cleared all the tiles so that cannot be the problem.
>
> This is really puzzling...any ideas?
>
>
> LAYER NAME "direction1-13" STATUS DEFAULT DATA "d1" TILEINDEX
> "TIGER04/county_index" TYPE LINE SIZEUNITS PIXELS #
> ================================================== # Class:
> direction 1, Scale 7 #
> ================================================== CLASS MINSCALE
> 100000 MAXSCALE 300000 STYLE SYMBOL "cartoline" SIZE 3 COLOR 206 0 0
> OFFSET -2 -99 ANTIALIAS true END END END
>
> LAYER NAME "direction2-14" STATUS DEFAULT DATA "d2" TILEINDEX
> "TIGER04/county_index" TYPE LINE SIZEUNITS PIXELS #
> ================================================== # Class:
> direction 2, Scale 7 #
> ================================================== CLASS MINSCALE
> 100000 MAXSCALE 300000 STYLE SYMBOL "cartoline" SIZE 3 COLOR 206 0 0
> OFFSET 2 -99 ANTIALIAS true END END END
>
>
> André Lockhart andre at CoValuate.com 510.333.7189
>
> -----Original Message----- From: UMN MapServer Users List
> [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On Behalf Of Eijnden, Bart van
> den (AGI) Sent: Thursday, October 19, 2006 1:16 AM To:
> MAPSERVER-USERS at LISTS.UMN.EDU Subject: Re: 4.10.0: Some vectors not
> rendering for a layer
>
> The benefit comes with displaying a smaller extent than the full =
> shapefile, and can be quite large. It's a spatial index (quadtree).
>
> You can generate them using shptree, a utility that comes with
> Mapserver = (MS4W).
>
> Best regards, Bart
>
> -----Oorspronkelijk bericht----- Van: UMN MapServer Users List
> [mailto:MAPSERVER-USERS at LISTS.UMN.EDU]Namens Andre Lockhart
> Verzonden: donderdag 19 oktober 2006 10:14 Aan:
> MAPSERVER-USERS at LISTS.UMN.EDU Onderwerp: Re: [UMN_MAPSERVER-USERS]
> 4.10.0: Some vectors not rendering for a layer
>
>
> No, we aren't using qix files for these layers.
>
> Also, we are rendering directly from the shapefiles, not via PostGIS
> or = some other RDBMS.=20
>
> Is there any benefit to qix files? If so, how might one (re)generate =
> them using open source tools?
>
> Thanks.
>
> =20 =20
>
> Andr=E9 Lockhart andre at CoValuate.com 510.333.7189 =20
>
> -----Original Message----- From: Eijnden, Bart van den (AGI) =
> [mailto:b.vdeijnden at agi.rws.minvenw.nl]=20 Sent: Thursday, October 19,
> 2006 12:45 AM To: Andre Lockhart; MAPSERVER-USERS at LISTS.UMN.EDU
> Subject: RE: [UMN_MAPSERVER-USERS] 4.10.0: Some vectors not rendering
> = for a layer
>
> Are you using a spatial index (qix file)?
>
> If so, did you regenerate the spatial index after the changes?
>
> Best regards, Bart
>
> -----Oorspronkelijk bericht----- Van: UMN MapServer Users List
> [mailto:MAPSERVER-USERS at LISTS.UMN.EDU]Namens Andre Lockhart
> Verzonden: donderdag 19 oktober 2006 9:41 Aan:
> MAPSERVER-USERS at LISTS.UMN.EDU Onderwerp: Re: [UMN_MAPSERVER-USERS]
> 4.10.0: Some vectors not rendering for a layer
>
>
> Thanks, Andreas.
>
> We've been on 4.10.0 for a few weeks and already have quotes around
> our expression variables. This problem only appeared after we drew new
> = vectors for existing shapefiles.
>
> =20 =20
>
> Andr=E9 Lockhart andre at CoValuate.com 510.333.7189 =20
>
> -----Original Message----- From: Andreas Albarello
> [mailto:andreas.albarello at territoriumonline.com] =
>
> Sent: Thursday, October 19, 2006 12:30 AM To: Andre Lockhart Cc:
> MAPSERVER-USERS at LISTS.UMN.EDU Subject: Re: [UMN_MAPSERVER-USERS]
> 4.10.0: Some vectors not rendering = for a layer
>
> Andre Lockhart wrote:
>> We have a layer with a few hundred vectors/segments that renders
>> in=20 different colors based on a class expression. Some of the
>> vectors=20 render, others do not. =20 We are well under the limit for
>> classes and layers. =20 One clue is that it is the most recently
>> drawn vectors that do not =
> render.
>> =20 We've tried rebooting/reinitializing everything, to no avail.
>
> Andre,
>
> I assume everything was working fine with Mapserver prior to
> version=20 4.10. If that is the case, I suspect you might have run
> into a problem=20 that I encountered myself with the new release and
> which I think is=20 related to some changes made in the mapfile lexer.
>
> In particular, I noticed that, when using class expressions of the
> form
>
> EXPRESSION abcd
>
> (that is a simple string based expression) Mapserver now requires you
> to =
>
> put quotes around those expressions (i.e. EXPRESSION "abcd") or it=20
> *might* fail to recognize them as such. This applies to a layer's
> FILTER =
>
> as well, but, as with EXPRESSION, only when using string expressions,
> no =
>
> regular or nested logical expressions (which are still delimited by=20
> slashes and brackets, respectively).
>
> Hope this helps.
>
> Best regards, Andreas
>
>
> Disclaimer
> **********************************************************************
> ** Aan dit bericht kunnen geen rechten worden ontleend. Dit bericht
> is uitsluitend bestemd voor de geadresseerde. Als u dit bericht per
> abuis hebt ontvangen, wordt u verzocht het te vernietigen en de
> afzender te=20 informeren. Wij adviseren u om bij twijfel over de
> juistheid of de=20 volledigheid van de mail contact met afzender op te
> nemen.
>
> This message shall not constitute any rights or obligations. This
> message is intended solely for the addressee. If you have received
> this message in error, please delete it and notify the sender
> immediately. When in doubt whether this message is correct or
> complete, please contact the sender.
> **********************************************************************
> **
>
>
>
> Disclaimer
> **********************************************************************
> ** Aan dit bericht kunnen geen rechten worden ontleend. Dit bericht
> is uitsluitend bestemd voor de geadresseerde. Als u dit bericht per
> abuis hebt ontvangen, wordt u verzocht het te vernietigen en de
> afzender te informeren. Wij adviseren u om bij twijfel over de
> juistheid of de volledigheid van de mail contact met afzender op te
> nemen.
>
> This message shall not constitute any rights or obligations. This
> message is intended solely for the addressee. If you have received
> this message in error, please delete it and notify the sender
> immediately. When in doubt whether this message is correct or
> complete, please contact the sender.
> **********************************************************************
> **
More information about the mapserver-users
mailing list