Common guides
When something in AstroCarto looks wrong or will not continue, first identify what is blocked: birth input, the selected result, a saved record or download, or access to an action. Keep the current input and visible message before changing anything. The checks below help you choose a useful next step without treating every problem as a calculation error.
Should I correct the input or keep the uncertainty visible?
Use the recorded local birth date and time, and the full birthplace. A destination belongs in the city workflow, not in the birthplace field. Resolve an identifiable input mistake before asking the result to answer a new location question.
| What you notice | First check | Action and completion check |
|---|---|---|
| The birthplace name is ambiguous | Country, region, and the matched suggestion | Select the intended birthplace and confirm its identity. Follow birth data and time zones for place matching and timezone handling. |
| You do not know a reliable birth time | Whether the form marks the time as unknown | Keep that uncertainty visible. Read unknown birth time for the limits of the workflow you want; a guessed time does not supply an accurate-time result. |
| You corrected a birth field but the old result remains open | Which calculation produced that map or report | Generate the map again, then rerun the affected research using the corrected input. Confirm the new input in the result; an existing report retains its own version. |
| The form still fails after checking the record | Date, local time, full birthplace, timezone where shown, and the exact error | Use the original record rather than shifting the time until the form accepts it. If the failure persists, contact support with the checked details and message. A general failure alone does not identify a timezone cause. |
A saved person is another input source. After selecting one, inspect the filled fields before calculating. If the stored record itself is wrong, correct the record through its own workflow; changing a form once does not necessarily update the saved person.
Is this a display difference, a different task, or a result to investigate?
Compare like with like before deciding that a map is wrong. Check the birth input and its time status, selected coordinates or named city, visible planets, workflow, and goal. A point on a map, a named-city check, a planetary pairing, and a city comparison do not describe the same object.
| What you see | What to distinguish | Useful next step |
|---|---|---|
| No planetary lines are visible | Hidden display versus a completed reading | Turn on an available planet and reselect the intended point. The interactive map guide explains the controls and visible evidence. |
| A city result differs from a nearby map click | Destination coordinates versus the point actually selected | Use Check a city to identify the destination by its full name and country. Keep any difference in coordinates visible in your notes. |
| A discovery list and your comparison have a different order | A supported candidate pool versus the cities you supplied; also check the goal | Return to the workflow for that question. A place missing from discovery is not automatically unsuitable, and a comparison winner leads only within that comparison. |
| Two websites show different maps | Input, local-time handling, place coordinates, line type, and calculation method | Record the matching conditions and the exact remaining difference. The calculation-method guide explains AstroCarto's basis; a visual mismatch alone does not establish which result is wrong. |
Worked example: restore visible evidence before judging a place
This example reuses the interactive map tutorial's synthetic input: 15 January 1990, 12:15, Greater London, England, United Kingdom, with known time. The selected point stays at 18.15° N, 11.95° E while the visible planets change.
| Same input and selected point | Example output | What has actually changed |
|---|---|---|
| After Hide All | 0 visible line results; the location cannot yet be read | The display has no visible planetary evidence. This is not an unfavourable location verdict. |
| Sun enabled | 2 visible line results; the quick reading describes no strong planetary-line push | The point now has readable Sun-only evidence. Other planets are still hidden or locked, and two displayed results do not mean two close lines. |
| Nearby discovery in that Sun-only view | The closest visible line is Sun MC, about 1,410 km away | It is distant from this point. The answer can be readable without showing a strong nearby influence. |
To diagnose this situation, keep the birth input and point fixed, enable Sun if available, reselect the point, and open See why we reached this answer. Check that the visible evidence has changed before interpreting it. The successful outcome is a reading that matches the intended display—not a favourable label. Your selected coordinates and line visibility can produce different numbers from the example.
A useful note is: “Same input and point; all hidden → Sun visible; now two displayed results, with the nearest Sun MC still distant. Display issue resolved; wider location research remains open.” If you need other planetary evidence, check its actual availability rather than treating hidden lines as absent from the chart.
Am I looking for an input, a destination, a report, or a local file?
Identify the object before trying to recover it. Saving a city, storing birth details, generating a report, and downloading a file have different completion checks.
| What you want back | First action | Confirm before relying on it |
|---|---|---|
| A city you intended to keep | Use Save and revisit places and check the correct account and collection | The destination appears in the saved list. Its label organizes your research; reopening it does not recover every earlier interpretation. |
| An existing report or other account record | Follow saved data and results and open the relevant history | Match the person, date, cities, goal and content where applicable. Check the account and record status before starting another report. |
| A map image, report PDF, or conversation TXT | Start from the relevant result's export action; use Export maps and reports | The file actually downloads, opens, and contains the intended result and input version. An open result page is not a downloaded file. |
For a Personal Report showing Prepare PDF, use that action and wait while it says Preparing…. When Download PDF appears, use the download action and open the resulting file. If preparation fails, follow the displayed retry action; if the problem persists, retain the report identity and error for support. A preparation message alone does not mean a file has reached your device. Other report formats may use a different download flow.
If a download is missing, check the browser's download list and destination folder before repeating the export. If the account record is missing, check the account and history instead. A local PDF does not restore an interactive map, and a remembered browser session is not a guaranteed account archive across devices.
Is this about sign-in, feature access, usage, or the account itself?
Read the message on the action you are trying to complete. Signing in identifies an account; it does not establish access to every feature. Credits, feature permissions, and reliable birth-time requirements answer different questions.
| Blocked situation | First check | Next step |
|---|---|---|
| A sign-in prompt or missing account history | Which account holds the purchase or generated record | Sign in to the intended account, then reopen the relevant action or history. A different sign-in can have different records. |
| A feature remains locked | The named action and the access message shown for it | Compare that action with the current plans and allowances. A visible map or an AI credit balance alone does not establish access to every city, pairing, report, or export action. |
| An action needs an accurate birth time | The time status of the person or people involved | Resolve the input limitation first. More credits or different feature access cannot make an unknown time reliable. |
| A stored person is wrong or must be removed | The saved birth record, rather than a map or the entire account | Follow Store and reuse birth details for reuse, edits, and the record's removal process. Check filled inputs again before calculating. |
| A purchase or account change needs help | Purchase status, the related account, and the specific object or action | Use Contact support. Describe whether the issue concerns a purchase, a record, access, or the account itself; removing a saved person is not the same as deleting an account. |
If a purchase appears complete but the expected action remains locked, check the intended account and purchase status before trying another purchase. Support can investigate the mismatch when you provide the relevant details; do not infer from the prompt alone that the payment failed.
A useful support request includes the action you attempted, exact visible message, time it occurred, account email, and the relevant report or purchase reference if available. For a map discrepancy, include the birth input, selected location, visible planets and goal. Once the issue is resolved, return to Guides to continue the original research task.
If the purchase itself is missing, match the purchasing account and transaction before trying another checkout.
For profile changes or account closure, follow the account-management paths rather than treating them as a result-generation problem.