nesma.org Forums Sizing Sizing – FPA Google API to capture location coordinates

Tagged: , , ,

This topic contains 12 replies, has 4 voices, and was last updated by  Frank Vogelezang 3 months, 1 week ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #7690

    Ankur Shrivastava
    Participant

    I have a user defined requirement that while performing an external input I have to send the location coordinates (Longitude, Latitude, Altitude) for which I will use Google API & based on the response I will send & save the location coordinate in the system.

    I think that Google files which are referenced can be counted as an EIF.

    Is my understanding correct? Need Expert advice.

    Also in Google (This location data), will it be considered as an ILF?

    #9278

    Alexander Vermeulen
    Participant

    Yes Ankur I have the same question: how to count the use of an existing webservice.

    Should we see the Google webserivce to transform a coördinate to address information as an External Interface File EIF?
    Or should we see the request to this webservice as an External Output EO (as we are sending information over our system-border)?
    Or should we count both of them?

    How are others counting this?

    #9415

    Martin Jacobs
    Participant

    Hello Ankur,

    You are working on an External Input, which is part of some system. Let’s call this system System_A. So the system under study is System_A. We count an EI of System_A, giving 4 FP (assuming average complexity).
    From System_A no EO is to be counted here, as the outgoing message to Google (API request) is not an elementary function. It is part of the EI and this message is not the primary intent of the user’s action. For the same reason the incoming message from Google (API response) is not to be counted.

    Now let’s consider the Google API itself. It exists, doesn’t change and resides outside System_A. So no FP to be counted here.

    Should the Google webservice (API) be seen as an EIF? If we should, then the webservice should qualify as an EIF, which means that EIF definition applies to the webservice.
    Nesma says: An external Interface File (EIF) is a logical group of permanent data seen from the perspective of the user that meets each of the following criteria:
    • It is used by the application to be counted and
    • It is not maintained by the application to be counted and
    • It is maintained by another application and
    • It is directly available to the application to be counted.
    And furthermore:
    • An external Interface File must be an Internal Logical File of another application.
    Not all of this applies to the webservice, so the webservice is not an EIF.
    Ifpug says: A data function shall be classified as an
    b) External Interface File (EIF) if it is
    • referenced, but not maintained, by the application being measured, and
    • identified in an ILF in one or more other applications.
    This does not apply to the webservice, so the webservice is not an EIF.
    Also the webservice does not contain the ILF(s) referenced.
    Where the requested data resides within Google will be unknown. Google will simply provide it, giving a correct message sent to it.
    So no EIF identified here.

    Hope this helps!

    Regards,
    Martin Jacobs
    QSM Europe

    #9416

    Alexander Vermeulen
    Participant

    Hello Martin,

    You say “Not all of this applies to the webservice, so the webservice is not an EIF.”
    Could you explain which of these criteria does not apply to the Google Api?

    Let’s say we are using the functionality in the Google Api to get an address from a zipcode.
    This Api has data for all known zipcodes and the corresponding coordinates
    Also this api has data for a lot of coordinates their adress information (street, city, country, etc).

    1. It is used by the application to be counted
    Yes our systemA uses the Google Api .

    It is not maintained by the application to be counted
    No, our systemA does not maintain the data of the Google Api

    It is maintained by another application
    Yes, people at Google have applications that maintain this information.

    It is directly available to the application to be counted.
    Yes, our systemA can directly call the functionality to retreive the data

    An external Interface File must be an Internal Logical File of another application
    Yes, The zipcode, coordnaties and address information are ILF in the Google application

    So you see, i think all criteria are met.
    Please tell us which criteria you think is not met, so we can learn from each other.

    thank you,
    Alexander

    #9417

    Martin Jacobs
    Participant

    Hello Alexander,

    I will do my best!

    See my response to your points between <mj> … </mj>

    You say “Not all of this applies to the webservice, so the webservice is not an EIF.”
    Could you explain which of these criteria does not apply to the Google Api?

    Let’s say we are using the functionality in the Google Api to get an address from a zipcode.
    This Api has data for all known zipcodes and the corresponding coordinates Also this api has data for a lot of coordinates their adress information (street, city, country, etc).
    <mj> I don’t think the API “has” the data. It can get it for you, as it is an interface. Do you consider API to be a system itself, or is Google the system you are considering? </mj>

    1. It is used by the application to be counted Yes our systemA uses the Google Api .
    <mj> I.m.o. this does not imply it is a data function. </mj>

    It is not maintained by the application to be counted No, our systemA does not maintain the data of the Google Api
    <mj> It does not. Still: does the API contain the data? </mj>

    It is maintained by another application
    Yes, people at Google have applications that maintain this information.
    <mj> Do people at Google maintain information within the API? </mj>

    It is directly available to the application to be counted.
    Yes, our systemA can directly call the functionality to retreive the data
    <mj> You can retreive the data, but how do you know it is the actual data? </mj>

    An external Interface File must be an Internal Logical File of another application Yes, The zipcode, coordnaties and address information are ILF in the Google application
    <mj> How do you know this? There might be several ILFs to compose this data. How many would you assume? </mj>

    So you see, i think all criteria are met.
    Please tell us which criteria you think is not met, so we can learn from each other.
    <mj> See my responses. I think you are making a lot of assumptions. Do you have the specs that support them? </mj>

    I am looking forward to continuation of this discussion as I think it is important to a lot of us!

    Regards,
    Martin

    #9418

    Alexander Vermeulen
    Participant

    Do we agree that Google Maps is an system with functionality and internal data?

    #9419

    Alexander Vermeulen
    Participant

    Google has published a lot of API to Google Maps.
    You can read them here: https://developers.google.com/maps/documentation/geocoding/start
    There you can read the “Reverse geocoding request and response (address lookup)” functionality.
    You tell it some filter data and Google profides a list of data:
    address_components
    and
    formatted_address
    So i don’t need to know a lot of technical details about the technical way the data is stored.
    Google tells me a logical list of address.

    From a user perspective this is the logical data that is used.

    But if you prefere we can create our own example with a systemB that provides data through an api and for that example we exactly know how the data is stored. Do we need that example or can we continu with Google Maps as the example case?

    #9420

    Martin Jacobs
    Participant

    Let’s continu with Google Maps as the example case.

    This is the core of you reasoning, I think:
    You tell it some filter data and Google profides a list of data:
    address_components
    and
    formatted_address
    So i don’t need to know a lot of technical details about the technical way the data is stored.
    Google tells me a logical list of address.

    From a user perspective this is the logical data that is used.

    I focus on your last sentence.
    Google Maps sends a dataset which is then available to me to use.
    Does this mean that in your view a dataset from outside the system boundary made available to you always is an EIF?
    Does this dataset contain permanent data which is maintained by Google Maps?

    #9421

    Alexander Vermeulen
    Participant

    Yes let start with the sentence: “Google Maps sends a dataset which is then available to me to use”

    You have two questions:
    1. Does this mean that in your view [of] a dataset from outside the system boundary made available to you always is an EIF?
    Maybe the word “always” is to strong, but yes, i think you can see this as an EIF.
    I think of an example provided by the counting team of Nesma that describes a situation where two ILF’s for one system can be one EIF for an external system: https://nesma.org/freedocs/additional-example-06-code-and-description/

    2. Does this dataset contain permanent data which is maintained by Google Maps?
    Yes i do think that this is permanent data within the Google Maps system: it is available to use and not only available during request and then consumed (gone). In other words: Google Maps system knows for each zipcode a street and a city. This is known prior to the API request and is still known by the system after the API request. For for a perspective of the API request this is permanent data.

    #9422

    Martin Jacobs
    Participant

    Do you count the DETs asked by and provided to you as 1 EIF?
    Do you know with certainty which ILFs of Google Maps are queried to provide the data made available to you?
    Let’s look at the example you refer to.
    If you have the certainty, then these should be named and counted. There might be more than one.
    If you don’t have this certainty, then an assumption should be made. The example makes clear that different FP analysts can make different assumptions, resulting in different counts. This is what I referred to with my remark about assumptions in my first response to you and in: An external Interface File must be an Internal Logical File of another application Yes, The zipcode, coordnaties and address information are ILF in the Google application
    <mj> How do you know this? There might be several ILFs to compose this data. How many would you assume? </mj>.
    Do you simply count the webservice as an EIF? Do you document any assumption or explanation with it? I am trying to minimise FP analyst counting differences.

    #9443

    Alexander Vermeulen
    Participant

    Hi Martin, you keep asking question. To many for me, it is to confusing in a chat.

    Personaly, in most cases I see a Webservice inside SystemB used bij SystemA as one EIF for SystemA.
    I don’t document this a lot as it is very usual for me to do so.

    So how do you count for the example?

    #15982

    SueHannan
    Participant

    Wow this was a mouthful. I have many of these same scenarios and need to understand best way to size it. I use the NESMA Estimated sizing method.

    I use USPS to validate address so in this case, it seems I would have an EIF (for the address that USPS is going to return to me) and an EQ for the USPS address returned to the customer at the request of validation (in other words, the EQ which is what the user see’s as the USPS address and can select it or keep the one they entered) and an EIF for the address that USPS keeps and maintains. As far as an additional EQ (which is the message from my system to the USPS web service) and the EI (for the message back with the valid address)…I am choosing to not count these separately as they are part of the primary EQ that the customer receives as the USPS address to use or keep what customer entered into the system.

    I also use Google maps to verify address is valid and to see where to deliver. I would imagine it is counted the same as the USPS scenario above.

    Can you help?? Thanks.

    #15983

    Frank Vogelezang
    Keymaster

    For the USPS address validation, a new topic has been started, to keep the discussion focused. Please use the rest of this thread for comments on the use of Google API only.

    Switch to the USPS topic.

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.