Qusetion about building an interactive database editor or a set of data entry pages

[rr...@rogers.com]

I'm trying to wrap my head around what we should do in this area and how we would accomplish it.

The first question is where is our database, what is the DBM and what's its scheme look like?

How do we currently load data into it?

I think the idea is to edit the database directly but to do that, the web application editor would need direct access to the database.

If I am to undertake building something, about the only server technology that I'm compitent to build in, is a server with a full Java container (TomCat for instance) and a DBM that has a good JDBC driver. Is this something we have or could have?

Regards
Raymond

[Morten Olsen Lysgaard]

Hi rraw.
I have already started a prototype Web application using Python and the django framework. It lets us model the different map objects and the relations between them.
I started with a really minimal set of features but this is easily extendable.
What I have not done yet is a good interface. We need ways of entering data in all sorts of formats. Be it csv, XML, json etc.
I want to start with a simple multi-line textarea where each line is a lat lon coordinate. This lets us easily enter stuff like airspaces. From this we could expand to several formats for inputs.
If you would like I would take the time to learn you everything you need to contribute to this app. Python is a very easy going language and if you are familiar with any other OO language, like java, you will get it really quickly. I think my main reason for lacking contribution lately has been that I feel like I'm developing for nobody and that it never would see use. Having a Co developer would be awsome since we then could help motivate and give each other ideas.
The reason for choosing Python as a language is twofold. One that it has a wide adoption, so that maybe someone else can contribute and second that it also has support for geometries in the database layer. Another reason is that I know the framework really well. Tell me what you think :-) have a great day - Morten

--
You received this message because you are subscribed to the Google Groups "openaviationmap" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openaviationm...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Antonio Locandro]

I would really want to start adding data. I think we need an easy way to do it and maybe a roadmap.

E.g. I can create a csv file or geojson with fixes for routes or add them directly in the app

ICAOID | LATITUDE | LONGITUDE

But we need something to start working and adding more than just Hungary and specially for countries with no electronic data

[Raymond Raw]

We already have a complete set of Java objects that would be directly usable if we stayed with a Java web server. Also, we would be able to make use of all of the parser code that we've already built in the converter to quickly implement uploading of the eAIP.Hungary and the OurAirports formats that are already built. I also have an OpenAir parser that's about 50% complete that would integrate directly. Any new parsers we created would be usable both in the web app and the converter. If we go the python/django route, I think these would all need to be recoded to python. There is JPype that might be useful but I have no experience with it and would be cautious about performance. Even this would necessitate the need to build a pure Java persistent layer I think. The ideal solution might be a Service Bus approach that would allow a mixture of Java and Python but that is a little more work to create.

If we stayed with Java, I would envision layering a persistence layer below our current java objects. JPA might suffice for this or Hybernate. Similarly, we'd layer a presentation above our current objects. Left to my own, I'd probably use the Apache implementation of JSF for that.

Having said all that, I'm cool with Python and DJango if that's the best fit.

[Antonio Locandro]

I will leave the coding to the experts. That is you guys! Once you have something I can put data into I will start.

In the meantime I will create a csv file with fixes to have a head start

--
You received this message because you are subscribed to a topic in the Google Groups "openaviationmap" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openaviationmap/l7ixenlE6Kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openaviationm...@googlegroups.com.

[Raymond Raw]

What ever approach we take, I believe that interactively adding
airports, runways, radio nav aids is a fairly straight forward web app
to create. Adding airspace data might be a little trickier because of
the need to define the airspace shape which might be irregular.

As previously noted, we already have a parser for the "OurAirports"
data. This is just a set of 4 CSV files any of which could be hand
coded. I would hope that we could utilize this code somehow.

[Raymond Raw]

Antonio,

I suggest that you look at the OurAirports formats for CSVs.    www.ourairports.com  You can download a complete set of all 43315 world wide airports from their site as a starting point. A sample of these is also included in the OAM source repository.

You received this message because you are subscribed to the Google Groups "openaviationmap" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openaviationm...@googlegroups.com.

[Antonio Locandro]

Airspaces may be trickier and might need something more like an online editor to cut geographic boundaries. But at least we should have tools to create airspaces based on points, lines and arcs

--

You received this message because you are subscribed to a topic in the Google Groups "openaviationmap" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openaviationmap/l7ixenlE6Kk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openaviationmap+unsubscribe@googlegroups.com.

[Ákos Maróy]

I'm all for adding more data, and providing an easy-to-use, web-based tool to be able to add / edit data. what Morten started earlier looks very promising, or we could modify OSM's iD editor.

having said this, I successfully convinced a member of the Hungarian OSM community to start adding data via our 'old' method: JOSM. he already started to enter data from the Slovakian AIP, and will go through all the European countries, one by one. I agreed to pay him money for this work.


as for tools to develop: I also have a strong Java background, but my experience with the GeoTools toolset has not be that nice actually. it is very cumbersome, it is quite hard to work with, etc.


as for rendering into bitmaps, I think we should look into MapCSS as an option, as it looks like a very active and promising project. but in terms of visualization, I think we should look at a browser-based canvas-oriented or WebGL-oriented visualization, which is interactive too. so that one can click on a feature (airspace, airport, navaid, etc.) and find out more information about it. I think that basically this would share a lot of code with the web-based editor as well.

for example, there is a JavaScript implementation for some of the MapCSS features, called Kothic JS: https://github.com/kothic/kothic-js/wiki  , an example here: http://kothic.org/js/  - could even be a start

[Morten Olsen Lysgaard]

I feel that there always will be a battle between software stacks when
you want to start something new.
We've already tried to use the OSM stack for our data but it's just
not fit four our purpose. It feels like putting a square brick trough
a round hole, it just doen't fit.
I really believe we could use the OSM stack for some of our data, but
the core containing aerodromes, airspaces etc. seem to require more
schema to be good to work with.
There seems like we have two runner ups, Python/Django and Java.
I don't have much experience with Java and a lot in Python. That being
said I think I quite easily could start coding in Java too.
Rraw, you have experience with Java. What can we get?
We need a web framework that supports models/database objects that
have geography collumns. Preferably PostGIS. This is really important
for being able to spatially query the data, eg. a bounding box query.
Does Java have a good such framework?

Also, if we go for Java, I'm going to need support and training to
contribute which I think is key to succeed, because one person quickly
gets tired of coding for himself without any feedback.

Rraw: please take a look at this url:
http://openaviationmap.org:9000/admin/
username: test
password: test

It is a very quick sketch of a goespatial application that I started
in Django. All the features you see here we get for free. I haven't
written a single line of code to make any of this UI, forms, editing
or saving. It all comes with Django. The only thing I did was to
define how the database should look or to put it another way, what
models we should have. If there are Java frameworks that can give us
stuff like this, then I will be easier to convince :)
I know this sounds bragging like "Oooh, look what my framework can do"
but I'm not saying this because I want to troll you. I'm just not very
good at what exists in the Java world so it's nice to compare what you
get out of the box.

> --
> You received this message because you are subscribed to the Google Groups
> "openaviationmap" group.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to openaviationm...@googlegroups.com.

[Ákos Maróy]

to chip into the web frontend development debate, django was suggested by Morten, but we could look at d3 as well: http://d3js.org/  - it looks really capable

another thing we can look at is cesium, a virtual globe that can display itself both in 3D and 2D: http://cesium.agi.com/ , demos here: http://cesium.agi.com/Cesium/Apps/Sandcastle/  I have done some coding with it myself, and it is really very capable



as for rendering maps, both the ground chart and the aviation stuff, I didn't really find anything thoroughly satisfying. on one side in Java, GeoTools and JTS is a very rich feature set, with conversion between coordinate reference systems (projections), etc. but still the whole thing was very bloated, extremely memory intensive, etc. as for describing how bitmap rendering should be done, MapCSS is very promising, with two Python implementations and a JavaScript implementation - but I'm sure we have to extend MapCSS ourselves to visualize everything we need

and then there is Cesium for a WebGL-based 3D visualization, of course

[Antonio Locandro]

Like I said before I will leave the dev decisions to you guys but I really think we need a way so people like me can start inputing data soon or we will see no progress

--
You received this message because you are subscribed to a topic in the Google Groups "openaviationmap" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openaviationmap/l7ixenlE6Kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openaviationm...@googlegroups.com.

[Ákos Maróy]

On 15/09/13 19:26, Antonio Locandro wrote:

Like I said before I will leave the dev decisions to you guys but I really think we need a way so people like me can start inputing data soon or we will see no progress

I totally agree

as I said, no I have a member of the Hungarian OSM community entering aviation data for Europe, via JOSM. he's also creating JOSM templates / presets that make data entry simple if you otherwise no JOSM, and also a coordinate conversion tool, so you just paste the coordinates from an AIP, and then fill out the metadata


one additional thing that needs working on, and can be done independently, is re-doing the rendering styles, most probably in MapCSS. this doesn't require coding for a start, but basically requires writing CSS rules, looking at the ICAO map guidelines, and experimentation

I wonder if some would want to give it a go - both for the ground features (based on OSM data), and aviation features, based on our existing data?

see some info here: http://www.mapcss.org/

[Antonio Locandro]

Advantages of mapcss over cartocss? I thought openstreetmap just switched to cartocss

[Ákos Maróy]

On 15/09/13 20:52, Antonio Locandro wrote:
>
> Advantages of mapcss over cartocss? I thought openstreetmap just
> switched to cartocss
>
>

a good idea - we should compare these technologies

[Raymond Raw]

Hi all

I'm thinking for a first phase, all we want is a simple set of text based data entry screens. Leave the graphical data entry to a second phase.

So, we might have simple Aerodrome, Runway, Navaid and Airspace screens to enter the data.

Later, we could add a point and click graphics input methodology. Either d3js or cesium might work well and could be integrated with the simple text screens.

I've attached a PDF that contains a simple wireframe mockup of what an Aerodrome data entry screen might look like. Obviously, there is a lot of stuff missing from this mockup but it demonstrates the basic concept for getting the data into the system.

Cheers
Raymond

[Ákos Maróy]

On 16/09/13 05:25, Raymond Raw wrote:

Hi all

I'm thinking for a first phase, all we want is a simple set of text based data entry screens. Leave the graphical data entry to a second phase.

yes, especially as one would want to enter coordinates manually anyway (as opposed to point to locations on a map)

although showing the data right after entry in a geographically correct fashion (e.g. on a map) would serve for easy verification for the coordinates

So, we might have simple Aerodrome, Runway, Navaid and Airspace screens to enter the data.

yep

Later, we could add a point and click graphics input methodology. Either d3js or cesium might work well and could be integrated with the simple text screens.

that's my thinking actually. cesium also has a 2D mode if needed for simpler coordinate operations. showing points are polygons in 2D are extremely easy. one can also show 3D 'bodies' for airspaces, I've done quite a few such visualizations already

how I see it is that we'd need an approach for UI components (buttons, dialogs), that might be django or d3.

I've attached a PDF that contains a simple wireframe mockup of what an Aerodrome data entry screen might look like. Obviously, there is a lot of stuff missing from this mockup but it demonstrates the basic concept for getting the data into the system.

it does quite well

interestingly, the 'presets' window for JOSM that was created by the Hungarian OSM guy for data entry look almost the same :)

[Morten Olsen Lysgaard]

Hi, I've worked a bit on the database schema of the Django app.
Take a look at it and find out what is missing or what will cause
problems. If we find a good database schema we can try to import some
big datasets :)

* Is there anything that needs improvement?
* What are the next important things to model for a map?

URL: http://openaviationmap.org:9000/admin/aip/
User: test
Password: test

[Akos Maroy]

On 16/09/13 15:21, Morten Olsen Lysgaard wrote:

Hi, I've worked a bit on the database schema of the Django app.
Take a look at it and find out what is missing or what will cause
problems. If we find a good database schema we can try to import some
big datasets :)

* Is there anything that needs improvement?
* What are the next important things to model for a map?

URL: http://openaviationmap.org:9000/admin/aip/
User: test
Password: test

what is also available is the object model I created when writing the OAM java tools, which convert data among different formats. see the objects here: https://github.com/OpenAviationMap/oam-java-tools/tree/master/src/main/java/org/openaviationmap/model

even if continue with a different language / environment, this model might come in handy, as we can build on the experience I had with it

[Morten Olsen Lysgaard]

I tottally agree. In the end it's not important what technology and
language we use, as long as we get to our goal. Your experiences with
modelling in the java project are very relevant if we are going to
build a new database for aviation data.