Re: [opennms-devel] Updated Node Map patches post OUCE2011

[Duncan M. <DMa...@cb...>]

Alex has turned this project over to me - as may be obvious from my other recent posts, I'm migrating it to REST so it uses the correct database framework.

I'm holding off on integrating it with the other map interfaces for now, but we still need a decision on the database changes. There didn't seem to be any real objections to adding the node_geolocation table, so could that be considered now? I've updated NMS-4356 with two new patches - one is a replacement for Alex's initial patch that removes the System.out.println("*****...") lines; the other is my own minor tweak to the new OnmsGeolocation in opennms-model, just to make it use @XmlElement consistently for lat/lon fields. If you've already poked around with Alex's original changes you may not need these at all.

Thanks,
Duncan Mackintosh
NMS Software Engineer
________________________________________
From: Benjamin Reed [ra...@op...]
Sent: 01 June 2011 13:54
To: OpenNMS Code Development and Bugs
Subject: Re: [opennms-devel] Updated Node Map patches post OUCE2011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aha!  See, this is what I get for responding before seeing the other
messages.  ;)

On 6/1/11 6:20 AM, ker...@be... wrote:
> 1. Add the concept of node geo-location to the data model

Excellent.  This has been in the back of my head for a while.
>
> Currently this patch simply add the node_geolocation table which can
> be queried higher up. Speaking to David Hustance at the conference he
> suggested it might be worth simply adding longitude and latitude
> directly to the node table. I'm not averse to this change but before
> going ahead we should probably think about additional geo location
> information.

No, I think it's a good idea to have it be separate.  For one thing, a
simple join is no slower, but when you don't need the extra information
from the DB, we won't get it.  Not only that, it means we can eventually
associate geolocations with things that aren't just strictly nodes.  We
already have geolocations on remote pollers as well, which aren't nodes,
so we'd be duplicating stuff regardless.

> In our application space there are couple of other variables that
> would be useful to know. These include height and orientation (bearing
> and downtilt). While not relevant to a lot of elements useful things
> can be done with the data if known. However it probably wouldn't make
> sense to extend the node table with this extra information.

Put it in the asset table?  It's already a dumping ground for everything
else.. .  :P
> 2. Add a number of servlets to support mapping
>
> Currently this hand generates some JSON used by the mapping layer. It
> provides two methods currently:
>
> * getMapViewCategories - fetch a list of categories
> * getMapNodes - fetch a list of nodes based on category
>
> I would probably want to extend getMapNodes to get based on a node id
> and child depth instead of just surveillance category.
>
> The greatest criticism of this bit is it avoids the DAO and as a
> result doesn't automatically benefit from any ACL's that have been set
> up. Seth (I think) also pointed out that OpenNMS already has a number
> of libraries that deal with JSON encoding for the OpenNMS RESTful API.
>
> I think the best course of action would to be to convert these
> servlets into a properly supported RESTful service. Are there any
> existing examples that are particularly good for showing how to
> implement the plumbing for an OpenNMS RESTful service?

Yeah, all of the rest code in opennms-services is actually pretty
simple.  It should take no time at all to clone one and expose the model
data that way.

> 3. Add a slippy node map
>
> This last patch is pure JavaScript. It uses the OpenLayers JavaScript
> library and the previously mentioned servlets to render the map. The
> greatest problem with it is it duplicates a lot of the generic mapping
> infrastructure which is already in place.
>
> However it is unlikely in the short term that I could get up to speed
> with the GWT coding involved to extend the existing Remote Poller map
> and replicate the current functionality. However if the first two
> additions can be committed with appropriately blessed interfaces then
> it reduces this to a simple client only patch which can be replaced
> once someone looks at representing nodes in the existing GWT based
> machinery.
>
> I did have a brief play with the Remote Poller map trying to get it to
> support WMS style OpenLayers maps (rather than XYZ style). Donald
> Desloge did give me a hand trying to get it to work and said he might
> have a chance to play with that later.

Yeah, the biggest issue I ran into is the difference in projections.  I
think the OpenLayers bits *were* using WMS layers at one point, but when
I moved to the (freely available) OpenMapQuest data, I got it moved over
to XYZ.

> Anyway comments, criticisms and pointers to analogous implementations
> gratefully received.

I think the infrastructural ideas for #1 and 2 are good, I just really
don't think we need a *third* map implementation.  It's time to start
consolidating.

When we get through the release candidate and Dev-Jam, I should have
more time to help out with this stuff, I can help work through
implementation bits.

- --
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFN5jaKUu+jZtP2Zf4RArebAJ40EONO9LcPpr0szu9msFlWMXFuwgCgkrpP
RtL5eMVLXOun0B4CW0cdLic=
=YOB9
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-devel mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
Cambridge Broadband Networks Limited Registered in England and Wales under company number: 03879840 Registered office: Selwyn House, Cambridge Business Park, Cowley Road, Cambridge CB4 0WZ, UK. VAT number: GB 741 0186 64