--- Begin Message ---
- Subject: Re: Servers, and fun things to do with them
- From: jerry at freeside dot com (Jeremy Porter)
- Date: Fri, 12 Apr 2002 07:26:15 +0000 (UTC)
- Newsgroups: local.lists.nomads
- References: <email@example.com>
- Sender: mail at bootstrap dot sculptors dot com
- Xref: nntp2.sculptors.com local.lists.nomads:7
This is very similar to an idea I've tossed around for a while.
The idea orginated on a 2000 mile road trip a couple of years ago.
Road conditions including construction and traffic, would be really
handle in "dynamic" road trip planning, allowing you to plan
alternate routes on the fly. (Getting stuck in construction traffic
in the middle of the night on I-80 through Nevada, gives you
time to think of these things).
So there were two key issues (in my mind) to solve.
1. Data transmission from the source to the collector.
2. Where and how the data is generated.
>In other news, the bicycle route planner idea that has been tossed
>around over the last couple of days is very cool -- on my Winnebiko
>adventure way back in the Olden Days, I used to have fantasies of
>that (though not couched in Web imagery, of course, as they hadn't
>invented HTML yet <creak>). Hams have long used an RST code,
>assigning numeric values to Readability, Signal Strength, and Tone.
>This is a convenient shorthand for signal reports and is widely used
>during CW (Morse Code) contacts. I've long since forgotten the
>acronym, but I used to imagine a 5-letter code with numbers ranging
>from 1-9 covering such things as road surface, traffic, shoulder
>width, beauty, grade, and so on. That could tag any road segment,
>allowing individual grades or variations to be marked within a
>route... it wouldn't be too much of a stretch to have a moving map
>display with an overlay showing the current data with the opportunity
>to add to the database, along with a way to scan a proposed route to
>average or browse the values. This would be easier to do with
>automated techniques than anything text-based.
Ok, looking at this and the other parts of Steve's post we can add:
3. Data service provisioning. (I.e. Hosting)
4. Data formats.
I've been doing commerical internet work since before <HTML> <creak>,
so I've never worried about #3. To me, its just a commerical service,
like telephone service, and you just buy it. Mailing lists are a
pain in the but, but Mailman is just about the easiest to admin of
any system, with a complete web interface in addition to the email
interface. It also does lots of things good old majordomo won't
do. Down side it requires python, whereas majordomo only needs perl.
Part of the reason I run my own server, is because its really convinient
to make changes, add packages, and being somewhat nomadic as a consultant
its real handy to have most of my critical datasets online. No more
leaving that critical file at home and not being able to get it.
Now of course, having to have a friend as a backup sysadmin, plus keeping
a cash reserve to fix/replace the system in a crash, is not trivial,
but having had most types of problems happen while I was out of town,
I've usually been back up in a week. And that's without any
special preperations. Its not the cheapest solution, but it works
Ok #4, while simple codes are good for data entry, or radio transmission,
etc. But for interoperability they suck. For storage and processing
they are at best tolerable. An efficient database will have a good
schema backing it, and a good data transfer language will also.
XML has the technology to do this, and it allows for dynamic extensions
of content types.
So lets go look back at #1 and #2 again:
1. Data transmission from the source to the collector
Back when Steve was making his trips, amature radio was one of the only
ways of sending digitial data out without physicial connectivity.
Today we have CDPD, WAP/CDMA data bearer service, GSM, RAM mobile,
2 way satelite paging, etc. Fundmentally, all are internet
access. Although cost effective techniques for long distance
travel are still iffy, as few of the cellular based services really
operate well oustide of cities and the interstate highway system.
2. Where and how the data is generated.
Ok first off, technomads could generate the data, as they would be
likely to have the communication tools, etc. But there aren't that
many of them out there. But who is out on the road a good bit,
truckers, professional travellers, etc. And these people would also
be interested in using the data as well as providing it, just look at
one of the single remaining uses for CB radio.
>One could even integrate this with route-planning software once the
>database was rich enough. Simply enter the parameters for which you
>want the software to optimize, along with start and end points... and
>the widget would return total mileage, average road-code, percentage
>of the route with traffic greater than x, climb data, etc. And while
>we're at it, quoth the Microship guy, how about doing a similar thing
>for waterways, kayak routes, and so on? In fact... hm... this is
>sounding a LOT like the Datawake tools we've already postulated in
>proposal form: a tool for integrating environmental telemetry from
>an arbitrary number of mostly mobile nodes, including community trust
>values and linked text/image files.
Really there are two remaining problems, data collating and processing.
This isn't trivial, but its a managable problem, if the data formats
interoperate. Having a tool that could take in say USGS public domain
GIS data, gps link telemetry, and gps link commentary, collate them,
and output them graphicly. Probably on low bandwidth links you
don't want to send the graphics, so a local rendering engine might
be good, plus element caching. (Road positions are going to change
much, but old traffic data isn't terribly useful).
My recommendation would be an XML compliant dataset stored in a SQL
backend, with some type of java based rendering applet. You would need
some type of local caching applet that would have write access to
store persistant data on the hard drive due to the java security
>Maybe if we get a nice robust server donated for all
>technomad-related things, we could host this (sticking my neck out,
>as *I'm* certainly not going to write it! <grin>)
I'd say this sort of thinking is perhaps why this hasn't happened.
I've seen a number of good commerical business ideas proposed here
in the last 3 or 4 (or more) years, that haven't been done, or someone
without any technomadic background implements, simply because its a
good business idea. Personally having found the rather limited utility
of a number of "trip planning softwares" or "GIS" ("TOPO GPS") softwares
and no real tools for linking in current data on road construction
or congestion and rather limited linking of GPS and outside maps,
and the completely closed and properitary nature of these tools,
I'd pay for a service that had good data. And there is a good case
to be made for paying data contributors (at least in usage credits) for
their work. Given the low bandwidth requirements of a well designed
system, this could be a real money maker, once the key software
components are writen, and CBers, HAM radio operators are already doing
this. (HAM radio APRS has this capaiblity built in, but not utilized
in part due to poor protocols and copyrights on "APRS" name and formats.)
But if people were interested in doing this as a business, and were
interested in rasiing the money to write software, or found programers
willing to write it, even though a business would use it to make money,
as open source software, then I'd certainly be willing to talk more about
I seriously considered a mail forwarding type service, with scanning
and email/fax/voicemail gateways, etc, but the overhead in software
and hardware to provide voice/fax gateway service, and the business
itself being far afield of my core business, made it not realistic
to pursue. And there are companies now that do that even if they
all have some issues, either privacy, cost, spammy-ness, etc.
But the whole GIS, realtime data merging features of this idea
really amount to a killer app. Plus by utilizing "free" data submission
and editing by users (in return for usage credits) it makes a fairly
>Cheers from the Microship book-writing sweatshop, where little else
>is getting done...
>Steven K. Roberts, N4RVE Nomadic Research Labs
>Microship Website: http://www.microship.com
>Current location: Camano Island, WA
>The Microship live page carries a new photo and short text update
>almost every day: http://www.microship.com/latestnews/live.html
--- jerry at freeside dot com
Freeside Orbitial Construction Corps
--- End Message ---