Tactical Map Interface Standard

[Chuck]

I was hoping someone could help me by answering a few questions.
First, I’d like to be completely open about my purpose. I am working
on a Linux version of a map designed to replace JMTK. This map is
used in a UAV ground control station. I completed the first version a
couple months ago, and I am now in the process of trying to make some
improvements. My number one goal is to have the map application use
standards based interactions with client apps.

I’ve looked at WFS, WMS, and KML. It would appear that for the most
part these standards don’t apply since I’m not building a web
service. Please correct me if I'm wrong. I've looked at FalconView's
interfaces available via the SDK and it doesn’t appear that FalconView
follows a standard for the interfaces defined in the SDK. Is this
correct? I am hoping that you will say no, because one of my tasks is
to define a standard interface if one doesn’t exist.

The purpose of the standard interface is to allow anyone to build a
replacement map or use my map is any other tactical system.

Does anyone know of a standard interface for direct interaction with a
tactical map?
Assuming there isn’t a standard interface for tactical map applications
(I haven’t been able to find one), would anyone be interested in
defining one? Does anyone know of a reason this wouldn't be a good
idea?

My original thoughts revolved around using DDS at the transport
mechanism and defining a standard set of messages that would apply to
a wide range of tactical situations. This would completely remove
programming language restrictions and even OS restrictions, as far as
the interface is concerned.

[Kit Plummer]

Pretty much just playing DA here, but why couldn't use WFS, WMS, and
KML? Sure, they're generally designed for map tiling/layering over a
network, but it would seem to me that might be a good decoupling
apparatus - thinking the WFS/WMS service could happily exist on the
same machine as the GUI. The benefits would be interoperability - you
could build all kinds of apps on top of your map "service". And, if
KML is involved you could easily expose your maps to a browser, or
Google Earth, or any other KML-rendering tool.

Just a few thoughts. BTW, Geoserver is an awesome Open Source
project, and is well used in the DoD. Same for OpenLayers, another
Open Source project.

Kit

[Jae Stutzman]

Chuck,

We have a similar problem as you. We are currently using a proprietary
mapping subsystem (one i'd like to replace someday). We actually did
prototype a DDS EM (Entity Model) for tactical maps and it worked out
quite well. I'd be interested to know a bit more about what you are
trying to achieve. I also have trouble pushing these web technologies
into a tactical system. It is almost like there are two parallel
tracks of SW engineering going on. It would be nice to find common
ground, though.

Jae

[Chuck]

Thanks Kit.

I have considered doing that. I believe there are some benefits, but
there are some considerable drawbacks.

A typical scenario for using a tactical map is to create routes
through direct interaction with the map.(click on where waypoints
should be placed) It is also common place to allow the client
application to popup its own gui based on some special interaction
with the map.(shift/click on a specific location) In addition the
client application may want to display 2525B symbols or NATO APP 6A.
Mouse Events/Keyboard Events: I don't think this fits with OGC
standards, or maybe i just haven't found it yet. I'm mostly concerned
with the possible latency issues that would be associated with trying
to do this via a web service.
Mil Symbols: I also haven't seen where this might be addressed in any
of the OGC standards.

Perhaps a combination of approaches would be good, but I think WFS
would be clunky if used in the scenario above. Even if the client
application gets the mouse event quickly, how long will it take to
push the point data back to the map for display? even a 1 second
turnaround will be laggy to the user.

For reasons only known by the Navy we are required to use CJMTK
(ArcGIS). I am hoping that I can convince the Navy to use more open
source products in my next version, but for now I am happy to build a
standards based interface.

Chuck

[Jeffrey Johnson]

If a thick client makes the most sense, I suggest you have a look at
Quantum GIS as a platform to work with http://www.qgis.org/ ... an
OSGeo project and built on Qt, so cross platform (unlike FalconView)

Jeff

[Chuck]

Jae,

I think you are correct. It appears obvious that some things don't
lend themselves to a web service(items that require immediate reaction
or near 0 latency). There are also security issues on tactical
systems that must be considered. I don't think it would preclude what
Kit talked about, but security is always an issue. If nothing else,
its difficult to get web services put into a tactical system due to
security misperceptions.

Chuck

On Aug 28, 11:12 am, Jae Stutzman <jaeb...@gmail.com> wrote:
> Chuck,
>
> We have a similar problem as you. We are currently using a proprietary
> mapping subsystem (one i'd like to replace someday). We actually did
> prototype a DDS EM (Entity Model) for tactical maps and it worked out
> quite well. I'd be interested to know a bit more about what you are
> trying to achieve. I also have trouble pushing these web technologies
> into a tactical system. It is almost like there are two parallel
> tracks of SW engineering going on. It would be nice to find common
> ground, though.
>
> Jae
>

[Chuck]

Jeff,

yep, I've look at QGIS more than once. The big problem is that we
need a standard interface, instead of another interface. I want
everyone to produce maps and map clients that are interchangeable,
without additional development.

Chuck

On Aug 28, 11:16 am, Jeffrey Johnson <ortel...@gmail.com> wrote:
> If a thick client makes the most sense, I suggest you have a look at

> Quantum GIS as a platform to work withhttp://www.qgis.org/... an

> OSGeo project and built on Qt, so cross platform (unlike FalconView)
>
> Jeff
>

[Jae Stutzman]

For us, our need wasn't so much the need of map data, each client had
its own copy of "the world" on its HDD :). Our requirement was that of
the tactical data being distributed to all nodes. This is where DDS
came in as a very powerful tool. Not so much that there was a symbol
at a geolocation, but that there was a hostile, air platform, at a
location, alt, etc. Our system then rendered the symbol based on the
rules the customer specified (as an aside, we used SVG for symbology).

This doesn't mean that there isn't a use for having a combination of
technologies. Perhaps this is where a loose standard can begin to
evolve. For DDS to work, the publishers need to be using the same EM
;)

Cheers,

Jae

[Kit Plummer]

Well, I can tell you the Army uses XMPP for their mapping
collaboration tools, latency is a relative term. XMPP - web-based
tranports, work "good enough" for them, and the standards-based
approach has prompting many a great collaborative innovation.

I've posted, previously, the desire to build an Open Source Mil-
STD-2525B web service which could take in the symbol code and generate
the appropriate icon as a PNG/JPG, or whatever.

WFS is clunky, and pretty slow. But, I do know there are cases where
it has been fairly optimized (caching, etc.). When you say tactical -
do you mean the content, or the system. Is this system to be used in
the battlespace on ruggedized hardware?

Kit

[Kit Plummer]

Hmmn...I couldn't disagree more. First you'll have to define web
services. Almost every "tactical" system I've seen uses network
served content/functionality. Sure security is a concern...but, there
are well-accepted answers.

I just hate to see a system go off down a path that leads to
unnecessary complexity - based on unqualified constraints. Not saying
that is the case here - but let's not let a few unknowns preclude a
path that provides the widest spread of innovative potential.

Kit

[Kit Plummer]

Cool. Would love to talk more about this. I just built a DDS to
XMPPCollab bridge, the Army's standard for collaborative mapboarding.
Wondering if there's someway to share.

Kit

[Miles Fidelman]

You might want to look at OpenLayers (http://www.openlayers.org/) and
MapBuilder (http://docs.codehaus.org/display/MAP/Home) - they're both
open source JavaScript libraries that understand WMS, WFS, etc.

We had good luck building clients using MapBuilder, but it's now reached
end of life. However, last release of MapBuilder was built largely with
OpenLayers, so I expect you might have good luck with OpenLayers.

Miles

--
Miles R. Fidelman, Director of Government Programs
Traverse Technologies
145 Tremont Street, 3rd Floor
Boston, MA 02111
mfid...@traversetechnologies.com
857-362-8314
www.traversetechnologies.com

[Chuck]

Kit,

A mil symbol service sounds like a cool item to have. You definitely
don't want to leave out the NATO APP 6A standard.

yes. This is a UAV control station, ship based for the most part.
I've also heard of systems being mounted in a HMMWV. Ruggedized
hardware is a must.

Regards,
Chuck

[Chuck]

Jae,

So did you build your own symbology engine to handle the SVG data? If
so, is it open source by chance?

Thanks,
Chuck

[Chuck]

Jae,

So did you build your own symbology engine to handle the SVG data? If
so, is it open source by chance?

Thanks,

Chuck

On Aug 28, 11:39 am, Jae Stutzman <jaeb...@gmail.com> wrote:

[Kit Plummer]

We use OpenLayers exclusively now (staying away from Flex mapping
options, but they exist). OpenLayers has a good track record on
"fielded" systems and is pretty easy to develop with. There's also
now a nice, shiny ExtJS wrapper around OpenLayers. Check it at: http://www.geoext.org

Kit

[Kit Plummer]

Well, I kind of have to shut up now, or my previous employer will get
mad. :{

I can tell you that there's a ton of work going on to solve those very
problems, by a lot of the top defense Industrial Base. I do know that
the RFP states things like "open", "modular", "standards".

From an architectural perspective, I think DDS is probably the best
choice - just because the XML-based messaging platforms induce a ton
of overhead. But, if all comms are shipboard, you'd be well to do to
figure if DDS, or one of the others is the incumbent - and by into
that. FWIW, we've embedded a ton of "services" in embedded systems.

[At this previous employer, I built a multi-platform UAV autonomy
system, that flew all open source software, and was built using
enterprise architectures (ESB, JMS, etc.). The ground station was
built using Flash, and communicated with all the flying nodes via
STANAG-4586 messages on a distributed JMS infrastructure (ActiveMQ)
over tactical radios. The system was built from scratch, by 3 guys,
and flying collaboratively and autonmously within 6 weeks. That's the
power of OSS. Ssh. Don't tell anyone.]

[Kit Plummer]

I'd sure love to get one going. Here's my original plea: http://kitplummer.github.com/2009/07/06/milstd2525b-icon-service.html

Would love to be able to have a good suite of options too.

Kit

[Jae Stutzman]

Chuck,

Yes we built our own, sadly it is not opensource... but we used OSS
libs, rsvg, cairographics, and a handful of other tools to do the
heavy lifting. It is tied in to the layer/cache management of the
proprietary mapping toolkit we were using. Someday I'll start to have
the discussion with mgmt about being OSS not just using OSS. However,
we are still doing the latter atm.

Jae

[JDN]

I have a great deal of experience with UAVs. Ground control stations
suck. Be a real jedi and make a control station that is web based.
This way it can be device and location independent. Being able to pass
off UAV control to a supported unit via a web interface is a killer app
that we really need. Maybe you can't do that now - but if you write it
in such a way that it can be easily moved to a web service it would be
excellent.

Neutron

[JDN]

ArcGIS/CJMTK is unmitigated crap. I was the Technical Support Officer
for C2PC when they wasted 6M on that - and I'm sure at least a billion
has gone down the tubes since then. I told them not to. It is a real
shame.

Neutron

[JDN]

This is a tired argument against web services. There is absolutely no
reason that user interface activities need to depend on web traffic at
all. This is a design issue. Security issues are mythical too. The
nets are protected. In fact - a web service requires far less
accreditation scrutiny than a thick app because the web server is
accredited.

I don't know why we keep paying for non Net Centric software. I
recently used tactical radios, a laptop and a web service to show that
we can do Combat Relevant PLI more accurately and with less footprint
that the $80,000 BFT systems we have in every vehicle. We will be doing
ground CRPLI this way - because it is not offered by any other system in
the DOD.

CRPLI (among other things) is position reporting that provides a
position within a set error - or indication that such a position is not
being reported. This is helpful for de-conflicting fires - which no DOD
system currently supports.

No offense Chuck - I just think that the reason you are being directed
to make a another box is because boxes allow more revenue to flow than
software does. A web service would eliminate the thousands of boxes we
are inflicted with now. Whaddaya think the Warfighter wants? Another
box? No.

I don't mean to shoot the messenger. If you are interested in doing a
web service we have an open source project that does the video storage
and retrieval. We are working on the web service for people to tell
operators where they want the UAV to go. Once we have that - making
these instructions go to the UAV directly will be a no brainer. UAVs
are robots. Near real time controls are not required.

Neutron

[JDN]

Oh gawd. Ruggedized hardware that only does one thing is unacceptable.
Do you think we have that kind of room in our vehicles? Even on the
ships the spaces are getting crammed. The only ruggedized hardware
anyone needs is ONE standard multi-function laptop/device that does
everything we need. We have to have that anyway. Nobody needs another
one. Back to a web service.

Tell your boss that Jimmy Neutron says he/she needs to quit wasting
money on crappy hardware and make something we need. If your boss is
you then sorry - but the facts remain. Hardware dependence violates
Net-Centric doctrine. Dependence on ruggedized hardware is an expensive
and heavy violation that nobody on the deck will thank you for.

For the price of the ruggedized hardware you could likely make the last
UAV control software we will ever need.

Neutron

[JDN]

Kit - If you or any of those 3 guys can do work for us now please make
contact. You can start Oct 1.

Neutron
james....@usmc.mil

[Chuck]

Believe it or not, this system was originally crammed into two full
server racks. It was a horrible waste of tax money. Its not even
through op-eval yet, and almost everything is obsolete. Solaris 8,
analog video(replaced 2 years ago, mostly), cctv, proprietary software
products, etc. Its your typical stovepipe, large contractor, tactical
system. Our specialty is to undo all of that. Basically we move it
all to commodity hardware using open source software and open
standards as much as we can.

[Chuck]

So, let me see if I can get some of these ideas put into a useful
context.

The purpose is to provide a tactical map useful for mission planning
and execution in particular. Lets assume that we are going to make a
tactical map based completely on web service standards. I believe
this is the best long-term solution. I may not be allowed to do it
all at this moment, but lets stick with the assumption.

There are several parts of the interface that should be addressed
including display of tactical graphics, display points/line/polygons,
display georeferenced images, mouse/keyboard events, display base map
and overlay user data. Did I miss anything?
1. Display tactical graphics - Is there a standard that does this?
Is this something that we should expect to be handled by 2 and 3?
2. Display points/lines/polygons - GML, WFS
3. Display georeferenced images - WMS?
4. mouse/keyboard events - Is there a standard for this? Keep in
mind that the user needs to be able to reposition points or create new
points typically done using "rubber lines"
5. display base map data - WMS
6. overlay user data - Is there a standard for this? I suppose you'd
create some mechanism to upload the user data and then use WMS for
display?

Can someone help me fill in some of the holes?

My first task is to determine the best way to accomplish this task. I
can worry about program office imposed restrictions later.

Thanks,
Chuck

[Kit Plummer]

Quick question. Are you planning building this system under an Open
Source license?

[Chuck]

That question is above my pay grade. I know of at least one program
office that would support such an activity. The one I work for, is
still growing in that direction. The company I work for may be up for
that, but I'd really need to have a complete plan before asking. We
don't do anything around here without all the homework first.

The question I will be asked: How are we going to make our money?
I'm not sure how relevant this question is for this product, since we
are not exercising any data rights on it. (free to the government)
other questions: How long will it take to produce? What resources
will we expend building it? What is the long-term sustainability?

We have funded things in the past like OpenDDS, which haven't done
well. (we funded part of it, not developed it) We take an active roll
in several standards groups like STANAG 4586. We, as a company, push
standards based architecture all the time.

So, I've babbled on too long. The short answer is maybe.

[Kit Plummer]

Then I believe the answers to all of your previous technical questions
are, Maybe. I believe _this_ group CAN help answer some of your most
recent questions however.

On Aug 31, 2009, at 9:08 AM, Chuck wrote:

>
> That question is above my pay grade. I know of at least one program
> office that would support such an activity. The one I work for, is
> still growing in that direction. The company I work for may be up for
> that, but I'd really need to have a complete plan before asking. We
> don't do anything around here without all the homework first.
>
> The question I will be asked: How are we going to make our money?

Why does the source license change this? You're still the company
that is going to support the product right? And, there's nothing from
preventing your company from charging for the licenses.

> I'm not sure how relevant this question is for this product, since we
> are not exercising any data rights on it. (free to the government)
> other questions: How long will it take to produce? What resources
> will we expend building it? What is the long-term sustainability?

Again, these questions aren't particular to building a product where
the source is available or not. But, if you're thinking that there's
a community here/there that will help you build it - not likely.

>
> We have funded things in the past like OpenDDS, which haven't done
> well. (we funded part of it, not developed it) We take an active roll
> in several standards groups like STANAG 4586. We, as a company, push
> standards based architecture all the time.

But, you're dependent on OpenDDS right?

[John Scott]

the one argument i have seen that works is this:
1. if your company wants to productize it, figure out how much that will cost in internal funds versus what the market could realize in profits. (most services companies won't spend IR&D funds past a certain point unless there is a big payoff)
2. OR make the argument that the gov (and others) can be a partner in developing the software as OSS. you are paid for services, features and upgrades. Also to runt he baseline. Very important to get buy in from you customer, btw to support the model. 
- I've noticed that proposed gov work where the work is converted to OSS is perceived as less risky for the gov. and higher value.

the falconview PPT had some good slides on their decision process.

OR shortcut the whole process and have the gov pay you some nominal amount to convert to OSS as services, thats what we did
js

--
------------------------------------------------------------------
John Scott
< johnm...@mindspring.com >
<     jms...@gmail.com      >
ph 240.401.6574

[Chris Williams]

Comments in-line...

On Aug 31, 11:40 am, Chuck <chuck.mess...@gmail.com> wrote:
> So, let me see if I can get some of these ideas put into a useful
> context.
>
> The purpose is to provide a tactical map useful for mission planning
> and execution in particular.  Lets assume that we are going to make a
> tactical map based completely on web service standards.  I believe
> this is the best long-term solution.  I may not be allowed to do it
> all at this moment, but lets stick with the assumption.
>
> There are several parts of the interface that should be addressed
> including display of tactical graphics, display points/line/polygons,
> display georeferenced images, mouse/keyboard events, display base map
> and overlay user data.  Did I miss anything?
> 1.  Display tactical graphics - Is there a standard that does this?
> Is this something that we should expect to be handled by 2 and 3?
> 2.  Display points/lines/polygons - GML, WFS

I would also include KML in your list (especially for vector type
data) since the spec is now taken over by OGC. While there might not
be a webservice per se to drive it, it would at least define the
format.

> 3.  Display georeferenced images - WMS?
> 4.  mouse/keyboard events - Is there a standard for this?  Keep in
> mind that the user needs to be able to reposition points or create new
> points typically done using "rubber lines"

I am not familair with any standard for this type of data but I would
be interested in knowing if you find anything. The closest concept I
have seen is using XMPP to send mouse/keyboard type events for
controlling remote systems for collaboration.

> 5.  display base map data - WMS
> 6.  overlay user data - Is there a standard for this?  I suppose you'd
> create some mechanism to upload the user data and then use WMS for
> display?

Again, I would look at KML.

> > > >>>>> the interface is concerned.- Hide quoted text -
>
> - Show quoted text -

[Chuck]

Kit,

I appreciate you being candid. It wasn't my intention to offend you.
I realize I asked a few questions that are too close to
implementation. I withdraw my implementation related questions. I am
however forced to deal with the open standards problem before I can
deal with the open source issue. The big thing for me is that I need
to make sure I haven't missed a standard that would support a tactical
map. If there are any gaps, I need to identify them and help define a
new open standard to fill those gaps.

I agree that we can make our money supporting these products. As I
pointed out, its irrelevant for this product anyhow, since we are just
giving it free to the Navy. This fact should help sell the idea of
moving it to open source.

No, we are not dependent on OpenDDS. We may have funded part of its
development, but we will use whatever product implements DDS the
best.

Chuck

> ...
>
> read more »

[Kit Plummer]

Dang, sorry man...I'm not offended. Definitely didn't mean to come
off as offended, my bad - digi-comms suck sometimes. I just want to
ensure if I'm putting in effort (to a Mil-OSS working group) that the
end result is opened. :)

Completely understand on the open standards part. As was mentioned
previous, I think you're much better positioned with "services"
regarding standards. The AFs new path to consolidating GSes is
interesting and full of buzzwords like "modular". But, modular is a
huge proponent of "Open" systems.

If you have access to AKO/DKO - do look up XMPPCollab.

Quick suggestion, don't get hung up on "Web Services" - you can have a
SOA with WS-*.

Kit

[Joel Odom]

FalconView has a set of COM APIs for drawing to the map. FalconView
4.3 will support KML and WMS, so that may be a good way to go if you
are looking for drawing to FalconView using a standard. Hope that
helps.

On Aug 28, 9:14 am, Chuck <chuck.mess...@gmail.com> wrote:
> I was hoping someone could help me by answering a few questions.
> First, I’d like to be completely open about my purpose.  I am working
> on a Linux version of a map designed to replace JMTK.  This map is
> used in a UAV ground control station.  I completed the first version a

[Chuck]

Yep, can't forget KML.

I'll let you know what I find for mouse/keyboard event standards.

> ...
>
> read more »

[Chuck]

My bosses are already very supportive of OSS, so i don't think it'll
be a hard sell. Thanks for the info.

On Aug 31, 1:28 pm, John Scott <jms...@gmail.com> wrote:
> the one argument i have seen that works is this:
> 1. if your company wants to productize it, figure out how much that will
> cost in internal funds versus what the market could realize in profits.
> (most services companies won't spend IR&D funds past a certain point unless
> there is a big payoff)
> 2. OR make the argument that the gov (and others) can be a partner in
> developing the software as OSS. you are paid for services, features and
> upgrades. Also to runt he baseline. Very important to get buy in from you
> customer, btw to support the model.
> - I've noticed that proposed gov work where the work is converted to OSS is
> perceived as less risky for the gov. and higher value.
>
> the falconview PPT had some good slides on their decision process.
>
> OR shortcut the whole process and have the gov pay you some nominal amount
> to convert to OSS as services, thats what we did
> js
>

> ...
>
> read more »

[Chuck]

My bosses are already very supportive of OSS, so i don't think it'll
be a hard sell. Thanks for the info.

On Aug 31, 1:28 pm, John Scott <jms...@gmail.com> wrote:

> the one argument i have seen that works is this:
> 1. if your company wants to productize it, figure out how much that will
> cost in internal funds versus what the market could realize in profits.
> (most services companies won't spend IR&D funds past a certain point unless
> there is a big payoff)
> 2. OR make the argument that the gov (and others) can be a partner in
> developing the software as OSS. you are paid for services, features and
> upgrades. Also to runt he baseline. Very important to get buy in from you
> customer, btw to support the model.
> - I've noticed that proposed gov work where the work is converted to OSS is
> perceived as less risky for the gov. and higher value.
>
> the falconview PPT had some good slides on their decision process.
>
> OR shortcut the whole process and have the gov pay you some nominal amount
> to convert to OSS as services, thats what we did
> js
>

> ...
>
> read more »

[Chuck]

Kit,

I'm glad you weren't offended. I completely understand not wanting
your work used on a closed source product. That's just a waste of
time, unless that's your job.
I've heard of XMPP Collab, but don't have access to AKO/DKO. I haven't
looked seriously at XMPP yet.

We've also looked at a couple options with SOA that doesn't use web
services.

> ...
>
> read more »

[Chuck]

Kit,

I'm glad you weren't offended. I completely understand not wanting
your work used on a closed source product. That's just a waste of
time, unless that's your job.
I've heard of XMPP Collab, but don't have access to AKO/DKO. I haven't
looked seriously at XMPP yet.

We've also looked at a couple options with SOA that doesn't use web
services.

> ...
>
> read more »

[Brad Cox]

Chuck, some of your questions suggest that you think standards apply
everywhere (beween mouse and cpu for example).

Standards apply across *major interfaces*; in this case to the long-haul
wire (internet for example) between map authors and readers. Mouse/keyboard
traffic is the internal (possibly proprietary) business of the developer
(really mouse/keyboard manufacturers).

I don't see any reason to pass that anyway between map readers and writers;
just the maps and symbols, and coordinates to say where they go. For
maps/symbols, there's PNG, JPG and SVG. For coordinates, there's KML and
others.

Don't see where you'd need to look much further, except maybe XML/SOAP for
wrappers.

[Kit Plummer]

Brad,

I think what Chuck is looking for with mouse/kbd - is the
collaboration stuff. The Army is doing a lot of stuff (fallout from
FCS) with "mapboarding" live collaboration on map data. I'm not
saying that this deserving of its own standard. Just pointing out
that handling of user input in a collaborative environment is
something on the table I believe. Seems like it would be good to have
a standard messaging scheme/format for handling distributed
callbacks. Now, I could be completely out in left-field here. :)

Kit

[Miles Fidelman]

And of course there ARE standards and quasi-standards related to mouse
events:

- at the hardware level, USB defines standards for Human Interface
Devices (http://www.usb.org/developers/hidpage/)

- at the O/S level - Windows, MacOS, and Linux each have standard ways
to handle mouse events, and then there are popular cross-platform GUI
toolkits

- at the software level, DOM Level 2 establishes a clear set of mouse
event definitions
(http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mouseevents)

- at the protocol level, the X-Windows core protocol addresses some of
this, Microsoft has their Remote Desktop Protocol, there's a proposal
for encoding mouse events over XMPP (simple whiteboarding protocol -
http://xmpp.org/extensions/xep-0113.html)

There's no lack of standards and quasi-standards - the real question is
which ones are actually being used, and which ones are likely to have
legs for the future.

Miles

Kit Plummer wrote:
> Brad,
>
> I think what Chuck is looking for with mouse/kbd - is the
> collaboration stuff. The Army is doing a lot of stuff (fallout from
> FCS) with "mapboarding" live collaboration on map data. I'm not
> saying that this deserving of its own standard. Just pointing out
> that handling of user input in a collaborative environment is
> something on the table I believe. Seems like it would be good to have
> a standard messaging scheme/format for handling distributed
> callbacks. Now, I could be completely out in left-field here. :)
>
> Kit
>
> On Aug 31, 2009, at 4:04 PM, Brad Cox wrote:
>
>> Chuck, some of your questions suggest that you think standards apply
>> everywhere (beween mouse and cpu for example).
>>
>> Standards apply across *major interfaces*; in this case to the long-
>> haul wire (internet for example) between map authors and readers. Mouse/
>> keyboard traffic is the internal (possibly proprietary) business of the
>> developer(really mouse/keyboard manufacturers).
>>

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

--
Miles R. Fidelman, Director of Government Programs
Traverse Technologies
145 Tremont Street, 3rd Floor
Boston, MA 02111
mfid...@traversetechnologies.com
857-362-8314
www.traversetechnologies.com

[Brad Cox]

Thanks, Miles and Kit. Quite right. Just saying, I couldn't see a need for
passing detailed writer actions between map writers and readers. KML (geo
coordinates) would suffice to put symbols on maps, cursors on targets, etc.
More advanced interaction, all bets are off.

[Miles Fidelman]

It occurs to me that, years ago, we had shared whiteboards in BBN Slate
(and maybe in its predecessor, the Diamond Messaging System). I don't
think anybody ever got cursor-control handoff to work right, and the
linked desktops always lost sync. I'm not sure anybody has gotten it
right since, either - for example in services like go-to-meeting.

>> Kit Plummer wrote:
>>
>>> Brad,
>>>
>>> I think what Chuck is looking for with mouse/kbd - is the
>>> collaboration stuff. The Army is doing a lot of stuff (fallout from
>>> FCS) with "mapboarding" live collaboration on map data. I'm not
>>> saying that this deserving of its own standard. Just pointing out
>>> that handling of user input in a collaborative environment is
>>> something on the table I believe. Seems like it would be good to have
>>> a standard messaging scheme/format for handling distributed
>>> callbacks. Now, I could be completely out in left-field here. :)
>>>

[Daniel Risacher]

Not to mention that bringing computing hardware onto a USN platform is soon to be forbidden for anyone except the CANES program.  CANES - Consolidated Afloat Network Enterprise Services.   They buy the hardware, they shock-and-vibe it, they mount it.  Everyone else uses it.  You will not be allowed to bring your own ruggedized computer onto a Navy vessel.  Get used to the idea that your Navy application will be delivered in a jewel case, not a green flyaway case.  

Dan 

[JDN]

Sounds like ISRIS.. Sounds like you are on the right track .. but
ArcGIS has got to go.

[JDN]

Chuck,
There are tons of tools that do all of those things already. If
you make UAS control module for Google Earth you are done. Should take
about 6 hours. Your boss would hate that.

We currently have about 6 tools for viewing that stuff (including
GE) and we don't need anymore (please). We need the back-end
architecture that will make them work and not all show different
versions of the "COP".

We need webn services that can be combined with the existing tools.
Then spend the rest of your money on hard UAS problems like accuracy,
time delay, targeting, BDA, storage and retrieval.

N

[Robot]

You may also want to check out openmap. Its by bbn but they've open
sourced it.

[John Scott III]

is this group still interested in having a version of MIL-STD-2525B being purely OSS?

A while back Matt G. (http://groups.google.com/group/mil-oss/tree/browse_frm/month/2009-07?_done=%2Fgroup%2Fmil-oss%2Fbrowse_frm%2Fmonth%2F2009-07%3F&) had mentioned he had a version out in the open. 

I have a client who wants one and could fund one, or fund an update. 

Neutron, Matt, Kit??

js

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Military Open Source Software" group.
To post to this group, send email to mil...@googlegroups.com
To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
-~----------~----~----~----~------~----~------~--~---

-----------------------------------------------------------

John Scott

 240.401.6574

< jms...@gmail.com >

http://powdermonkey.blogs.com

tweets @johnmscott

Have you joined MIL-OSS: 

http://mil-oss.org/

http://groups.google.com/group/mil-oss

WG 3 mtg in Atlanta August, 2011

[Kit Plummer]

The question is "what is needed"? My original idea was a web-based
(RESTful) service that a SPEC/code could be submitted to, and have an
image/icon generated - returned as a PNG/SVG/other.

Matt's tool kinda does this, but not really, in a desktop app format.
I'm looking through my emails - there are a few other options out that
have been released (under some license) that are a bit closer to my
idea.

Kit

> --
> You received this message because you are subscribed to the "Military Open
> Source Software" Google Group.

> To post to this group, send email to mil...@googlegroups.com
> To unsubscribe from this group, send email to
> mil-oss+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/mil-oss?hl=en
>

> www.mil-oss.org
>

[Chaim Krause]

I have started one, but, at this point, it is only a place holder, as
other events have overtaken it. However, I should be able to restart it
very soon.

As Kit asked, what all is wanted?

Tell you what. I will do this. Give me 24 hours and I will add
functionality to the website to take feature requests. Right now it is
only a homepage placeholder.

http://open-std-2525.org

I have SVG versions of all the mil-std-2525 symbols. It will use Django,
Piston, and PIL to return graphics via a RESTful API.

I would be open to sponsorship, to cover hosting costs, if your client
is interested. That would help me support the case for spending time on
it, as my significant other which is also competing for my time. ;)

Feel free to reply to me direct or via this list.

--Chaim

>> First, I�d like to be completely open about my purpose. I am

>>
>> working
>>
>> on a Linux version of a map designed to replace JMTK. This map is
>>
>> used in a UAV ground control station. I completed the first
>>
>> version a
>>
>> couple months ago, and I am now in the process of trying to make
>>
>> some
>>
>> improvements. My number one goal is to have the map application use
>>
>> standards based interactions with client apps.
>>

>> I�ve looked at WFS, WMS, and KML. It would appear that for the most
>>
>> part these standards don�t apply since I�m not building a web

>>
>> service. Please correct me if I'm wrong. I've looked at
>>
>> FalconView's
>>

>> interfaces available via the SDK and it doesn�t appear that

>>
>> FalconView
>>
>> follows a standard for the interfaces defined in the SDK. Is this
>>
>> correct? I am hoping that you will say no, because one of my
>>
>> tasks is
>>

>> to define a standard interface if one doesn�t exist.

>>
>> The purpose of the standard interface is to allow anyone to build a
>>
>> replacement map or use my map is any other tactical system.
>>
>> Does anyone know of a standard interface for direct interaction
>>
>> with a
>>
>> tactical map?
>>

>> Assuming there isn�t a standard interface for tactical map
>>
>> applications
>>
>> (I haven�t been able to find one), would anyone be interested in

[John Scott III]

cool

First, I’d like to be completely open about my purpose.  I am

working

on a Linux version of a map designed to replace JMTK.  This map is

used in a UAV ground control station.  I completed the first

version a

couple months ago, and I am now in the process of trying to make

some

improvements.  My number one goal is to have the map application use

standards based interactions with client apps.

I’ve looked at WFS, WMS, and KML.  It would appear that for the most

part these standards don’t apply since I’m not building a web

service.  Please correct me if I'm wrong.  I've looked at

FalconView's

interfaces available via the SDK and it doesn’t appear that

FalconView

follows a standard for the interfaces defined in the SDK.  Is this

correct?  I am hoping that you will say no, because one of my

tasks is

to define a standard interface if one doesn’t exist.

The purpose of the standard interface is to allow anyone to build a

replacement map or use my map is any other tactical system.

Does anyone know of a standard interface for direct interaction

with a

tactical map?

Assuming there isn’t a standard interface for tactical map

applications

(I haven’t been able to find one), would anyone be interested in

[Chaim Krause]

I have set up a site to start taking feature requests.

http://openstd2525.uservoice.com

[Gene McCulley]

Here is a demo of a simple REST wrapper around OpenMap: http://www.stackframe.com/SymbolFactory/

It is part of a system we are building. It is on our public website purely for demo purposes right now.

If anybody is interested in developing something around this, feel free to contact me.

Gene McCulley
StackFrame, LLC
mccu...@stackframe.com
http://www.stackframe.com/
voice: 321-206-8908
fax: 321-256-2962

> --

> You received this message because you are subscribed to the "Military Open Source Software" Google Group.

> To post to this group, send email to mil...@googlegroups.com
> To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
>

> www.mil-oss.org

[Miles Fidelman]

Gene McCulley wrote:
> Here is a demo of a simple REST wrapper around OpenMap: http://www.stackframe.com/SymbolFactory/
>
>

Now that's cool!

--
In theory, there is no difference between theory and practice.

In<fnord> practice, there is. .... Yogi Berra

[Kit Plummer]

It'd be cool if the service was open source, and could be
extended/built-out by a community.