Mapping Application

[phoenix]

There's a bit of work going on behind the scenes to put together a mapping database / application on the HU website, which could be used to store details of repair shops, dealerships (and other useful stuff) that we all encounter on our travels. All this info could then be automatically searched, displayed on a map page somewhere within the website, for downloading, printing, etc.

Does anyone have any input on what sort of data/functionality we
a) require?
b) would be nice?
c) definitely don't need or want?

[spooky]

Originally Posted by phoenix

data/functionality we
a) require?
b) would be nice?
c) definitely don't need or want?

a)
GPS data with way points description of the location:
Border crossing, hot-spots, strategic fuel stations, repair shops, tech-tips and so on.
Visa and paper advice, recommendations what to take care of, equipment advice and so on..

b)
descriptions of (shortest, nicest and dangers roads)
may advice or a list for places to work on the journey, or just must go tips.
may a download data base for PDF-files for forms and official notes..

c)
entertainment parks, common tourist hot-spots, bla bla...

[phoenix]

We're focussing on the 'mapping' aspect of it for now, so stuff like the following is more like a "phase 2" set of requirements.. (ie, it's not really mapping related, which is what we're *initially* concerned with)

...tech-tips and so on.
Visa and paper advice, recommendations what to take care of, equipment advice and so on..

Once we have the positional (GPS) stuff in place, we could certainly link from there to stuff like forms, recommendations, checklists etc..

[Frank Warner]

Originally Posted by phoenix

There's a bit of work going on behind the scenes to put together a mapping database / application on the HU website, which could be used to store details of repair shops, dealerships (and other useful stuff)



Does anyone have any input on what sort of data/functionality we
a) require?
b) would be nice?
c) definitely don't need or want?

Some ideas .. kick these around ..

As the data would be in a form useable by a gps it would be convient if it were downlaodable in a gps friendly POI format - say .gpx? You need the maping format for those without a gps. But those with a gps (and those would be the people providing the information?) would prefer the gps data.

As I see it most of us have greater difficluties in larger towns .. so the needs are
accomodation - prefer cheap on the outskirts of town .. or cheap and secure inside the town. (campsites, Hotels .. Pubs .. etc)

Information centres - good for info on laundromats (or other washing type places), festivals, etc

repair places (even tyre places )

Umm good places to eat , and drink

Shoping places (for food)

----- Only need petrol places when it gets remote .. or it is Sunday.

[Rebaseonu]

Good idea to make such database. I don't know what do you mean by mapping? I think most important are waypoints, eg waypoint database where all users can contribute. Then you can download all waypoints in given country or region in say .GPX format. Or user can select the types of waypoints to be included in downloadable file.

[phoenix]

.GPX support is being factored in.. A second format like CSV shouldn't be too much of an issue for non GPS users. Like you say, the main user base is likely to be GPS users though.

The current data model supports storing all the things you mention.. the devil is in the detail though!

When we say "mapping", we mean "to do with maps", or something like that. Basically, we mean GPS data, and hopefully a nice interface to it.. think google maps, google earth, mirosoft virtual earth, that sort of thing... but for bikers!

[crazymanneil]

Phoenix et al,

Not sure if you have noticed this thread too -

http://www.horizonsunlimited.com/hub...le-earth-27454

Basically I can help if useful. I've some PHP/MySQL experience and been reading up about KML files for Google earth. Could perhaps do a conversion script from your DB to google earth?

Neil

[phoenix]

The plot thickens..

Yep, I've seen the thread.. The background on whats going on elsewhere is that we have a draft MySQL database schema in place that supports a lot of the ideas that have been discussed on the HUBB (including the ability for people to enter GPS positions, routes, etc). The plan now is to put a Drupal (based on PHP) web frontend on it, and expose it somewhere within the HU website (probably first on the dev website).. This is the harder bit, from what I can see (but then I say that because database development is my bread and butter, but web development isn't).

In the discussions that we've had, Grant has ruled out Google Earth for one simple reason: you need to have it installed on the pc, which is not very compatible with travellers using under-specced pcs in internet cafes all over the world. The alternative is a web based approach, with nothing to be installed on the pc (other than the usual browser, and perhaps Javascript). This might use something like yahoo maps, google maps, or some other map provider.

If you have some free time on your hands, and can help with the development (MySQL/PHP/Drupal/JavaScript), I suggest having a word with Grant & jefff8.. Help is always welcome..

On the database to Google Earth conversion.. I just did version 0.1 of that tonight in order to have a look at some of our test data in Google Earth.. (using CSV file export/import).. I didn't see this db->Google Earth bit as a core part of the app (I did it more to satisfy my curiosity), but if you write a nice conversion from the database to GPX/KML/whatever, that should definitely be usable to us somewhere.

Colm

[Smellybiker]

I could convert the POI's into a GPS map that folks could load into a Garmin receiver & make that a freebie download for Hubbers..... could add'em to the Wanderlust maps as well ;-)

[phoenix]

Great, Anyone with technical (programming) skills, time, and inclination, I suggest they contact Grant & jefff8. I'll post them to make sure they're aware of the discussion here too.

[BklynDakar]

I agree that the most useful data is cheap lodging with secure parking in major towns, then maybe service locations and so on. I seem to be in the minority of opinion, however.

I am working on a database that hopefully will be part of the future HU map, but it is a lot of work. If anyone wants to help or has data they are willing to contribute please PM me.

Originally Posted by Frank Warner

Some ideas .. kick these around ..

As the data would be in a form useable by a gps it would be convient if it were downlaodable in a gps friendly POI format - say .gpx? You need the maping format for those without a gps. But those with a gps (and those would be the people providing the information?) would prefer the gps data.

As I see it most of us have greater difficluties in larger towns .. so the needs are
accomodation - prefer cheap on the outskirts of town .. or cheap and secure inside the town. (campsites, Hotels .. Pubs .. etc)

Information centres - good for info on laundromats (or other washing type places), festivals, etc

repair places (even tyre places )

Umm good places to eat , and drink

Shoping places (for food)

----- Only need petrol places when it gets remote .. or it is Sunday.

[phoenix]

Jacob,

There's already a database in place on the dev server, with the data model documented at the following post.. (indeed, this data model took into account the fields you named, earlier in the same post).

http://www.horizonsunlimited.com/hub...lication-25491

Is this the sort of thing you're after? Any potential changes are still up for grabs, but it won't be long before we start committing to this model (by virtue of code we'll have built that uses it).

I'm just about to start looking at putting a Drupal front end on it, with guidance from Jeff and Grant. We could do with any help we can get.

If you want to move independently, or aren't interested in Drupal/PHP (which I'm still learning), it's probably still best to use the same data model (if possible).. that way, we don't waste time and energy with two divergent data models. It will also minimise data migration issues from one data model to the other.

The data model supports all the things you mention.. it's just a matter of putting the relevant data in the "thingtype" table, and building on a front end, to allow us to input / retrieve data. I suspect we'll need at least one generic front-end to input / query data initially. This generic screen should be able to handle any type of positional data (motels / parking / cheap motels, whatever), until we get something more specific in place for that particular type of data (which would probably be driven by demand).

Colm