In this project you will scrape as much data as you can get about the *actual* sightings of Pokemons. As it turns out, players all around the world started reporting sightings of Pokemons and are logging them into a central repository (i.e. a database). We want to get this data so we can train our machine learning models. You will of course need to come up with other data sources not only for sightings but also for other relevant details that can be used later on as features for our machine learning algorithm (see Project B). Additional features could be air temperature during the given timestamp of sighting, location close to water, buildings or parks. Consult with Pokemon Go expert if you have such around you and come up with as many features as possible that describe a place, time and name of a sighted Pokemon. Another feature that you will implement is a twitter listener: You will use the twitter streaming API (https://dev.twitter.com/streaming/public) to listen on a specific topic (for example, the #foundPokemon hashtag). When a new tweet with that hashtag is written, an event will be fired in your application checking the details of the tweet, e.g. location, user, time stamp. Additionally, you will try to parse formatted text from the tweets to construct a new “seen” record that consequently will be added to the database. Some of the attributes of the record will be the Pokemon's name, location and the time stamp. Additional data sources (here is one: https://pkmngowiki.com/wiki/Pok%C3%A9mon) will also need to be integrated to give us more information about Pokemons e.g. what they are, what’s their relationship, what they can transform into, which attacks they can perform etc.
After the API spec has settled you're going to have to implement and ship it as an npm package, so that the map teams and us, the UI team, can use it. This of course is a lot of work, however, we, the UI team, will just use a stub implementation until you provide us with your implementation.
@MajorBreakfast I think youve already seen our first version of the API as you already mentioned it in your other post. You don't have to use a stub implementation, you simply have to call these URLs like http://pokedata.c4e3f8c7.svc.dockerapp.io:65014/api/pokemon/sighting/source/POKESNIPER. Why would you want to blow that up into a whole package?
Also in your architecture you got something slightly wrong: not only twitter but also the other data sources do contribute to the prediction.
Yup @MajorBreakfast you are mixing up things a bit.
PokeData IS the API, this is where you or any other team (map, predictions,...) Get their data :)
It doesn't make sense that the map people use this as an npm package, they should just use the API calls to get the data, should some calls be missing they can coordinate with this project to implement the new routes and where to get the data from.
The map trams will then package their product into npm packages which you will use. These packages will have the possibility to define where the endpoint for the API calls is, so that everything will work correctly.
jonas-he
commented
8 years ago 
sacdallago
MajorBreakfast
The discussion about the API happens at https://github.com/PokemonGoers/Catch-em-all/issues/23 and I hope you all join us!
After the API spec has settled you're going to have to implement and ship it as an npm package, so that the map teams and us, the UI team, can use it. This of course is a lot of work, however, we, the UI team, will just use a stub implementation until you provide us with your implementation.
MajorBreakfast (Project E)