Nesma 主页 论坛 浆纱 浆纱 – FPA Google API捕获位置坐标

已标记: , , ,

观看中 13 帖子 - 1 通过 13 (的 13 总)
  • 作者
    帖子
  • #7690

    我有一个用户定义的要求,在执行外部输入时我必须发送位置坐标 (经度, 纬度, 高度) 我将使用 Google API & 根据我将发送的回复 & 保存系统中的位置坐标.

    我认为引用的Google文件可以算作EIF.

    我的理解正确吗? 需要专家建议.

    也在谷歌 (该位置数据), 是否会被视为 ILF?

    #9278

    是的 Ankur 我有同样的问题: 如何统计现有网络服务的使用情况.

    我们是否应该看到 Google 网络服务将坐标转换为外部接口文件 EIF 的地址信息?
    或者我们应该将此 Web 服务的请求视为外部输出 EO (当我们通过系统边界发送信息时)?
    或者我们应该把它们都算上?

    其他人如何计算这个?

    #9415

    你好安库尔,

    您正在处理外部输入, 这是某个系统的一部分. 我们将此系统称为 System_A. 所以所研究的系统是System_A. 我们计算 System_A 的 EI, 给予 4 FP (假设平均复杂度).
    从 System_A 开始,此处不计算任何 EO, 作为发送给 Google 的消息 (API请求) 不是初等函数. 它是 EI 的一部分,此消息不是用户操作的主要意图. 出于同样的原因,来自 Google 的传入消息 (API响应) 不被计算在内.

    现在让我们考虑一下 Google API 本身. 它存在, 不改变并且驻留在 System_A 之外. 所以这里不计FP.

    是否应该使用 Google 网络服务 (API) 被视为 EIF? 如果我们应该, 那么该 Web 服务应该符合 EIF 的资格, 这意味着 EIF 定义适用于 Web 服务.
    内斯玛 说: 外部接口文件 (EIF) 是从用户角度来看的永久数据的逻辑组,满足以下每个标准:
    • 它被应用程序用来进行计数和
    • 它不是由要计数的应用程序维护的,并且
    • 它由另一个应用程序维护并且
    • 可直接提供给应用程序进行计数.
    而且此外:
    • 外部接口文件必须是另一个应用程序的内部逻辑文件.
    并非所有这些都适用于网络服务, 所以 Web 服务不是 EIF.
    如果帕格 说: 数据函数应分类为
    b) 外部接口文件 (EIF) 如果是
    • 参考, 但没有维护, 通过被测量的应用程序, 和
    • 在一项或多项其他申请中的ILF 中被识别.
    这不适用于网络服务, 所以 Web 服务不是 EIF.
    此外,Web 服务不包含 ILF(小号) 参考.
    所请求的数据位于 Google 内的何处将是未知的. 谷歌将简单地提供它, 向其发送正确的消息.
    所以这里没有识别出 EIF.

    希望这可以帮助!

    问候,
    马丁·雅各布斯
    QSM欧洲

    #9416

    你好马丁,

    你说 “并非所有这些都适用于网络服务, 所以 Web 服务不是 EIF。”
    您能否解释一下哪些标准不适用于 Google Api?

    假设我们正在使用 Google Api 中的功能从邮政编码获取地址.
    该 API 包含所有已知邮政编码和相应坐标的数据
    此外,此 api 还包含许多坐标的数据及其地址信息 (街道, 城市, 国家, 等等).

    1. 由应用程序使用来进行计数
    是的,我们的 systemA 使用 Google Api .

    不是由要统计的应用程序维护的
    没有, 我们的systemA不维护Google Api的数据

    它由另一个应用程序维护
    是, Google 的人员拥有维护此信息的应用程序.

    可以直接提供给应用程序进行统计.
    是, 我们的systemA可以直接调用函数来检索数据

    外部接口文件必须是另一个应用程序的内部逻辑文件
    是, 邮政编码, 坐标和地址信息是 Google 应用程序中的 ILF

    所以你看, 我认为所有标准都满足.
    请告诉我们您认为不符合哪些标准, 这样我们就可以互相学习.

    谢谢,
    亚历山大

    #9417

    你好亚历山大,

    我会尽力而为!

    请参阅我对您的观点的回复 <米杰> … </米杰>

    你说 “并非所有这些都适用于网络服务, 所以 Web 服务不是 EIF。”
    您能否解释一下哪些标准不适用于 Google Api?

    假设我们正在使用 Google Api 中的功能从邮政编码获取地址.
    该API包含所有已知邮政编码和相应坐标的数据此外,该API还包含许多坐标及其地址信息的数据 (街道, 城市, 国家, 等等).
    <米杰> 我不认为 API “有” 数据. 它可以为你得到它, 因为它是一个接口. 你认为API本身就是一个系统吗, 或者 Google 是您正在考虑的系统? </米杰>

    1. 它被应用程序使用来计数是的,我们的systemA使用Google Api .
    <米杰> 本人. 这并不意味着它是一个数据函数. </米杰>

    不是被统计的应用程序维护的 否, 我们的systemA不维护Google Api的数据
    <米杰> 它不是. 仍然: API 是否包含数据? </米杰>

    它由另一个应用程序维护
    是, Google 的人员拥有维护此信息的应用程序.
    <米杰> Google 的人员是否维护 API 中的信息? </米杰>

    可以直接提供给应用程序进行统计.
    是, 我们的systemA可以直接调用函数来检索数据
    <米杰> 您可以检索数据, 但你怎么知道这是实际数据? </米杰>

    外部接口文件必须是另一个应用程序的内部逻辑文件 是, 邮政编码, 坐标和地址信息是 Google 应用程序中的 ILF
    <米杰> 你怎么会知道这事? 可能有多个 ILF 来组成这些数据. 你会假设有多少? </米杰>

    所以你看, 我认为所有标准都满足.
    请告诉我们您认为不符合哪些标准, 这样我们就可以互相学习.
    <米杰> 查看我的回复. 我认为你做了很多假设. 您有支持它们的规格吗? </米杰>

    我期待继续讨论,因为我认为这对我们很多人都很重要!

    问候,
    马丁

    #9418

    我们是否同意 Google 地图是一个具有功能和内部数据的系统?

    #9419

    谷歌已经发布了很多谷歌地图的API.
    您可以在这里阅读它们: https://developers.google.com/maps/documentation/geocoding/start
    在那里您可以阅读 “反向地理编码请求和响应 (地址查找)” 功能性.
    你告诉它一些过滤数据,Google 会提供一个数据列表:
    地址组件

    格式化地址
    所以我不需要了解很多关于数据存储技术方式的技术细节.
    谷歌告诉我一个逻辑地址列表.

    从用户的角度来看,这是使用的逻辑数据.

    但如果您愿意,我们可以使用 systemB 创建我们自己的示例,该示例通过 api 提供数据,对于该示例,我们确切地知道数据是如何存储的. 我们是否需要该示例,或者我们可以继续使用 Google 地图作为示例吗?

    #9420

    我们继续以 Google 地图为例.

    这是你推理的核心, 我认为:
    你告诉它一些过滤数据,Google 会提供一个数据列表:
    地址组件

    格式化地址
    所以我不需要了解很多关于数据存储技术方式的技术细节.
    谷歌告诉我一个逻辑地址列表.

    从用户的角度来看,这是使用的逻辑数据.

    我关注你的最后一句话.
    Google 地图发送一个数据集供我使用.
    这是否意味着在您看来,来自系统边界之外的、可供您使用的数据集始终是 EIF?
    该数据集是否包含由 Google 地图维护的永久数据?

    #9421

    是的,让我们从这句话开始: “Google 地图发送一个数据集供我使用”

    你有两个问题:
    1. 在您看来这是否意味着 [的] 始终可供您使用的系统边界外部的数据集是 EIF?
    也许这个词 “总是” 太强了, 但是,是的, 我认为您可以将其视为 EIF.
    我想到 Nesma 计数团队提供的一个示例,该示例描述了一种情况,一个系统的两个 ILF 可以成为外部系统的一个 EIF: https://nesma.org/freedocs/additional-example-06-code-and-description/

    2. 该数据集是否包含由 Google 地图维护的永久数据?
    是的,我确实认为这是 Google 地图系统中的永久数据: 它可以使用,而不仅仅是在请求期间可用然后被消耗 (消失了). 换一种说法: 谷歌地图系统知道每个邮政编码一条街道和一个城市. 这是在 API 请求之前已知的,并且在 API 请求之后系统仍然知道. 从 API 请求的角度来看,这是永久数据.

    #9422

    您是否将向您询问并提供给您的 DET 算作 1 EIF?
    您是否确定查询 Google 地图的哪些 ILF 来提供您可用的数据?
    我们看一下你提到的例子.
    如果你有确定性, 那么这些应该被命名并计算. 可能有不止一个.
    如果你没有这个确定性, 那么应该做出一个假设. 这个例子清楚地表明不同的 FP 分析师可以做出不同的假设, 导致不同的计数. 这就是我在给你的第一次回复中关于假设的评论中提到的内容以及: 外部接口文件必须是另一个应用程序的内部逻辑文件 是, 邮政编码, 坐标和地址信息是 Google 应用程序中的 ILF
    <米杰> 你怎么会知道这事? 可能有多个 ILF 来组成这些数据. 你会假设有多少? </米杰>.
    你只是简单地将Web服务算作EIF吗? 你用它记录任何假设或解释吗? 我正在努力最小化 FP 分析师计数差异.

    #9443

    嗨马丁, 你一直问问题. 对我来说很多人, 聊天中很混乱.

    个人的, 在大多数情况下,我看到 SystemB 内的 Web 服务使用 bij SystemA 作为 SystemA 的一个 EIF.
    我不会对此进行太多记录,因为这对我来说是很常见的.

    那么你如何计算这个例子呢??

    #15982
    苏汉南
    参加者

    哇这真是满嘴. 我有许多相同的情况,需要了解确定尺寸的最佳方法. 我使用NESMA估算尺寸.

    我使用USPS验证地址,因此在这种情况下, 看来我会有EIF (USPS将返回给我的地址) 并在验证请求后将USPS地址的EQ返回给客户 (换一种说法, 用户看到的EQ是USPS地址,可以选择它或保留输入的EQ) 以及EUS保留和维护的地址的EIF. 至于一个额外的情商 (这是从我的系统到USPS Web服务的消息) 和EI (使用有效地址返回邮件)…我选择不单独计算这些,因为它们是客户作为 USPS 地址接收的主要 EQ 的一部分,以使用或保留客户输入系统的内容.

    我还使用Google地图来验证地址是否有效,并查看在哪里送货. 我想它的数量与上面的USPS场景相同.

    你能帮我吗?? 谢谢.

    #15983
    弗兰克Vogelezang
    密钥管理员

    为了 USPS地址验证, 一种 新话题 已经开始, 保持讨论的重点. 请使用本线程的其余部分仅发表有关使用 Google API 的评论.

    切换到 USPS 主题.

观看中 13 帖子 - 1 通过 13 (的 13 总)
  • 您必须登录才能回复此主题.