[Mapserver-users] Autonumbering of labels?

[Doug]

The simple form of what you describe is exactly what we want to do.  In 
this specific case, we don't even need to sort by distance from the 
center, zooming text links, etc.  But I can see those being good, 
general capabilities for similar applications.

And I'd really have no problem with "MapScript" being the answer if 
there were a thread-safe way for us to use it (particularly from Java, 
even if JNI were required).

I'm assuming that this must be a very difficult thing to change.  Given 
the large number of Java environments, and the likelihood that many of 
them look for OpenSource tools, I would have guessed that the problem 
would have already been solved if it were remotely simple.

Doug

Stephen Woodbridge wrote:

> Steve and Doug,
> 
> This sounds like the functionality that you would want for a standard 
> Locator type of application. For a locator you would want to position to 
> some location and specify a radius, then render a map with the locations 
> found there from a database or a LAYER, numbered on the map and have a 
> table under the map the describes each of the labeled the locations.
> 
> Doug is this what you are try to do?
> 
> For a locator, you would also probably want the locations sorted by 
> increasing distance from the center point. You might also want to have 
> links defined in each of the table description that would allow you to 
> zoom in close to that specific location. The table could be describe by 
> a template that is populated based on attribute fields and a [DISTANCE] 
> from the center point. The template fragment could be generated at the 
> same time the point is assigned its number.
> 
> This is really a mapscript application, because you should deal with 
> error recovery like what if there are no location where you specified? 
> you should display a nice page, not an map with no locations on it. You 
> might also want to dynamically expand the search radius and try again 
> before failing, etc.
> 
> While it is very possible to add something like this to mapserver, I 
> think our strategy has been to NOT make bloat-ware by adding lots of 
> application into mapserver. I think we want mapserver to be small and 
> fast and keep the application code in mapscript. But that is really the 
> developers' call.
> 
> -Steve
> 
> Steve Lime wrote:
> 
>> Labeling isn't random so you might be able to figure something out. This
>> type of an operation usually involves a query to get at attributes of
>> features you want. So, in MapScript you'd do something like:
>>
>> - draw a base image for the required extent
>> - query the points data using that extent
>> - loop through the results drawing each point on the base image, using a
>> counter to compute the label values
>> - produce the output page with the image and the list of point features
>>
>> So you could have the map with gas station's labeled 1to 10, and then a
>> list with the names of each station. That's an easy solution...
>>
>> Steve
>>
>>
>>>>> Doug <ummmmm at MYREALBOX.COM> 06/08/04 12:22 AM >>>
>>
>>
>> That is exactly what we want to do.
>>
>> We have an existing site that uses a commercial product with an 
>> expensive annual license fee that our project management team would like
>>
>> to see us replace with OpenSource alternatives.  This site does show a 
>> textual list of feature attributes whose numbers correspond to labels on
>>
>> the map.
>>
>> Are you saying that with or without ordered labelling, there's no way to
>>
>> order the features predictably?
>>
>> BTW, thanks for everyone's expert advice.  We're brand new to 
>> MapServer and still fairly new to GIS in general.
>>
>> Doug
>>
>> Steve Lime wrote:
>>
>>
>>> Actually I think I know how it could be done regardless of the value
>>
>>
>> of
>>
>>> force. When you build the labels you could use a special string like
>>> %rn% to denote a draw time substitution (just like runtime
>>
>>
>> substitutions
>>
>>> with the CGI). Then as you plop labels on the map you could keep count
>>> and each label gets the value of count+1 substituted for %rn%. If a
>>> label isn't drawn, no biggie cause the counter doesn't go anywhere
>>> either.
>>> I wonder though if there is real value in this. What do the numbers
>>> really mean? I could see utility in labeling features and then
>>> referencing them by number elsewhere on a page (e.g. found 5 hotels
>>> within 10 miles of point x). However, there's no way to tie numbers to
>>> actual features, not with more work.
>>>
>>> Could someone file a bug/feature request on this one so it doesn't get
>>> lost? I won't have time until after MUM2 to think about it.
>>>
>>> Steve
>>>
>>>
>>>
>>>>>> Stephen Woodbridge <woodbri at swoodbridge.com> 06/07/04 4:18 PM >>>
>>>
>>>
>>> Steve Lime,
>>>
>>> This should simplify the issues you raised about this feature. 
>>> Basically, the autonumber feature should just draw all the points in
>>
>>
>> the
>>
>>> view using the FORCE option so there are no renumbering issues,
>>
>>
>> because
>>
>>> they are all drawn.
>>>
>>> -Steve W.
>>>
>>> Doug wrote:
>>>
>>>
>>>
>>>> Stephen Woodbridge wrote:
>>>>
>>>>
>>>>
>>>>> Doug wrote:
>>>>>
>>>>>
>>>>>
>>>>>> The reason we're trying to stay away from MapScript is the thread 
>>>>>> safety issues we've been reading about.  That and the fact that we
>>>
>>>
>>> do
>>>
>>>>>> all of our application coding in Java, for which there doesn't
>>>
>>>
>>> appear
>>>
>>>>>> to be any standard, accepted implementation.
>>>>>>
>>>>>> So how to people use MapScript anyway if it's not thread safe?  
>>>>>> Always as separate CGI processes?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Yes, PHP is required to run as a CGI process and likewise for Perl 
>>>>> (ie: you can not run it as an apache module or mod_perl application).
>>>>>
>>>>> So what are your requirements regarding autonumbering and label 
>>>>> collisions?
>>>>>
>>>>> -Steve W.
>>>>
>>>>
>>>>
>>>> If I understand what you're asking, I think we want to show all labels
>>>
>>>
>>>
>>>> all the time, even if they collide.  Or even if some hid others, we 
>>>> wouldn't want to re-order the numbers.
>>>>
>>>> Doug