Yeah they definitely did not accommodate certain scenarios and force you into submitting inaccurate data either on the subscription side or the address locations side. Here is one we are commonly running into:
The subscription file shows 1 subscriber in a tract. That tract is typically on the edge or even outside of the "normal" coverage area of the Wisp. Using our methodology and THEIR requirements for if a location is "serviceable" we did not find any locations in that tract. The 1 that shows up in the subscription file is typically a "one-off" case, like a 50ft pole or a tower in someone's back yard, the top of a grain silo, etc. These are not deemed "serviceable" by their requirements as they are not a "typical" installation that can be done within 10 days. So, to be in compliance with the requirements it is not reported. However, if you have no locations in a tract that shows up in the subscription file, you can't continue the filing. So there is a direct conflict with the two requirements. On one hand, you have to report the subscriber in your subscription. On the other, the location is technically not serviceable by their requirements so you can't report it in the addresses and because the tract is generally unserviceable anyway, no other locations show up. You either have to remove the tract from subscriptions, or add a point that doesn't qualify under their rules. I've emailed them 4 times about it and their only response was to tell me we must have geocoded our customer incorrectly. What? I don't even think they are reading my description of the problem. On Sun, Aug 28, 2022 at 11:24 AM Trey Scarborough <t...@3dsc.co> wrote: > Yeah, but this is kind of unheard of they didn't even require this type of > information back when they were doing all of this for phone lines. Its too > late now but if as a whole everyone would have said no we are not doing > this. If a majority of small ISPs didn't they would have a hard time > enforcing the 15k fines. That would leave a spoltlight on VZ, ATT, > Windstream, etc and there is no way their information is going to be > accurate either. Then it would have been made more apparent that the data > they are providing is garbage. When the underlying element of address > fabric is flawwed and not accurate especially in rural areas. I really > don't understand how they can expect the RF propagation and everything else > to be accurate. > > > On 8/25/22 2:15 PM, Josh Luthman wrote: > > Not filing is a bad decision. > > On Thu, Aug 25, 2022 at 2:55 PM Cameron Crum <cc...@murcevilo.com> wrote: > >> cheat has a special section for this . Look at the bottom left. You have >> to build your speed tier to signal strength mappings so they can export >> polygons for your speed tiers. It's a bit different from just the regular >> runs. If you have cheat polygons, we can prep your stuff pretty quickly as >> we don't have to do all the analysis. It's basically your contact info, >> what services you are filing for and then your polygon and fabric uploads. >> >> Cameron >> >> On Thu, Aug 25, 2022 at 1:45 PM Steve Jones <thatoneguyst...@gmail.com> >> wrote: >> >>> The companies doing the BDC filings >>> What data, specifically are they going to need from us to do the filing? >>> Im trying to get the export out of CnHeat, but I still need to get more >>> sites into it and I havent even started the whole subscription side >>> Anybody just not filing? >>> -- >>> AF mailing list >>> AF@af.afmug.com >>> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >>> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> > > -- > AF mailing list > AF@af.afmug.com > http://af.afmug.com/mailman/listinfo/af_af.afmug.com >
-- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
