NBEMS - Amateur Radio program

Some discussions just don't fit into a well defined box. Use this forum to discuss general topics and issues revolving around the Church and the technology offerings we use and share.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#11

Post by RossEvans »

Bill.Stewman wrote:Thanks for the warning, but most of the geocoding seems OK.

I fully expect that "most" of the geocoding performed by that web site is okay. The problem is that for applications such as emergency preparedness, "most" is not nearly good enough.

Would the stake president want to send a team to rescue the Jones family, trapped on their roof by a flood, directing the team to a location that was a couple of miles from where the Jones house really is? The time to resolve the geocoding errors is long before the flood hits. That's why it's called "preparedness."
Bill.Stewman wrote:What are the better options to place each home more accurately?

One option may be to wait for the Church's own geocoding/mapping application, now reported to be in beta. It apparently will include a step for correction of geocoding errors and capturing the corrected data in the Church's databases. (The contours of that geocoding tool remain to be disclosed outside of the beta.)

Meanwhile, I don't know of a general batch-geocoding solution that is free, accurate and comprehensive. And I have looked hard. Getting most results and making maps is pretty easy. Getting fully accurate results is what is hard. (In my ward, we are lucky enough to have good public-domain geocoded data from the city. With some custom programming, we are able to geocode almost all addresses precisely and automatically, then manually resolve those that fail the quality threshhold. A few households with fundamentally invalid addresses will not be geocoded at all.)

The particular problem with batchgeocode.com is that it disards known errors and warnings it receives from its own source, the Yahoo geocoding API, when addresses are processed one at a time. So, for example, a street address may not be located, but Yahoo plots the Zip-code centroid instead. Or the street number may not be located, so Yahoo plots the center of the whole street, which might be several miles long. Or the street is listed in the ward database as "Wyoming Ave" even though there is no such street. Yahoo guesses that it really is "Wyoming Blvd," which is probably a good guess but may not be. Yahoo flags these as warnings in a way that a program can discern, but batchgeocode.com discards the accuracy detail without notifying the user at all.

The magnitude of this problem will vary with many factors, including how clean the addresses are in the ward directory. In many -- most? -- wards, the quality of that address data is not very good.

Similar problems can occur with other geocoding engines. Geocoding is inherently error-prone, and no batch process can be accurate unless it provides for detection and manual correction of errors -- both errors of omission and of commission.

You might look at HPaulsen's mapping program. One thing it does under the hood -- it is using Google's geocoding API -- is to check the quality code Google returns with each geocoding transaction, and exclude those addresses that fail to meet a threshold of reasonable certainty. The user then can attempt to plot these addresses manually. That application does not export KML files, but theoretically it could be enhanced to do so. (Whether Google would allow that under its Terms of Use is another matter. I'm not sure of the answer.)

Other solutions might include commercial geocoding service bureaus.
Onti-p40
New Member
Posts: 4
Joined: Thu Oct 15, 2009 12:35 pm
Location: On the move, USA

#12

Post by Onti-p40 »

avskip wrote:Have you ever heard of NBEMS ( Narrow Band Emergency Messaging System) ? It's a set of programs used to send messages and files via Amateur Radio using an audio interface.
Look to me like a solution in desperate need of a problem.

The same job is already well-handled by popular, reliable commo modes which have a good track record (PKT was used in live disaster ops in 1986), and anyone who can't figure out how to hook up a radio-PC interface won't have much trouble finding someone who can.

The risk is to divide the available resources too far. The job of disaster communications is to COMMUNICATE, and anything which can (at best) only provide an incremental improvement isn't worth making the change.
michaelcox
Member
Posts: 89
Joined: Sun Feb 18, 2007 12:51 am
Location: Southern Utah, USA
Contact:

#13

Post by michaelcox »

Bill.Stewman wrote:VoIP - Ch 9259 - 0230

Any one know if this net is still going on? Just found it. Will have to fire up Echolink on Tuesday and check out *ERC-ECC*.
Thanks,

Michael H. Cox
User avatar
jltware
Member
Posts: 68
Joined: Sun Feb 03, 2008 12:24 am
Location: Australia

#14

Post by jltware »

I think it is, but I'm pretty sure that node is IRLP, not echolink. 9259 is channel 9 on the Western Reflector, which is one I have seen used quite often before. Not sure if that node number will do you any good on echolink, as the two networks aren't crosslinked (though there are repeaters and nodes out there capable of accessing either, just not both at the same time).
User avatar
Mikerowaved
Community Moderators
Posts: 4734
Joined: Sun Dec 23, 2007 12:56 am
Location: Layton, UT

#15

Post by Mikerowaved »

jltware wrote:Not sure if that node number will do you any good on echolink, as the two networks aren't crosslinked (though there are repeaters and nodes out there capable of accessing either, just not both at the same time).
While that's usually the case between Echolink and IRLP, it turns out that IRLP 9259 and Echo link Conference *ERC-ECS* (328327) have a special full-time link between them, so you can use either system when joining the above mentioned net. I have a commitment on Tues evening or I would check in more often myself.
So we can better help you, please edit your Profile to include your general location.
User avatar
jltware
Member
Posts: 68
Joined: Sun Feb 03, 2008 12:24 am
Location: Australia

#16

Post by jltware »

Really?? Very interesting. I was completely unaware that such links existed. (In fact, I thought they were a violation of IRLP's terms and conditions). Do you know is it common for such crosslinks to exist? Is there any way to look up if such links exist on other reflectors? I found info on that link once I knew what to look for, but wouldn't know what to search for when looking for others. Wow, you really do learn something new everyday. Thanks for the heads up :).
User avatar
Mikerowaved
Community Moderators
Posts: 4734
Joined: Sun Dec 23, 2007 12:56 am
Location: Layton, UT

#17

Post by Mikerowaved »

This is the only full-time link between the two systems that I'm aware of.
So we can better help you, please edit your Profile to include your general location.
zalearch
New Member
Posts: 1
Joined: Mon Apr 09, 2012 10:25 pm

NBEMS - Amateur Radio Program

#18

Post by zalearch »

I have been using the NBEMS as part of the fldigi software and have enjoyed using it.
I conduct a digital net on 3.581 USB each Saturday 7:00PDT (1400utc). The call sign is under W7MNW. I would like to invite participants we are all in a learning phase of one degree or another. We have a small number of participants.

I use FLDIGI and have it set up for RSID which sends out a id carrier that will switch your software to the proper mode if it is set up for both RX / TX. If you would like to experiment with mode contact : kc7fyd@q.com; It is a quick way of getting reports out of the stake to the local BSH. If you have tried to send out a report using voice sometimes things do not come through as intended. Using Digital it will also allow you to have a hard copy that is transmitted in a shorter time. In our area we experimenting with the use of the digital modes for communication improvement on passing reports.
Post Reply

Return to “General Discussions”