Is a compile needed for the client code, or just for the server code?
Is the server code required to run the client code? If so, I might
need the server code. Maybe?
Nice. How are you creating heat maps and taxon footprints?
> Drawing the points corresponding to the rows in the results grid is
> something the browser can handle, though not as well as I might like.
What's a good example of where the browser doesn't handle it as well
as you'd like?
> We're
> already passing the Lat/Lng in the results set. In my first pass at this, I
> grabbed the data I needed, formatted it as GeoJSON, and passed it to
> OpenLayers to be read. To be production-ready I would want a degree of
> interactivity between the points on the map and the rows in the grid.
Totally. Sounds like you want a clickable marker that's synchronized
with the corresponding row in the grid. What additional interactivity
are you thinking would be useful? We're working on the same thing
right now with the Google Maps API.
> The heat map/taxon footprint is likely going to be its own service, simply
> because result sets can be so much larger than anything the browser could
> reasonably process.
I'm assuming a result set is a single image? What if the result set
image was tiled instead? Then they could be overlaid onto the map
without worrying about their size. Maybe?
> I created a prototype service to do this - you can see
> the results on our Facebook page
Rad! Is there a link for the prototype service?
> but it needs significant work before it is production-ready. The
> prototype is neither fast nor scaleable, and there's a good bit of work we'd
> like to do on 'look and feel' to balance file-size with display accuracy.
Definitely let me know more about this service. We're working on tile
services right now so there could potentially be some really great
overlap here.
> The issue we'd like to work on with the paging is on the front-end.
> Currnetly, each set of 15 results is a query to the service. We can easily
> return larger result sets (at least 150 records instead of just 15) without
> appreciable impact on performance. The query to the service is a fraction
> of a second slower, but paging within the returned results is about as close
> to instant as you can get.
We're working on the same thing right now. We found that pre-fetching
1 extra page on each page request is a good balance. So for example,
if the UI requests page 8, the server sends back page 8 and page 9. We
tried sending back more pages, but as you discovered, the query
becomes slower, and we're a leetle fanatical about performance. :)
Maybe, but working code trumps non-working code. Great job hacking
GDI+ into a heat map service! :)
So I think we're at a good point for a voice call maybe? Would be
great chatting about some of these things and also seeing about
potential overlap and collab between FishNet2 and VertNet dev. I'm
pretty tied up this week but how does next Wednesday, Thursday, or
Friday work?
>> One thing that Patrick forgot to mention. I could be wrong, but last I remember the results grid is being rendered using an external library for which we don't have the source for. I will double check next week to confirm. Since it is precompiled as a .dll, you may end up needing windows to get a flawless compile.
Just a quick follow up. I definitely want to get FishNet2 up and
running in my dev environment, but it's unclear if a compile is needed
for the client code or just the server code. Also, it's not clear if
the server code is required to run the client code. Thanks in advance
for your help. I'm definitely an ASP.NET noob. :)